+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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Friday, October 06, 2006 10:34 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: [PROPOSAL] Separate Public Identifier from IdP Identifier On 10/6/06, Martin Atkins <[EMAIL PROTECTED]> 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@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs