[PROPOSAL] Separate Public Identifier from IdP Identifier

Drummond Reed drummond.reed at cordance.net
Fri Oct 6 18:02:15 UTC 2006


+1. Josh is right. Ultimately there are three identifiers involved in all
interactions between the User, the RP, and the IdP:

1) User-Presented-Identifier (UPI): the identifier entered by the User at
the RP.

2) RP-Persisted-Identifier (RPI): the identifier that will be persisted by
the RP in order to recognize the User when next the User returns.

3) IdP-Persisted-Identifier (IPI): the identifier persisted by the IdP
against which the IdP will authenticate the user.

Here's a simple analysis of how these are used during the different flows:

OPENID 1.X

1) User enters UPI
2) RP discovers IPI (if any -- otherwise UPI = IPI)
3) RP sends IPI to IdP
4) IdP authenticates against IPI
5) IdP responds with IPI

JOSH'S PROPOSED FLOW

1) User enters UPI
2) RP sends UPI to IdP
3) IdP discovers IPI (if any -- otherwise UPI = IPI)
4) IdP authenticates against IPI
5) IdP responds with UPI

OPENID 2.0 DIRECTED IDENTITY FLOW

1) User enters UPI (where UPI = identifier of directed identity server)
2) RP sends special UPI ("http://openid.net/identifier_select/2.0") to IdP
3) IdP discovers IPI
4) IdP authenticates against IPI
5) IdP responds with RPI

OPENID 2.0 XRI CANONICAL ID FLOW

1) User enters UPI (XRI i-name)
2) RP discovers RPI (XRI i-number = CanonicalID)
3) RP sends RPI to IdP
4) IdP authenticates against RPI (RPI = IPI)
5) IdP responds with RPI

*********

On this basis, it seems the solution is for the protocol to clearly
recognize all three identifier types. This would:

a) Support all four flows above.
b) Enable RPs and IdPs to all do the right thing at the right time with the
right identifier
c) Eliminate confusion over which identifier is doing what in each flow.

So we would go from openid.identity, which is currently overloaded, to:

openid.identity = IPI
openid.persist = RPI
openid.display = UPI

Or whatever names everyone can agree on.

=Drummond 


-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Josh Hoyt
Sent: Friday, October 06, 2006 10:34 AM
To: Martin Atkins
Cc: specs at openid.net
Subject: Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

On 10/6/06, Martin Atkins <mart at degeneration.co.uk> wrote:
> * The IdP returns a document naming its authentication endpoint (in the
> "URI" field) and a special anonymous token as openid:Token. openid:Token
> may be the same as the public identifier from the previous step, but
> this is not required.

Anonymous is not a good thing to call this. What IdP-driven identifier
selection does is let the IdP help the user choose an identifier. In
no way is the response any more anonymous than an identifier that was
typed in by the user.

It is true that one of the motivations for this feature is the great
improvement in the user experience for site-specific identifiers, but
the IdP could just as well return a cross-site identifier for the
user.

Sorry to go on about terminology, but I think it's important for
understanding what's really going on.

Josh
_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs




More information about the specs mailing list