Two Identifiers - no caching advantage

[Martin Atkins]

Dick Hardt wrote:
> On 21-Oct-06, at 10:52 PM, Josh Hoyt wrote:
> 
>> On 10/21/06, Dick Hardt <dick at sxip.com> wrote:
>>>         2) the RP does not verify the binding between the portable
>>> identifier and the IdP-specific identifier in the response.
>>>   to the one the attacker controls and the IdP has mapped
>> This is the part where I think you're wrong. The RP MUST verify that
>> binding, whether it is by keeping state, self-signing the request
>> (which gets passed through to the response) or doing discovery again.
> 
> I agree the RP SHOULD do that. The proposal does not specify that.
> I thought we had that conversation. I have not looked at the patch  
> that you sent. Perhaps you address the issue there.
> 
> My point though is: why have the RP bind the IdP-specific identifier  
> and the public identifier? Why not let the IdP be responsible for this?
> 
> In 1.x when the IdP was not aware of the public identifier, then the  
> RP had to do the binding. Now that the IdP is aware of the public  
> identifier, it would be simpler and logical for the IdP to be  
> responsible for the binding. It is doing it anyway.
> 
> All the RP wants is which public identifier is the user, and is the  
> IdP authoritative for it.
> 

If "delegation" is going to require cooperation from the IdP anyway, 
there's no longer any value in having the distinction between a public 
identifier and an IdP-local identifier. The hypothetical IdP 
"IdP-tastic" can just store a relationship between 
http://mart.vanitydomain.com/ and my user account at IdP-tastic. There's 
no need for http://mart.idp-tastic.com/ anymore, and with that gone 
delegation is no longer useful: the public identifier, whatever it might 
be, is the only identifier.

Any disadvantages to uniting the public identifier and the IdP 
identifier are also disadvantages of having the IdP do the "binding" as 
you describe. For simplicity's sake, I'm currently only willing to vote 
positively for one of the following scenarios:

* Have only one identifer in the protocol. Remove delegation entirely. 
IdP maintains relationships between arbitrary identifiers and its local 
user accounts. IdP no longer needs to issue its own identifiers, though 
it can if desired. This makes life simpler for RPs, but has the risk 
that delegation would become an IdP "premium" feature, which may hurt 
users in the long term.

* Protocol has two distinct identifiers: public and IdP-local. Relying 
party manages delegation. IdP does not even know that the delegation has 
taken place and has no way to stop it happening [1]. RP now has to do 
more work, but identifier portability now comes for free.

Having the IdP deal with the public identifier while still keeping the 
IdP-local identifier (and thus delegation) is, it seems to to me, 
muddled nonsense; the whole purpose of delegation was to make these 
identifiers distinct.


[1] Conceivably a mischievous IdP could make use of knowledge of how 
particular RPs round-trip their delegation state to block it, but that 
would be an arms race in the RP's favour rather than a designed-in 
mechanism for detecting delegation.