Consolidated Delegate Proposal

[Martin Atkins]

Josh Hoyt wrote:
> On 10/10/06, Martin Atkins wrote:
>> Does the IdP really need to know what URL I gave to the RP?
>>
>> Earlier versions handled this adequately by the library including
>> implementer-defined variables in the return_to URL, which allows a
>> stateful RP to hide the real identifier behind a meaningless session
>> token, which satisfies Brad's criteria that the RP should be able to
>> hide from the IdP the fact that delegation is in use.
> 
> see [1] where I addressed this question. I think that the benefits of
> having it there outweigh the benefit of hiding your identifier *from
> your chosen IdP*. The benefits for having it available to the IdP are
> the same as the benefits outlined in [2].
> 

Trusting the IdP to do one thing (authenticate you) does not imply that 
you trust the IdP to do all things (for example, to know the identifier 
you used on a particular site.)

While it's true that the IdP will know what RPs you have been signing 
into (based on the return_to URLs) it will not necessarily be able to 
track *what you do* on that site unless it knows what identifier you 
used there. In sensitive situations, one can use a throw-away identifier 
that resolves only once and which only the RP need know about without 
IdP involvement.

Giving each party only the information it absolutely requires is a good 
general design principle, in my opinion.

I'm not convinced that the directed identity case needs to work with 
delegated identifiers, but even still there's nothing to stop an IdP 
from giving the user the *option* of disclosing their delegated 
identities through a configuration setting, thus giving the user the 
choice about whether to trust the IdP with this information.

I'm surprised that our resident privacy advocates aren't making a bigger 
deal out of this. (If the privacy advocates have no problem then I'll 
let this go, since this isn't a use case I feel particularly strongly 
about myself.)