Yet Another Delegation Thread

Recordon, David drecordon at verisign.com
Wed Oct 25 00:21:55 UTC 2006


What I wrote up doesn't allow a RP to have the information it needs to
maintain state is my understanding.

--David 

-----Original Message-----
From: Dick Hardt [mailto:dick at sxip.com] 
Sent: Tuesday, October 24, 2006 5:12 PM
To: Recordon, David
Cc: specs at openid.net
Subject: Re: Yet Another Delegation Thread

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