Questions about IIW Identifier Recycling Table

[David Fuelling]

Hey Johnny,

Thanks for your clarifications and answers to my questions about [1].

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....

To make Identifier Recycling Happen:
1.) The OP should send the RP a Unique hash value as an attribute in
AttributeExchange.  This unique value should be the hash of :

+ nonce
+ op_secret_password
+ user_supplied_secret_password
+ rp_url.

For example, SHA256["1393k3k3939k" + "op_recycling_password" +
"my_recycling_password" + " http://example.com" ].

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).

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.

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.

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.

In the end, this approach seems to receive a "Check" under all of the
headers on the IIW grid

Does not require change to delegation == Check
Lost Domain when owning OP == Check
Active Recycling == Check
Consistent 1.1 == Check (Assuming 1.1 OP/RP's can use AX -- is that true?)
One identifier / New DB Field == Check (all data is stored in the AX
mechanism).
No Strip Fragment == Check
Fragments Can be used by other mechanisms (FOAF, etc) == Check

[1] http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling
[2] http://openid.net/pipermail/specs/2007-May/001767.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20070607/b80f1e27/attachment-0002.htm>