Persistent Identifiers (was: Proposal for Recycling Identifiers in OpenID 2.0)

[Claus Färber]

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