Persistent Identifiers (was: Proposal for Recycling Identifiers in OpenID 2.0)
Claus Färber
GMANE at faerber.muc.de
Mon May 28 14:20:46 UTC 2007
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
More information about the specs
mailing list