Re[2]: Consolidated Delegate Proposal

2006-10-11 Thread Chris Drake

 Martin wrote:
 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.)

Dick wrote:

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.

Wednesday, October 11, 2006, 4:42:35 AM, Drummond wrote:
DR The same argument convinced me, too. If public XRDS documents are what we're
DR using to provide user control of identifier synonyms and thus provide
DR identifier portability -- which is the clearest and cleanest approach we've
DR seen -- then the best thing we can do from a privacy perspective is not
DR mislead users that they are protecting their privacy by using a public
DR OpenID identifier and a private identifier with their IdP.
DR =Drummond

This is backwards:  Users have already chosen the IdP whom they trust
to look after their identity and privacy:  and except for the unlikely
double-blind scenarios, no user will want to hide RP info and usage
from their own IdP.

The privacy violations come into effect when the *RP* is given access
to any more information than it strictly needs to know to accomplish
its task.

Might I suggest a fast-track approach to tabling the core requirements
for OpenID 2.0 and bypassing the debate: lets just identify exactly
what everyone wants to achieve, make sure the proposed protocol can
support everything everyone wants to do - then leave it up to the RPs
and IdP's as to which features they feel like supporting.

Nobody knows in advance whether privacy or delegation or any other
feature is going to succeed in the marketplace, so I feel it's better
to accommodate it, then let the market decide.

The bottom line is that we're spending months arguing over what will
end up to be a few days work and a couple of hundred lines of code.

The only thing I want to see, which can then be used to accommodate
privacy protection, is for RP's to accept an IdP-initiated login.
It's none of the RPs business how my user selected their
openid.identity for presentation to the RP.

Chris.

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Re[2]: Consolidated Delegate Proposal

2006-10-11 Thread Dick Hardt
+1

Well said Chris.

On 10-Oct-06, at 11:22 PM, Chris Drake wrote:


 This is backwards:  Users have already chosen the IdP whom they trust
 to look after their identity and privacy:  and except for the unlikely
 double-blind scenarios, no user will want to hide RP info and usage
 from their own IdP.

 The privacy violations come into effect when the *RP* is given access
 to any more information than it strictly needs to know to accomplish
 its task.

 Might I suggest a fast-track approach to tabling the core requirements
 for OpenID 2.0 and bypassing the debate: lets just identify exactly
 what everyone wants to achieve, make sure the proposed protocol can
 support everything everyone wants to do - then leave it up to the RPs
 and IdP's as to which features they feel like supporting.

 Nobody knows in advance whether privacy or delegation or any other
 feature is going to succeed in the marketplace, so I feel it's better
 to accommodate it, then let the market decide.

 The bottom line is that we're spending months arguing over what will
 end up to be a few days work and a couple of hundred lines of code.

 The only thing I want to see, which can then be used to accommodate
 privacy protection, is for RP's to accept an IdP-initiated login.
 It's none of the RPs business how my user selected their
 openid.identity for presentation to the RP.

 Chris.



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs