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