Yet Another Delegation Thread

Dick Hardt dick at sxip.com
Wed Oct 25 00:12:04 UTC 2006


Can we have those conversations on the list so that everyone  
understands what the goals missed are?

I'd appreciate feedback on the revised proposal I emailed out and  
what is missing from it.

-- Dick

On 24-Oct-06, at 3:45 PM, Recordon, David wrote:

> I honestly wasn't really putting it out as a proposal, rather  
> describing
> more of the different cases involved in all of this.  In any case,
> talking this over more with Josh and Drummond it doesn't actually
> accomplish all of the goals anyway.
>
> --David
>
> -----Original Message-----
> From: Dick Hardt [mailto:dick at sxip.com]
> Sent: Monday, October 23, 2006 11:04 PM
> To: Drummond Reed
> Cc: Recordon, David; specs at openid.net
> Subject: Re: Yet Another Delegation Thread
>
> +1
>
> Glad to see that we have settled on one identifier parameter
>
> On 23-Oct-06, at 7:07 PM, Drummond Reed wrote:
>
>> Here's another way to summarize the conclusions David and I  
>> reached in
>
>> our analysis today:
>>
>> 1) In OpenID Authentication 1.1, if there is a difference between the
>> identifier the user wants to assert to an RP and the identifier the
>> IdP wants to assert for the user (lets just call them ID1 and ID2),
>> then the mapping from ID1 to ID2 can only be handled by the RP (using
>> the OpenID delegate feature).
>>
>> 2) Josh and Mart have argued that in OpenID Authentication 2.0 an IdP
>> should also be able to handle the mapping between ID1 and ID2, and
>> indeed in the directed identity use case, the IdP MUST handle this
>> mapping.
>>
>> 3) What David and I realized today is that there are even use cases
>> for BOTH the RP and IdP doing the mapping. In other words, even if an
>> RP maps from
>> ID1 to ID2 and passes ID2 to the IdP, there shouldn't be anything to
>> prevent the IdP from mapping ID2 to ID3 and passing ID3 back to  
>> the RP
>
>> (as long as the RP verifies the IdP is authoritative for ID3).
>> Example: I log into RP using one URI#1, which maps in my XRDS  
>> document
>
>> to another IdP- specific URI#2, and then when logging into my IdP it
>> reminds me that I previously used URI#3 at this RP, so I choose  
>> URI#3.
>>
>> 4) Therefore, as long as the protocol: a) REQUIRES the RP to do the
>> mapping from ID1 to ID2 if present in the HTML or XRDS (which gives
>> the user IdP-independent mapping if the user wants it), and b) ALLOWS
>> the IdP to do the mapping from whatever identifier it receives  
>> (ID1 or
>
>> ID2) to whatever identifier it wants to assert on behalf of the user
>> (ID3), then all use cases are supported. A user can take advantage of
>> RP mapping, IdP mapping, or both.
>>
>> 5) This flexibility means that, with the rules David wrote, only one
>> identifier parameter should be needed (although, as David suggests, a
>> second parameter that is only a display hint from the RP to the IdP
>> might be a help
>> -- and I would argue that it could work in the other direction as 
>> well, but again only as a display hint.)
>>
>> =Drummond
>>
>> -----Original Message-----
>> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
>> Behalf Of Recordon, David
>> Sent: Monday, October 23, 2006 6:09 PM
>> To: specs at openid.net
>> Subject: Yet Another Delegation Thread
>>
>> So been going through all of this up in Seattle with Drummond and
>> think I fully have my head around this.
>>
>> Thinking we have the following cases, which Draft 10 basically  
>> already
>
>> addresses.  In any of the responses, the IdP MAY return a differing
>> value for "openid.identity" than the RP requested.  This obviously  
>> has
>> varying degrees of usefulness depending on the specific situation.
>> See
>> below for "rules" RP must follow to protect itself from bogus
>> assertions.
>>
>> 1) IdP Registered
>> 	a) Entered http://user.myidp.com   (IdP implicitly knows it
>> owns)
>>             <URI> -> http://myidp.com/server.cgi
>>
>>          Request
>>             openid.identity -> http://user.myidp.com
>>          Response
>>             openid.identity -> http://user.myidp.com
>>
>> 	b) Entered http://user.example.com (IdP has an out of band
>> "registration" process where it verifies via discovery)
>>             <URI> -> http://myidp.com/server.cgi
>>
>>          Request
>>             openid.identity -> http://user.example.com
>>          Response
>>             openid.identity -> http://user.example.com
>>
>> 2) Delegated (IdP knows nothing about what the user entered)
>> 	a) Entered http://user.example.com
>>             <URI>             -> http://myidp.com/server.cgi
>>             <OpenID:Delegate> -> http://user.myidp.com (IdP
>> Controlled)
>>
>>          Request
>>             openid.identity -> http://user.myidp.com
>>          Response
>>             openid.identity -> http://user.myidp.com
>>
>> 	b) Entered =user.example (or @2idi for Directed Identity case)
>>             <URI>             -> http://myidp.com/server.cgi
>>             <OpenID:Delegate> -> http://user.myidp.com (IdP
>> Controlled)
>>
>>          Request
>>             openid.identity -> iNumber (LocalID ? <LocalID /> :
>> <CanonicalID />)
>>          Response
>>             openid.identity -> iNumber
>>
>> 3) Directed Identity
>>       Entered http://myidp.com (IdP Registered)
>>             <URI>  -> http://myidp.com/server.cgi
>>             <Type> -> http://openid.net/identifier_select/2.0
>>
>>       Request
>>             openid.identity -> http://openid.net/identifier_select/ 
>> 2.0
>>       Response
>>             openid.identity -> http://user.myidp.com (IdP Registered,
>> though not necessarily on same domain)
>>
>>
>> I would argue, that this actually accomplishes what is needed;
>> providing the following rules:
>> 1) Before starting a transaction, the RP MUST validate that the  
>> IdP is
>
>> authoritative for the URI it is requesting an assertion about through
>> the discovery process.
>>
>> 2a) If the RP ever receives a response value from IdP differing in  
>> the
>
>> URI assertion it requested, it MUST validate that the IdP is
>> authoritative for that URI via the discovery process.  This is due to
>> that the IdP's response value for "openid.identity" does not have to
>> be the same as the RP's request value in any of these three cases.
>>
>> 2b) In the Directed Identity case, the RP MUST always validate that
>> the IdP is authoritative for the URI returned in its assertion via  
>> the
>
>> discovery process.
>>
>> So the one time that an additional parameter is useful, is in the
>> Delegated Case where it would be useful to the IdP to know what the
>> user entered at the RP.  This has certain privacy implications,  
>> though
>
>> most of the data is public to begin with in terms of the HTML/XRDS
>> semantics.
>> There also is the concern that since the IdP is signing the response,
>> it would have to also check that it is authoritative over this other
>> parameter.  If this is still a design goal, I'd propose we add
>> "openid.display" (or whatever we want to call it) which the RP sends
>> in the request solely to aid the IdP when interacting with the user.
>> The IdP would then still make an assertion about the value of
>> "openid.identity" and thus not return "openid.display" in the
>> response.
>> This thus continues placing the burden on the RP to verify all of the
>> assertions made in the protocol.
>>
>> In the end this remains backwards compatible with 1.x, though also
>> broadens the delegation model as Josh and Mart have previously
>> described.  This also places no additional burden on the IdP,  
>> since in
>
>> every case the RP is responsible for verifying that the IdP is
>> authoritative for the assertion made.  While the IdP should not make
>> assertions that are not true, at the end of the day the RP should be
>> verifying the validity of every assertion in any case to protect
>> itself.
>>
>> --David
>> _______________________________________________
>> 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