Hey Johnny,<br><br>Thanks for your clarifications and answers to my questions about [1].<br><br>Over the last few days I've been thinking about your Identifier Recycling proposal[2], in addition to other proposals (Tokens, etc). Assuming I understand things correctly, it seems as if a hybrid of the public/private token approach would seem to garner the most checks, per the IIW grid. Not sure if my idea is technically correct or not, so please let me know if what I'm proposing falls short anywhere. Here goes....
<br><br>To make Identifier Recycling Happen: <br>1.) The OP
should send the RP a Unique hash value as an attribute in AttributeExchange. This unique value should
be the hash of : <br><br>+ nonce<br>+ op_secret_password<br>+ user_supplied_secret_password<br>+ rp_url.<br><br>For example, SHA256["1393k3k3939k" + "op_recycling_password" + "my_recycling_password" + "
<a href="http://example.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://example.com</a>" ].<br><br>In this scheme, each RP will receive (via Attribute Exchange) a one-way hashed value that is unique to the OP/RP/OpenId/User combination. This value cannot
be forged so long as the recycling passwords for the OP and User are not compromised. (Note that the user's recycling password should probably be different from the actual login password).<br><br>2.) When an account should be recycled, the OP should force the new user to supply a new recycling password, which will change the hash received by a given RP. This is the signal to the RP to use a different/new account on the RP side, despite having seen the OpenId before.
<br><br>3.)
This scheme would also protect against an OP domain expiring, and getting picked up by a malicious new owner. In this case, the OP recycling password will not be known/valid, and the the new domain owner won't be able to make auth assertions for existing RP accounts that were served by the previous OP owner.
<br><br>4.) To protect legitimate users from lost recycling passwords, an account recovery mechanism will need to be in place at a given RP, so that if the RP thinks the account should be recycled, the end-user has a way to prevent this (perhaps via email, SMS message, or some other mechanism). This is a problem anyway with the other approaches.
<br><br>In the end, this approach seems to receive a "Check" under all of the headers on the IIW grid<br><br>Does not require change to delegation == Check<br>Lost Domain when owning OP == Check<br>Active Recycling == Check
<br>Consistent 1.1 == Check (Assuming 1.1 OP/RP's can use AX -- is that true?)<br>One identifier / New DB Field == Check (all data is stored in the AX mechanism).<br>No Strip Fragment == Check<br>Fragments Can be used by other mechanisms (FOAF, etc) == Check
<br><br>[1] <a href="http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling</a>
<br>[2] <a href="http://openid.net/pipermail/specs/2007-May/001767.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://openid.net/pipermail/specs/2007-May/001767.html</a>