Yet Another Delegation Thread

Drummond Reed drummond.reed at cordance.net
Wed Oct 25 18:24:04 UTC 2006


>> 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.

>> 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.

In our analysis (leaving the other DNS/TLS security issues aside), this
would defeat any attack based on either a malicious IdP (trying to verify a
Claimed Identifier for which it's not actually authoritative), or a MITM
(trying to switch out either the Claimed Identifier or the IdP-Specific
Identifier).

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.


>> 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.

=Drummond 





More information about the specs mailing list