Delegation Proposal Amendment

Dick Hardt dick at sxip.com
Mon Oct 9 21:55:51 UTC 2006


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:dick at sxip.com]
> Sent: Monday, October 09, 2006 2:21 PM
> To: Drummond Reed
> Cc: 'Josh Hoyt'; specs at 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
>> (<Type>http://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 =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
>>
>>
>> -----Original Message-----
>> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
>> Behalf
>> Of Josh Hoyt
>> Sent: Friday, October 06, 2006 11:41 AM
>> To: specs at openid.net
>> Subject: Delegation Proposal Amendment
>>
>> I'd like to amend my proposal for changing the delegation mechanism:
>>
>> 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.
>> This is the identifier on which discovery was performed by the  
>> relying
>> party.
>>
>> The name "openid.rp_user_id" is not the best, but it *is* very
>> specific. Other suggestions welcome.
>>
>> Benefits
>> ========
>>
>> This proposal retains the current behaviour in terms of who is
>> responsible for discovery and verification. It makes the messages
>> between the RP and IdP more explicit. It is completely
>> backwards-compatible. IdP-driven identifier selection can now  
>> return a
>> delegated identifier (if the user wishes to do so).
>>
>> Drawbacks
>> =========
>>
>> The IdP now has knowledge of the identifier that the user entered at
>> the relying party.
>>
>> Discussion
>> ==========
>>
>> I think there is general agreement that the protocol messages on the
>> wire can lead to confusing results. I also think that it's easy to  
>> get
>> the relying party implementation wrong because it has to keep  
>> track of
>> state to ensure that the user gets the right identifier. I don't  
>> think
>> that most relying parties will have a problem keeping state, but I
>> think it's not a good idea to make proper behavior (using the right
>> identifier) *depend* on the relying party's implementation of state
>> storage.
>>
>> This proposal is similar in spirit to Martin's proposal, in that it
>> acknowledges that delegation is not really a special case. The main
>> difference is that (a) it is obvious from the protocol messages what
>> is going on and (b) discovery is entirely unchanged.
>>
>> Related threads
>> ===============
>>
>> Original proposal:
>>   http://openid.net/pipermail/specs/2006-September/000002.html
>>
>> Brad's explanation of openid.delegate:
>>   http://openid.net/pipermail/specs/2006-October/000182.html
>>
>> Regarding the purpose of delegation:
>>   http://openid.net/pipermail/specs/2006-October/000170.html
>>
>> Martin's similar proposal:
>>   http://openid.net/pipermail/specs/2006-October/000216.html
>>
>>
>> Josh
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>
>
>
>




More information about the specs mailing list