Re: Re[2]: Identifier portability: the fundamental issue
On Tue, 2006-10-17 at 13:29 +1000, Chris Drake wrote: Now - how comfortable are you with the idea of letting 1.5 billion Chinese people use OpenID Ideally we'd have the input of the SocialBrain Foundation on that. Those are the folks who put together OpenID.cn. Has anyone on this list talked to them at all? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: Identifier portability: the fundamental issue
Hi Drummond, DR ... if there is any record at all of any association between these DR two identities, ... double-blind anonymous authentication solves this problem. The RP knows nothing more about you besides: A) you're authenticated, and/or B) you've been here before (eg: have signed up for an account) The IdP knows merely C) That you wanted to log in somewhere The RP does not know your ID or even your IdP, and your IdP does not know what site you logged in to. I have a working proof-of-concept that I demonstrated to a few people some months back, let me know if you've not seen it, and I'll send over the URL In a nutshell - this relies on uniform nonce formats and asymmetric cryptography (so the RP and IdP can talk between one another without making any actual contact - the browser and/or user carry the authentication payloads forth and back without referrer URLs or any other info that can link the 2 sites (RP/IdP) together). Besides all that - the normal use case for an IdP in OpenID world (remember: decentralized) will be someone running some open-source code on their own server, so trust in this instance *is* boolean: at least in so far as if there's anything for someone to not be trustworthy about themselves for - it won't be the fault of their IdP code PROVIDING their IdP has provided them with IdP-initiated logins in order to allow this user to protect their own privacy in the first place. Court orders are what I termed 3.5. Authorized exploitation in my threat list, and insider leaks I called 1.3.6. physical attack of server resources (eg: server/hosting-facility compromise) - there's another 98 other threats to keep in mind here as well:- http://chrisdrake.com/Comprehensive_list_of_Threats_to_Authentication_Procedures_and_Data.html While your example might seem extreme, the consequences are also extreme (or fatal, if you live someplace like China) - which is why I take privacy so seriously. Stick Himalayas video into google news if you want to watch what Chinese do to their own people when found trying to visit the Dalai Lama. Now - how comfortable are you with the idea of letting 1.5 billion Chinese people use OpenID without making it easy to help them protect their own privacy ? There's a big picture here, and it's not about meeting some arbitrary deadline or saving a day or two of coding work - it's about producing something that works, and can be deployed ethically. Take a long hard look at that Nun lying dead in the snow, then tell me you still believe there's no need for IdP-initiated privacy protection in OpenID. Kind Regards, Chris Drake, =1id.com Tuesday, October 17, 2006, 7:29:00 AM, you wrote: DR +1. Trust is not a boolean. Martin, that's very quotable. Can I attribute DR it to you? DR =Drummond DR -Original Message- DR From: [EMAIL PROTECTED] DR [mailto:[EMAIL PROTECTED] On Behalf DR Of Martin Atkins DR Sent: Monday, October 16, 2006 12:25 PM DR To: specs@openid.net DR Subject: Re: Identifier portability: the fundamental issue DR Chris Drake wrote: There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. DR If I'm using one IdP to assert my primary public identity, they can DR hypothetically develop quite a profile about me. I probably don't mind DR too much in most cases, because I researched them and found that they DR are a good provider and won't sell my data out to the bad guys. DR However, there might be some things I want to do (for example, posting DR locally-prohibited speech on a public forum) that I don't want attached DR in any way, shape or form to my public identity. The trust relationship DR I have with that IdP probably isn't enough for this; if there is any DR record at all of any association between these two identities, as DR friendly as my IdP may be, there is a chance that it will be ceased by DR court order, or leaked by an insider, which might lead to me getting in DR serious legal trouble. DR This is just one (perhaps extreme) example of why my trust in my IdP is DR not universal and all-encompassing. Trust is not a boolean. DR ___ DR specs mailing list DR specs@openid.net DR http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Re[2]: Identifier portability: the fundamental issue
Chris, I think you may have me mistaken for somebody else on the list (DR is also David Recordon). I'm a big fan of IdP-initiated login and privacy protection in OpenID. However as much as I think that's an important use case, there's also many use cases around using a public, omnidirectional identifier. So OpenID should accommodate both. =Drummond -Original Message- From: Chris Drake [mailto:[EMAIL PROTECTED] Sent: Monday, October 16, 2006 8:29 PM To: Drummond Reed Cc: 'Martin Atkins'; specs@openid.net Subject: Re[2]: Identifier portability: the fundamental issue Hi Drummond, DR ... if there is any record at all of any association between these DR two identities, ... double-blind anonymous authentication solves this problem. The RP knows nothing more about you besides: A) you're authenticated, and/or B) you've been here before (eg: have signed up for an account) The IdP knows merely C) That you wanted to log in somewhere The RP does not know your ID or even your IdP, and your IdP does not know what site you logged in to. I have a working proof-of-concept that I demonstrated to a few people some months back, let me know if you've not seen it, and I'll send over the URL In a nutshell - this relies on uniform nonce formats and asymmetric cryptography (so the RP and IdP can talk between one another without making any actual contact - the browser and/or user carry the authentication payloads forth and back without referrer URLs or any other info that can link the 2 sites (RP/IdP) together). Besides all that - the normal use case for an IdP in OpenID world (remember: decentralized) will be someone running some open-source code on their own server, so trust in this instance *is* boolean: at least in so far as if there's anything for someone to not be trustworthy about themselves for - it won't be the fault of their IdP code PROVIDING their IdP has provided them with IdP-initiated logins in order to allow this user to protect their own privacy in the first place. Court orders are what I termed 3.5. Authorized exploitation in my threat list, and insider leaks I called 1.3.6. physical attack of server resources (eg: server/hosting-facility compromise) - there's another 98 other threats to keep in mind here as well:- http://chrisdrake.com/Comprehensive_list_of_Threats_to_Authentication_Proced ures_and_Data.html While your example might seem extreme, the consequences are also extreme (or fatal, if you live someplace like China) - which is why I take privacy so seriously. Stick Himalayas video into google news if you want to watch what Chinese do to their own people when found trying to visit the Dalai Lama. Now - how comfortable are you with the idea of letting 1.5 billion Chinese people use OpenID without making it easy to help them protect their own privacy ? There's a big picture here, and it's not about meeting some arbitrary deadline or saving a day or two of coding work - it's about producing something that works, and can be deployed ethically. Take a long hard look at that Nun lying dead in the snow, then tell me you still believe there's no need for IdP-initiated privacy protection in OpenID. Kind Regards, Chris Drake, =1id.com Tuesday, October 17, 2006, 7:29:00 AM, you wrote: DR +1. Trust is not a boolean. Martin, that's very quotable. Can I attribute DR it to you? DR =Drummond DR -Original Message- DR From: [EMAIL PROTECTED] DR [mailto:[EMAIL PROTECTED] On Behalf DR Of Martin Atkins DR Sent: Monday, October 16, 2006 12:25 PM DR To: specs@openid.net DR Subject: Re: Identifier portability: the fundamental issue DR Chris Drake wrote: There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. DR If I'm using one IdP to assert my primary public identity, they can DR hypothetically develop quite a profile about me. I probably don't mind DR too much in most cases, because I researched them and found that they DR are a good provider and won't sell my data out to the bad guys. DR However, there might be some things I want to do (for example, posting DR locally-prohibited speech on a public forum) that I don't want attached DR in any way, shape or form to my public identity. The trust relationship DR I have with that IdP probably isn't enough for this; if there is any DR record at all of any association between these two identities, as DR friendly as my IdP may be, there is a chance that it will be ceased by DR court order, or leaked by an insider, which might lead to me getting in DR serious legal trouble. DR This is just one (perhaps extreme) example of why my trust in my IdP is DR not universal and all-encompassing. Trust is not a boolean. DR ___ DR specs mailing list
Re[2]: Identifier portability: the fundamental issue
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
Re: Re[2]: Identifier portability: the fundamental issue
On 14-Oct-06, at 7:28 AM, Chris Drake wrote: 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. NOTE: There are instances when the user will WANT the RPs to know they are the same user across sites. Right now my reputation on a site is locked into that site. No other site can know that I have done things on other sites, so that I can go to a new site and take my reputation with me. Real world example: when I give a talk, I use the same identifier so that people know it is me. I use the same email on different mailing lists so people know it is the same person. 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.). I completely agree. This was the major issue Sxip had with OpenID 1.x. The user had to identify themselves with no assistance from their IdP, and hence no support for directed identity. 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. As we are building and testing software, it is interesting as to what become the common cases. More later. :-) 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? Yes, these things do need to be addressed. Would be great to get additional seasoned security gurus to review and comment. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
