RE: Delegation Proposal Amendment
> ... > Revised Proposal > > > As it stands, "openid.identity" is the identifier by which > the IdP knows the user. There is no parameter by which the RP > knows the user. > > I propose to add a field called "openid.rp_user_id" in > "checkid_*" and "id_res" that defaults to "openid.identity" > if it is missing. This field is the identifier by which the > relying party knows the user. > ... Josh, Can you propose this in terms of diffs to the current draft so it is glaringly obvious what the proposal means? 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 ;) Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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
RE: Delegation Proposal Amendment
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 (http://openid.net/server/2.0), 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 =drummond.reed. Please confirm that you want to login to YourFavoriteRP. [Allow Once] [Allow Always] [Cancel] Better still, this functionality is not limited to XRIs. RPs can apply it to any User just by prompting the user for a preferred Display Name along with their OpenID identifier. Then the RP can send the Display Name as the UPI string so the IdP can call the user by the same name. For example: Hello Drummond. Please confirm that you want to login to YourFavoriteRP. [Allow Once] [Allow Always] [Cancel] So this boils down to a simple proposed amendment to your amendment: PROPOSED AMENDMENT: Add a third optional parameter, openid.display, the value of which is the UPI. The rules governing its use: 1) If the RP DOES NOT send openid.display, it defaults to openid.rp_user_id. (And by your amendment, if RP does not send openid.rp_user_id, then it defaults to openid.identity). 2) If the RP prompts the User for a Display Name for an OpenID identifier, the RP SHOULD set the value of openid.display to the UTF-8 encoded value of the display name string. 3) If the RP does not prompt the User for a Display Name (or if the User does not supply one), but if UPI is an i-name, the RP SHOULD send the i-name as the openid.display value. =Drummond
RE: Delegation Proposal Amendment
> Do you mean literal Unix-style diffs or a human-readable set > of changes to section numbers? I'd personally prefer the former, but I would settle for the latter. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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 > (http://openid.net/server/2.0), 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 =drummond.reed. Please confirm that you want to login > to YourFavoriteRP. [Allow Once] [Allow Always] [Cancel] > > Better still, this functionality is not limited to XRIs. RPs can > apply it to > any User just by prompting the user for a preferred Display Name > along with > their OpenID identifier. Then the RP can send the Display Name as > the UPI > string so the IdP can call the user by the same name. For example: > > Hello Drummond. Please confirm that you want to login > to YourFavoriteRP. [Allow Once] [Allow Always] [Cancel] > > So this boils down to a simple proposed amendment to your amendment: > > PROPOSED AMENDMENT: Add a third optional parameter, openid.display, > the > value of which is the UPI. The rules governing its use: > > 1) If the RP DOES NOT send openid.display, it defaults to > openid.rp_user_id. > (And by your amendment, if RP does not send open
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 > (http://openid.net/server/2.0), 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) >
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 >> (http://openid.net/server/2.0), 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 >> >>
