Dmitry Shechtman schrieb: > This is definitely an interesting proposal. However, it only attempts to > solve the recycling problem, whereas canonical IDs would solve this and > several more.
I think the best solution would be a Persistent Identifier. If the OpenID Provider returns a different Persistent Identifier, the Relying Party can assume the ID has been recycled. There's no reason the Persistent Identifer should be part of the URI. It can just be returned by the OpenID Provider as a message parameter, which can be ignored by Relying Parties not interested. Or even better, it could only be used in Attribute Exchange. If Persistent Identifiers are unique across OpenID providers, they can even be used to allow users to change their claimed identity. This can be achieved by using a public cryptographic key as the Persistent Identifier (well, semi-persistent actually): A rough sketch: Login: On login, the RP tells the OP that it wants to use a Persistent Identifier and requests ALL keys for the user: RP => OP: openid.persid.version=0.1 openid.persid.getkey=ALL The RP returns a list of its public keys, both current keys and obsolete previous keys (which it can still authenticate as): OP => RP: openid.persid.key.0=DH:<base 64...> openid.persid.key.1=RSA:<base 64...> openid.persid.key.2.obsolete=RSA:<base 64...> openid.persid.key.3.obsolete=FOO:<base 64...> The RP has stored the key #2 as a persistent identifier for a user, so it asks the OP to authenticate with that key: RP => OP: openid.persid.challenge.0.key=RSA:<base 64...> openid.persid.challenge.0.id=120938231 openid.persid.challenge.0.data=<base 64...> The OP presents the correct answer but wants the RP to update to the new persistent identifier: OP => RP: openid.persid.response.id=120938232 openid.persid.response.data=RSA:<base 64...> The RP now accepts the user as being identical to the user which had key #2. It now stores key #1, which is the current RSA key, in its database for that user, possibly overwriting key #2. It might also update the OpenID identifier. Login with known key: Here, the RP already has a key for the claimed identifier, so it just sends it with the initial request: RP => OP: openid.persid.version=0.1 openid.persid.getkey=CURRENT openid.persid.challenge.0.key=RSA:<base 64...> openid.persid.challenge.0.id=120938232 openid.persid.challenge.0.data=<base 64...> The RP can now immediately return the correct answer along with a list of its CURRENT keys: OP => RP: openid.persid.response.0.id=120938231 openid.persid.response.0.data=<base 64...> openid.persid.key.0=RSA:<base 64...> openid.persid.key.1=RSA:<base 64...> As above, the RP now accepts the user as being identical to the user which had key #2 and stores key #1, which is the current RSA key, in its database. Claus _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs