Yet Another Delegation Thread

[Dick Hardt]

On 25-Oct-06, at 11:24 AM, Drummond Reed wrote:

>>> On 25-Oct-06, at 8:57 AM, Drummond Reed wrote:
>>>
>>> Sure, Dick, here's the list of reasons that Josh and David and I
>>> discussed
>>> for allowing the RP to do the mapping between a Claimed  
>>> Identifier and
>>> IdP-Specific Identifier:
>>>
>>> 1) The first is the reason Brad designed this mechanism in the
>>> first place
>>> -- it allows the user to control the binding of their Claimed  
>>> Identifier
>>> (the portable identifier the user controls) to an IdP-Specific
>>> Identifier
>>> (which the IdP controls). This means the user doesn't have to
>>> register their
>>> Claimed Identifier with the IdP (which may not even be possible  
>>> -- for
>>> example, LiveJournal may only recognize you by your LiveJournal
>>> login name,
>>> but you can get still use them as your IdP by pointing your vanity
>>> domain
>>> name at your LiveJournal blog page). This also prevents IdP
>>> "lockin" on a
>>> Claimed Identifier.
>>
>> this is done with the current method, correct? in this case, you only
>> send the IdP specific identifier
>
> It's true the IdP-Specific Identifier is the only one the RP MUST  
> send.
> However Josh pointed out that if the RP also has the OPTION of  
> sending the
> Claimed Identifier, the IdP can then offer the user more context- 
> sensitive
> options about the response. For example, as you have pointed out  
> earlier, I
> could login to an RP with ID1, have that map in my XRDS to IdP- 
> Specific ID2,
> but then have my IdP remind my that the last time I was at that RP,  
> I used
> ID3, which the IdP can only highlight as different than ID1 if it  
> knows ID1.

<click> now I understand the use case (there are a couple in here)

*if* the RP does not want the IdP to know about the portable  
identifier, then the RP sends the IdP-specific  identifier.

Otherwise the RP only needs to send the portable identifier. The IdP  
can do disco and map that to the IdP specific identifier.

Per comments below, the public identifier is what I think should be  
sent around, with sending the IdP-specific identifier being available  
for backward compatibility and potential privacy. This is what lead  
me to having the existing name having the existing functionality, and  
a new name for the new functionality.

>
>>> 2) Since the RP has to do discovery on the Claimed Identifier
>>> anyway, if it
>>> discovers a mapping between the Claimed Identifier and an IdP- 
>>> Specific
>>> Identifier, the RP can send the IdP-Specific Identifier to the IdP
>>> and save
>>> the IdP from having to repeat discovery.
>>
>> unfortunately that disco information could be modified in route, so
>> the IdP can't trust it
>
> This seems to be an area of persistent disagreement. When Josh and  
> David and
> I went back over this yesterday, our conclusion was that in order  
> to be
> stateless (and eventually support "bare requests"), an RP must  
> ALWAYS verify
> any IdP response against the RP's own discovery.

correct, completely agree the RP MUST verify IdP response to the RP's  
own disco

  (although I am confused with "bare requests", that would be from  
the RP to the IdP n'est pas?)

> Thus our conclusion was that when an IdP receives an IdP-Specific
> Identifier, it can always respond directly without needing to  
> repeat disco
> on the Claimed Identifier.

correct, and the RP is wanting to keep the public identifier used to  
be secret from the IdP, otherwise the RP can send the public identifier

>
>
>>> 3) Allowing the user to control Claimed
>>> Identifier-to-IdP-Specific-Identifier mapping gives the user the
>>> ability to
>>> establish any number of OpenID "synonyms" that do not require any
>>> involvement on the part of the IdP. In many ways this is the user-
>>> facing
>>> compliment of the directed identity value proposition: in directed
>>> identity,
>>> the user can have the IdP create any number of pseudonyms for
>>> different RPs.
>>> But the user is dependent on the IdP for this functionality. With
>>> Claimed
>>> Identifier-to-IdP-Specific-Identifier mapping, the user controls  
>>> which
>>> Claimed Identifier maps to which IdP-Specific-Identifier, and is NOT
>>> dependent on the IdP for this mapping (which means it is entirely
>>> portable).
>>
>> I read this a couple times and don't understand what is different
>> between it and (1) above ...
>
> It's just a broader reason for (1).
>
>>> Hope this helps,
>>
>> It does, but also confirms my thinking that one identifier works  
>> fine.
>
> By "one identifier", I believe you mean that the RP need only send  
> either:
> a) the Claimed Identifier if there is no IdP-Specific Identifier,  
> or b) the
> IdP-Specific Identifier if it exists. And that the IdP need only  
> respond
> about the one identifier that was sent.
>
> As I understand it at this point, there are two features this  
> approach does
> not support:
>
> 1) If the RP sends only an IdP-Specific Identifier, and the IdP  
> responds
> only about the IdP-Specific Identifier (which is the way OpenID 1.x  
> works),
> the the RP is forced to keep state because the identifier the RP  
> needs is
> the Claimed Identifier, not the IdP-Specific Identifier (and the RP  
> cannot
> discover the Claimed Identifier from the IdP-Specific Identifier).
>
> 2) If the RP sends only the IdP-Specific Identifier, the IdP does  
> not have
> any context with which to assist the user in their ultimate  
> decision about
> which Claimed Identifier to give the RP.
>
> Sending both identifiers (when the RP discovers both) enables both  
> of these
> features.

This explanation is what I was looking for, thanks.

The only motivation for the RP to send the IdP-Specific identifier is  
if the RP does not want the IdP to know which identifier the user is  
using, so sending the public identifier defeats that motivation.

If the RP sends the public identifier, the IdP can do disco to find  
the IdP-specific identifier, and even if it is the right one.

Given that the IdP may return a completely different identifier then  
the one the RP sent, the IdP-specific identifier in a response would  
be meaningless if it did not match the public identifier the user chose.

Related point:

If the response contains both the IdP-specific identifier, and the  
public identifier, then they BOTH should be valid identifiers. In  
other words, the IdP is signing this response saying that the user is  
both of these. Since the RP MUST verify the IdP response (per your  
comment above) the RP only needs the public identifier, since that is  
the one that the RP is using, and all the RP needs to do is check if  
the IdP is authoritative for the public identifier. Having both  
identifiers in the response has always been problematic for me since  
it implies the IdP is making a statement about both, and it does not  
need to, and if the user has selected a different identifier, the  
values won't match what the RP sent anyway.

Thanks again for taking the time to clarify your points Drummond.  
Good background for the editors con call.

-- Dick