RE: Delegation Proposal Amendment
Dick, The persistent identifier I referred to in this thread was whatever identifier the RP was going to persist (proposed to be called openid.rpuserid on http://www.lifewiki.net/openid/ConsolidatedDelegationProposal). This boils down to: * If Claimed Identifier = URL, then openid.rpuserid = URL * If Claimed Identifier = XRI i-name (reassignable), then openid.rpuserid = XRI i-number (CanonicalID - persistent). Both are discoverable from the XRDS document once the RP has done discovery. That's cases 2/3/4/5 on http://www.lifewiki.net/openid/ConsolidatedDelegationProposal. Thus the only case where the RP does not have an identifier to persist is the directed identity case (Case 1). In that case, the RP does not send openid.rpuserid, but instead receives it back in the response from IdP. =Drummond -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 2:21 PM To: Drummond Reed Cc: 'Josh Hoyt'; specs@openid.net Subject: Re: Delegation Proposal Amendment Drummond How does the RP get a persistent identifier before it has called the IdP? The user could type anything into the form. -- Dick On 6-Oct-06, at 2:22 PM, Drummond Reed wrote: Josh, This is very cool. Adding openid.rp_user_id would give us an unambigous way to represent what I called the RPI in my earlier message: IPI = IdP-Persistent-Identifier = openid.identity RPI = RP-Persistent-Identifier = openid.rp_user_id It doesn't address the third identifier, which I called UPI (User-Presented-Identifier -- the one the user typed in at the RP), but let's leave that aside for now. So as I understand it, the rules would be: * ON THE RP SIDE * The RP ALWAYS does discovery on UPI. Then it applies these tests: 1) If UPI maps to a directed identity server (Typehttp://openid.net/server/2.0/Type), then: openid.rp_user_id = [empty] openid.identity = http://openid.net/identifier_select/2.0; 2) If UPI is an XRI that maps to a CanonicalID AND there is no openid:delegate element in the XRD, then: openid.rp_user_id = CanonicalID openid.identity = CanonicalID 3) If UPI is an XRI that maps to a CanonicalID AND to an IPI (via the openid:delegate element in the XRD), then: openid.rp_user_id = CanonicalID openid.identity = IPI 4) If UPI is a URL that maps to an IPI (via the openid:delegate element in the XRD), then: openid.rp_user_id = UPI openid.identity = IPI 5) Else: openid.rp_user_id = UPI openid.identity = UPI * ON THE IDP SIDE * 6) IdP ALWAYS keys on the value of openid.identity. 7) IdP ALWAYS returns the same value of openid.identity that the RP sent (so the RP can always key off this value in the response). 8) IdP ALWAYS returns the value of openid.rp_user_id UNLESS it was empty, in which case see rule 9a below. 9) IdP MAY or MAY NOT do discovery. The rules are: a) If openid.identity = http://openid.net/identifier_select/2.0;, then IdP prompts User for UPI (or detects cookie, etc.). If UPI != IPI, then IdP does discovery on UPI to get mapping to IPI. IdP authenticates against IPI, but at that point allows user to select the RPI (or generates for the user). IdP returns: openid.rp_user_id = user-selected or IdP-generated RPI openid.identity = http://openid.net/identifier_select/2.0; b) If openid.identity = UPI that IdP does not recognize, then IdP does discovery on UPI to get mapping to IPI. After authentication against IPI, IdP returns: openid.rp_user_id = UPI openid.identity = UPI c) If openid.identity = IPI, IdP does not need to do discovery, but authenticates against IPI and returns: openid.rp_user_id = [value sent by RP] openid.identity = IPI * This all works wonderfully and covers all the use cases -- congratulations! Now, let me make a case for also making the third identifier -- the UPI -- explicit in the protocol. This addresses a specific usability issue that arises due to the fact that XRIs support i-name/CanonicalID separation, which URLs don't. However I believe it can also improve usability for URLs. The motivation is that in cases 2 and 3 above, the openid.rp_user_id that the RP passes to the IdP is going to be an CanonicalID, which is an i-number. This is a very ugly string like: =!F83.62B1.44F.2813 (that's my actual i-number) However the IdP only has the choice of openid.rp_user_id or openid.identity from which to greet me to ask for my authentication credentials. Since these will both be a CanonicalID, this leads to a greeting like: Hello =!F83.62B1.44F.2813. Please confirm that you want to login to YourFavoriteRP. [Allow Once] [Allow Always] [Cancel] All it takes to solve this problem is for the RP to pass the UPI in the authentication request. Then the IdP can say: Hello
Re: Delegation Proposal Amendment
ok -- I get it now -- I think it is a bad name as it implies that this is the identifier that the RP persists across sessions really, it is the user identifier that the RP gets -- Dick On 9-Oct-06, at 2:38 PM, Drummond Reed wrote: Dick, The persistent identifier I referred to in this thread was whatever identifier the RP was going to persist (proposed to be called openid.rpuserid on http://www.lifewiki.net/openid/ConsolidatedDelegationProposal). This boils down to: * If Claimed Identifier = URL, then openid.rpuserid = URL * If Claimed Identifier = XRI i-name (reassignable), then openid.rpuserid = XRI i-number (CanonicalID - persistent). Both are discoverable from the XRDS document once the RP has done discovery. That's cases 2/3/4/5 on http://www.lifewiki.net/openid/ConsolidatedDelegationProposal. Thus the only case where the RP does not have an identifier to persist is the directed identity case (Case 1). In that case, the RP does not send openid.rpuserid, but instead receives it back in the response from IdP. =Drummond -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Monday, October 09, 2006 2:21 PM To: Drummond Reed Cc: 'Josh Hoyt'; specs@openid.net Subject: Re: Delegation Proposal Amendment Drummond How does the RP get a persistent identifier before it has called the IdP? The user could type anything into the form. -- Dick On 6-Oct-06, at 2:22 PM, Drummond Reed wrote: Josh, This is very cool. Adding openid.rp_user_id would give us an unambigous way to represent what I called the RPI in my earlier message: IPI = IdP-Persistent-Identifier = openid.identity RPI = RP-Persistent-Identifier = openid.rp_user_id It doesn't address the third identifier, which I called UPI (User-Presented-Identifier -- the one the user typed in at the RP), but let's leave that aside for now. So as I understand it, the rules would be: * ON THE RP SIDE * The RP ALWAYS does discovery on UPI. Then it applies these tests: 1) If UPI maps to a directed identity server (Typehttp://openid.net/server/2.0/Type), then: openid.rp_user_id = [empty] openid.identity = http://openid.net/identifier_select/2.0; 2) If UPI is an XRI that maps to a CanonicalID AND there is no openid:delegate element in the XRD, then: openid.rp_user_id = CanonicalID openid.identity = CanonicalID 3) If UPI is an XRI that maps to a CanonicalID AND to an IPI (via the openid:delegate element in the XRD), then: openid.rp_user_id = CanonicalID openid.identity = IPI 4) If UPI is a URL that maps to an IPI (via the openid:delegate element in the XRD), then: openid.rp_user_id = UPI openid.identity = IPI 5) Else: openid.rp_user_id = UPI openid.identity = UPI * ON THE IDP SIDE * 6) IdP ALWAYS keys on the value of openid.identity. 7) IdP ALWAYS returns the same value of openid.identity that the RP sent (so the RP can always key off this value in the response). 8) IdP ALWAYS returns the value of openid.rp_user_id UNLESS it was empty, in which case see rule 9a below. 9) IdP MAY or MAY NOT do discovery. The rules are: a) If openid.identity = http://openid.net/identifier_select/2.0;, then IdP prompts User for UPI (or detects cookie, etc.). If UPI != IPI, then IdP does discovery on UPI to get mapping to IPI. IdP authenticates against IPI, but at that point allows user to select the RPI (or generates for the user). IdP returns: openid.rp_user_id = user-selected or IdP-generated RPI openid.identity = http://openid.net/identifier_select/2.0; b) If openid.identity = UPI that IdP does not recognize, then IdP does discovery on UPI to get mapping to IPI. After authentication against IPI, IdP returns: openid.rp_user_id = UPI openid.identity = UPI c) If openid.identity = IPI, IdP does not need to do discovery, but authenticates against IPI and returns: openid.rp_user_id = [value sent by RP] openid.identity = IPI * This all works wonderfully and covers all the use cases -- congratulations! Now, let me make a case for also making the third identifier -- the UPI -- explicit in the protocol. This addresses a specific usability issue that arises due to the fact that XRIs support i-name/CanonicalID separation, which URLs don't. However I believe it can also improve usability for URLs. The motivation is that in cases 2 and 3 above, the openid.rp_user_id that the RP passes to the IdP is going to be an CanonicalID, which is an i-number. This is a very ugly string like: =!F83.62B1.44F.2813 (that's my actual i-number) However the IdP only has the choice of openid.rp_user_id or openid.identity from which to greet me to ask for my authentication credentials. Since these will both be a CanonicalID, this leads to a greeting like: Hello =!F83.62B1.44F.2813. Please confirm
Re: Delegation Proposal Amendment
On 10/6/06, Granqvist, Hans [EMAIL PROTECTED] wrote: Can you propose this in terms of diffs to the current draft so it is glaringly obvious what the proposal means? Sure. Also, I think this diffs to current draft can be most useful for all proposals as it cuts through the various semantic clouds we all have hanging over our heads ;) Do you mean literal Unix-style diffs or a human-readable set of changes to section numbers? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
