Consolidated Delegate Proposal

Dick Hardt dick at sxip.com
Tue Oct 10 18:32:12 UTC 2006


On 10-Oct-06, at 11:26 AM, Martin Atkins wrote:

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

perhaps, but it likely will

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

I would envision that the IdP would be creating that throw away  
identifier. How would you propose it is created?

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

agreed, one of Kim's laws

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

I was supportive of keeping the delegate from the IdP until I  
realized that the delegation was public knowledge and could not be  
hidden from the IdP.




More information about the specs mailing list