Yet Another Delegation Thread
Drummond Reed
drummond.reed at cordance.net
Wed Oct 25 01:16:04 UTC 2006
First, just to make sure intentions are clear, the conversation that David
and I had yesterday (because he happened to be in Seattle) and the
subsequent conversation that David and Josh and I had today (because Josh
had questions about what we posted) were meant only to try to better
understand the issue, not take anything offline. I personally believe that
the remaining 2.0 issues need to be resolved primarily via telecons because
they have proved themselves too hard to work out in email (the XRI TC holds
2 hour telecons weekly almost entirely for this purpose). David and Josh and
I agreed that our discussions today were all preliminary to the telecon(s)
the editors have already agreed to do starting this week.
For this reason I'm hesitant to write anything further on this thread. But
However I'll try to answer Dick's question as succinctly as I can:
* Dick's proposal defined two different identifier parameters, but sent only
one or the other on the wire depending on the initial conditions at the RP.
* David's writeup yesterday also proposed sending only a single identifier
parameter on the wire that would fulfill both "roles" that Dick's two
identifier parameters filled.
* But in our discussion today, Josh and David and I boiled down the
fundamental problem with the "single identifier on the wire" solutions: as
long as the RP has the ability to do the mapping between the Claimed
Identifier and an IdP-specific Identifier (and there are many good reasons
to allow the RP to do this mapping, including that this is how OpenID 1.1
works), then sending only one of these two identifiers on the wire to the
IdP shuts down an option the IdP and/or user should have. To wit:
- If only the Claimed Identifier is sent, the IdP is forced to repeat
discovery if it doesn't recognize it (Josh and David and I believe the IdP
should not be forced to repeat discovery - it is not required in OpenID 1.1
and should not be required in OpenID 2.0).
- If only the IdP-specific Identifier is sent, then the IdP does not have
the option to assist the user with identifier selection based on the Claimed
Identifier (which is required for directed identity anyway, and is one of
the motivations behind this whole thread).
Our conclusion was that the only way to avoid shutting down one or the other
of these options is to allow (but not force) the RP to send both identifiers
using two parameters, and to have the IdP return both parameters, which the
RP must always verify based on its own discovery.
That's the "state of the state" as of our discussion this afternoon.
Hopefully this will be helpful input into the editor's call(s) this week.
=Drummond
-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Dick Hardt
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
>>
>>
>
>
>
_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs
More information about the specs
mailing list