Hi Josh, >> I do not believe the RP needs to know the IdP-specific identifier ever >> (worse: I think it should never be allowed to know it, or even be >> allowed to see it!).
JH> Why not? PRIVACY. Page back and read trough my posts to this list for the intricate details. JH> Where is power being granted to the RP? It has pretty much none. JH> It *does* have responsibility, but only as much as is necessary to JH> make the protocol work. If RPs are allowed to build up linked portfolios of everyones identifiers, they can get together with other RPs (or sniff IDs in google) to snoop on and conspire against our users behind their backs. If the true spirit of OpenID is to empower users, it's seriously neglectful to block users from protecting their own privacy. >> Can we not adopt my earlier suggestion: just ensure OpenID can permit >> IdP-initiated logins. This permits every scenario of portability (and >> privacy) that everyone wants, without us having to continue to debate >> it ? JH> Huh? How is IdP-initiated login related to privacy or portability? It is ** NONE OF THE RPs BUSINESS ** how the OpenID that got presented to it was originally selected by, or resolved for, our Users. Letting the IdP initiate a login allows the IdP to PRIVATELY negotiate with the user over which identity to present (which for anyone who cares about privacy, will usually be a per-site identity not linked to their main OpenID or vanity domain or whathaveyou.). The beauty of this suggestion is that we don't even need to debate it: so long as IdP initiated logins are supported, market forces will then decide whether or not privacy and security become widespread in OpenID. I'm not saying this should be the *only* way an OpenID login can take place - just that if this simple concept is implemented, that we can then defer all privacy issues to the IdPs in future, and concentrate now on getting this spec out the door. -- I notice the current spec: http://openid.net/specs/openid-authentication-2_0-10.html does not even *mention* privacy? (besides the allusion in the abstract: "It does this without the Relying Party needing access to password, email address, or other sensitive information." - but somehow nobody's understanding that the users OpenID *itself* is "sensitive information", especially in the way google will in future let anyone troll back through our users online "tracks" using this ID...) Also missing are 16. Security Considerations and 16.1. Preventing Attacks Perhaps someone should add a section on privacy, and someone should take a crack at the security aspects! Who is in charge of writing this stuff? I've submitted 102 (one hundred and two!!!) security considerations in the posts I've made to this list so far: Shouldn't someone be documenting this? Chris. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
