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: Identifier portability: the fundamental issue
Drummond Reed wrote: > I think you may have me mistaken for somebody else on the list (. . .) Double-blind anonymity in action? ;) -Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 16-Oct-06, at 12:24 PM, Martin Atkins wrote: > 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. >> > > If I'm using one IdP to assert my primary public identity, they can > hypothetically develop quite a profile about me. I probably don't mind > too much in most cases, because I researched them and found that they > are a good provider and won't sell my data out to the bad guys. > > However, there might be some things I want to do (for example, posting > locally-prohibited speech on a public forum) that I don't want > attached > in any way, shape or form to my public identity. The trust > relationship > I have with that IdP probably isn't enough for this; if there is any > record at all of any association between these two identities, as > friendly as my IdP may be, there is a chance that it will be ceased by > court order, or leaked by an insider, which might lead to me > getting in > serious legal trouble. > > This is just one (perhaps extreme) example of why my trust in my > IdP is > not universal and all-encompassing. Trust is not a boolean. A possible solution is you can use a different IdP when you want to do this activity so there is no link to your primary IdP. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[4]: Identifier portability: the fundamental issue
Hi Drummond, Yikes! - sorry about the misquote - very clumsy of me. Kind Regards, Chris Drake ___ 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>
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: Identifier portability: the fundamental issue
+1. "Trust is not a boolean." Martin, that's very quotable. Can I attribute it to you? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Monday, October 16, 2006 12:25 PM To: specs@openid.net Subject: Re: Identifier portability: the fundamental issue 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. > If I'm using one IdP to assert my primary public identity, they can hypothetically develop quite a profile about me. I probably don't mind too much in most cases, because I researched them and found that they are a good provider and won't sell my data out to the bad guys. However, there might be some things I want to do (for example, posting locally-prohibited speech on a public forum) that I don't want attached in any way, shape or form to my public identity. The trust relationship I have with that IdP probably isn't enough for this; if there is any record at all of any association between these two identities, as friendly as my IdP may be, there is a chance that it will be ceased by court order, or leaked by an insider, which might lead to me getting in serious legal trouble. This is just one (perhaps extreme) example of why my trust in my IdP is not universal and all-encompassing. Trust is not a boolean. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 16-Oct-06, at 2:01 PM, Josh Hoyt wrote: > On 10/16/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: >> In this case you are better off opening a separate account with this >> or some other IdP. The current delegation model will not protect you >> at all. The delegate tag is in a publicly accessible Yadis document. >> >> I agree that anonymity is an important feature, but the current >> solution gives you only a false sense of security. > > What's "the current solution" that you're talking about? As far as I draft 10, the delegate tag in the Yadis document and the RP sending only the delegate id to the IdP > know, no one is suggesting portable identifiers as a way to achieve > anonymity. I also do not think anyone is suggesting that IdP-driven > identifier selection will make you anonymous *to the IdP.* Right, but many people seem to be under the impression that this delegate tag (or hiding the portable id from the IdP) will give you some security or anonymity. I am not saying that this was the original intent or that this is one of the goals. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 10/16/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote: > In this case you are better off opening a separate account with this > or some other IdP. The current delegation model will not protect you > at all. The delegate tag is in a publicly accessible Yadis document. > > I agree that anonymity is an important feature, but the current > solution gives you only a false sense of security. What's "the current solution" that you're talking about? As far as I know, no one is suggesting portable identifiers as a way to achieve anonymity. I also do not think anyone is suggesting that IdP-driven identifier selection will make you anonymous *to the IdP.* You are correct that in order to avoid anyone knowing the identifiers that you use, you have to have separate accounts on different IdPs. I can't come up with any way that the protocol can help (or impede!) the user with achieving this. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 16-Oct-06, at 12:24 PM, Martin Atkins wrote: > 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. >> > > If I'm using one IdP to assert my primary public identity, they can > hypothetically develop quite a profile about me. I probably don't mind > too much in most cases, because I researched them and found that they > are a good provider and won't sell my data out to the bad guys. > > However, there might be some things I want to do (for example, posting > locally-prohibited speech on a public forum) that I don't want > attached > in any way, shape or form to my public identity. The trust > relationship > I have with that IdP probably isn't enough for this; if there is any > record at all of any association between these two identities, as > friendly as my IdP may be, there is a chance that it will be ceased by > court order, or leaked by an insider, which might lead to me > getting in > serious legal trouble. In this case you are better off opening a separate account with this or some other IdP. The current delegation model will not protect you at all. The delegate tag is in a publicly accessible Yadis document. I agree that anonymity is an important feature, but the current solution gives you only a false sense of security. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
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. > If I'm using one IdP to assert my primary public identity, they can hypothetically develop quite a profile about me. I probably don't mind too much in most cases, because I researched them and found that they are a good provider and won't sell my data out to the bad guys. However, there might be some things I want to do (for example, posting locally-prohibited speech on a public forum) that I don't want attached in any way, shape or form to my public identity. The trust relationship I have with that IdP probably isn't enough for this; if there is any record at all of any association between these two identities, as friendly as my IdP may be, there is a chance that it will be ceased by court order, or leaked by an insider, which might lead to me getting in serious legal trouble. This is just one (perhaps extreme) example of why my trust in my IdP is not universal and all-encompassing. Trust is not a boolean. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
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. My assumption (which I am careful to not proclaim as truth) is that there won't be many IDPs around once the OpenID dust settles. Sure, there will be the run-in-the-basement ones, but for business-critical needs an IDP must spend a lot of money: maintain provable privacy of data, keep uptime, supply enriched services related to stored data, etc. Today's main internet companies can afford to invest in that, and they will also probably compete by adding OpenID access to their existing user base. Furthermore, many RPs will require a user to have an account with one or a few of these mega-IDPs. If there's money at stake, the RP would want to minimize risk. It's all about RP peace of mind. So few small IDPs will survive. Feel free to compare search engines and how a few big companies have all but obliterated the market. Hostile RPs are easy to handle. You just take your business elsewhere. But if an IDP decides to boot you when you're no longer indirectly promoting them using their identity URLs, you could stand to lose quite a lot. Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: Identifier portability: the fundamental issue
On 10/14/06, Chris Drake <[EMAIL PROTECTED]> 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. Relying parties only get to see identifiers that users choose to give them. I don't see how this is a breach of privacy. > 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 think I am finally starting to see the position from which you're arguing, and I think you're making much ado about nothing. IdP-driven identifier selection is part of OpenID 2.0, which lets users enter just their IdP instead of a personal identifier. Site-specific identifiers will most likely be issued by the IdP, so they'll be IdP-specific, which means that the portable identifier discussion is irrelevant, since that feature is not invoked for IdP-specific identifiers. Users are not forced to disclose an identifier that can be correlated. Given *the current draft of OpenID with no modifications,* the only thing that the relying party has to know that can be used to correlate users is what IdP is making the assertion. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 13-Oct-06, at 12:59 PM, Drummond Reed wrote: > Yesterday we established consensus that with OpenID, identifier > portability > is sacred. > > Today I'd like to establish consensus on the following "postulate": > > "To achieve identifier portability in OpenID, it MUST be possible > for the RP > and the IdP to identify the user using two different identifiers: an > identifier by which the RP knows the user (the portable > identifier), and an > identifier by which the IdP knows the user (the IdP-specific > identifier)." No true. The RP knows the IdP is authoritative since there is a reference to the IdP in the document the portable identifier resolves to. How the IdP knows the user owns the portable identifier, and how the user tells the IdP that she wants to use that portable identifier, do not involve the RP, and therefore are out of scope of the protocol, as this is a protocol between the RP and the IdP, not the user and the IdP. -- Dick ___ 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
RE: Identifier portability: the fundamental issue
Chris, I totally agree that: a) OpenID Authentication 2.0 should support yours scenario of IdP-initiated login, and b) that this enables a whole range of privacy solutions, many of which can be supported by IdP innovation. If IdP-initiated login were the only use case, then only one identifier would be needed. It's the use cases for RP-initiated login that argue for having a second identifier parameter in the protocol. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Friday, October 13, 2006 9:19 PM To: specs@openid.net Subject: Re: Identifier portability: the fundamental issue Hi Drummond, DR> CASE 1: the protocol supports only IdP-specific identifiers and no portable DR> identifiers. DR> RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. Please explain? If I've got an OpenID URL (eg: my vanity domain), I can "transfer" this via DNS (or just update my OpenID ). If I've got an i-name, I can transfer this too. Where's the "lock in" ? 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!). Yes - we need 2 identifiers - but from the point of view of the specs - the OpenID protocol really only needs to deal with one. 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. 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 ? This really *is* only an hour or two's worth of code: after which, market forces can decide which bells and whistles relating to portability and privacy the IdPs choose to implement - from the OpenID point of view, it's all "just going to work". Kind Regards, Chris Drake, =1id.com Saturday, October 14, 2006, 5:59:23 AM, you wrote: DR> CASE 2: the protocol supports only portable identifiers and no IdP-specific DR> identifiers. DR> RESULT: IdP is forced to know and store all portable identifiers for a user, DR> including identifiers for which the IdP is not authoritative, and users DR> would be forced to register all their portable identifiers with their IdP, DR> and to update these registrations every time the user adds or deletes a DR> portable identifier. Highly undesirable if not impossible. DR> * DR> Please post if you do not agree with this postulate. DR> =Drummond 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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: Identifier portability: the fundamental issue
Brad Fitzpatrick wrote:
>
> Counter-argument: but OpenID 1.1 does have two parameters: one's just in
> the return_to URL and managed by the client library, arguably in its own
> ugly namespace (not IdP/RP managed, not "openid.", but something else...
> the Perl library uses "oic." or something). So then it's harder to
> document the correct behavior to people ("RPs should verify the mapping
> when you get a signature!") because the parameter names aren't consistent
> between RP clients.
>
Not specifying it gives RPs the freedom to put whatever handle they want
in the return_to, though. If they *are* able to maintain state, they
might have some arg like ?handle=1380a383198bcefd933, which is
completely opaque to everone except the RP.
I'd rather avoid specifying things we don't need to specify, since it
leaves more flexibility for implementors in an area where this
flexibility doesn't do any harm.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 10/13/06, Chris Drake <[EMAIL PROTECTED]> wrote: > DR> CASE 1: the protocol supports only IdP-specific identifiers and no > portable > DR> identifiers. > > DR> RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. > > Please explain? If I've got an OpenID URL (eg: my vanity domain), I > can "transfer" this via DNS (or just update my OpenID ). If > I've got an i-name, I can transfer this too. Where's the "lock in" ? This is true assuming that IdPs have uniform support for registering an identifier that it did not issue. OpenID 1 addressed this in its architecture. In OpenID 1, the identifier does not even have to be registered with the IdP. The proposed changes alter this arrangement. In the 2-identifier proposal, the IdP does not need to support registering identifiers, but it can be aware that a third-party identifier is being used. In the one-identifier proposal, the IdP is solely responsible for being aware of the arrangement. I do not think the success of the protocol rides on this decision, but I think it's important to understand, and understand the implications of the choice that is made. In many ways, the spirit of OpenID has been to empower the user above all. OpenID 1's delegation is consistent with that. > 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!). Why not? > Yes - we need 2 identifiers - but from the point > of view of the specs - the OpenID protocol really only needs to deal > with one. See above. > 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. Where is power being granted to the RP? It has pretty much none. It *does* have responsibility, but only as much as is necessary to make the protocol work. > 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 ? Huh? How is IdP-initiated login related to privacy or portability? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 10/13/06, Drummond Reed <[EMAIL PROTECTED]> wrote: > >So whether it's in the spec formally or not, I don't really care. But the > >spec MUST contain details on the precautions a RP should take. > > Yup.(Got that, editors?) http://openid.net/specs/openid-authentication-2_0-10.html#anchor38 Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
Hi Drummond, DR> CASE 1: the protocol supports only IdP-specific identifiers and no portable DR> identifiers. DR> RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. Please explain? If I've got an OpenID URL (eg: my vanity domain), I can "transfer" this via DNS (or just update my OpenID ). If I've got an i-name, I can transfer this too. Where's the "lock in" ? 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!). Yes - we need 2 identifiers - but from the point of view of the specs - the OpenID protocol really only needs to deal with one. 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. 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 ? This really *is* only an hour or two's worth of code: after which, market forces can decide which bells and whistles relating to portability and privacy the IdPs choose to implement - from the OpenID point of view, it's all "just going to work". Kind Regards, Chris Drake, =1id.com Saturday, October 14, 2006, 5:59:23 AM, you wrote: DR> CASE 2: the protocol supports only portable identifiers and no IdP-specific DR> identifiers. DR> RESULT: IdP is forced to know and store all portable identifiers for a user, DR> including identifiers for which the IdP is not authoritative, and users DR> would be forced to register all their portable identifiers with their IdP, DR> and to update these registrations every time the user adds or deletes a DR> portable identifier. Highly undesirable if not impossible. DR> * DR> Please post if you do not agree with this postulate. DR> =Drummond 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: Identifier portability: the fundamental issue
> > Drummond wrote:
>> >
>> > "To achieve identifier portability in OpenID, it MUST be
>> > possible for the RP and the IdP to identify the user using
>> > two different identifiers: an identifier by which the RP
>> > knows the user (the portable identifier), and an identifier
>> > by which the IdP knows the user (the IdP-specific identifier)."
>>
>> Hans wrote:
>>
>> There is no reason why the idp MUST require to know both
>> identifiers for identifier portability to be possible in
>> the system.
>
>Brad wrote:
>
>Existence proof: OpenID 1.1 does identifier portability without two
>identifiers in the spec.
Just to clarify: the "postulate" above did not mean to imply there must be
two different identifiers in the spec/protocol. It was just meant to assert
that the principle of identifier portability (upon which we already have
consensus) requires that it be possible for the RP and IdP to use two
different identifiers.
I was hoping to inch our way towards consensus here by seeing if we had
agreement on this second principle (as some messages have been implying that
IdP-specific identifiers were not needed at all).
>And despite all the "but it can't be stateless without two!" noise, it
>actually can: you put the portable identifier in the return_to URL and
>verify it again when you get the signature back from the IdP. That is,
>verify the mapping from portable -> IdP-specific still holds. Because you
>can't just trust the 1 (or 2) values you get back from the IdP, otherwise
>the IdP (which could be malicious) could be fucking with you, asserting a
>portable identifier which it's not actually permitted to do, according to
>the portable identifer's YADIS//etc.
Good point. I've never figured an attack vector for the RP to send the wrong
identifiers to the IdP, since the RP is just "fooling itself". But I agree
there can be one for a malicious IdP to return the wrong ones to an RP.
>So with 1 or 2, you still need to verify, but that verification doesn't
>have to be painful: you can cache it. "But that's state! omg!" Okay,
>so don't cache it and re-check it. But OpenID's been all about the
>state(caching) vs. roundtrip(slow) for some time, so it's a fair tradeoff.
Agreed.
>Counter-argument: but OpenID 1.1 does have two parameters: one's just in
>the return_to URL and managed by the client library, arguably in its own
>ugly namespace (not IdP/RP managed, not "openid.", but something else...
>the Perl library uses "oic." or something). So then it's harder to
>document the correct behavior to people ("RPs should verify the mapping
>when you get a signature!") because the parameter names aren't consistent
>between RP clients.
Agreed, and you articulated well the reasons for doing it at the spec level.
>So whether it's in the spec formally or not, I don't really care. But the
>spec MUST contain details on the precautions a RP should take.
Yup.(Got that, editors?)
=Drummond
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
Title: RE: Identifier portability: the fundamental issue We must have different understandings of the term sacred then. My understanding of the term is that it refers to a tenet of faith which might cause offense if contradicted. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED]] Sent: Friday, October 13, 2006 12:58 PM Pacific Standard Time To: specs@openid.net Subject: Identifier portability: the fundamental issue Yesterday we established consensus that with OpenID, identifier portability is sacred. Today I'd like to establish consensus on the following "postulate": "To achieve identifier portability in OpenID, it MUST be possible for the RP and the IdP to identify the user using two different identifiers: an identifier by which the RP knows the user (the portable identifier), and an identifier by which the IdP knows the user (the IdP-specific identifier)." I would submit that if this postulate is true, then OpenID Authentication 2.0 requires two identifier parameters because if the protocol only allows sending one, then: 1) If the RP sends the IdP-specific identifier, the RP must keep state to maintain mapping to the portable identifier (bad), and 2) If the RP sends the portable identifier, an IdP is forced to do a resolution a second time after the RP has already done resolution (bad). OTOH, if the postulate is false, then a case can be made for OpenID Authentication 2.0 having just one identifier parameter. PROOF CASE 1: the protocol supports only IdP-specific identifiers and no portable identifiers. RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. CASE 2: the protocol supports only portable identifiers and no IdP-specific identifiers. RESULT: IdP is forced to know and store all portable identifiers for a user, including identifiers for which the IdP is not authoritative, and users would be forced to register all their portable identifiers with their IdP, and to update these registrations every time the user adds or deletes a portable identifier. Highly undesirable if not impossible. * Please post if you do not agree with this postulate. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 13-Oct-06, at 12:59 PM, Drummond Reed wrote: > Yesterday we established consensus that with OpenID, identifier > portability > is sacred. > > Today I'd like to establish consensus on the following "postulate": > > "To achieve identifier portability in OpenID, it MUST be possible > for the RP > and the IdP to identify the user using two different identifiers: an > identifier by which the RP knows the user (the portable > identifier), and an > identifier by which the IdP knows the user (the IdP-specific > identifier)." > > I would submit that if this postulate is true, then OpenID > Authentication > 2.0 requires two identifier parameters because if the protocol only > allows > sending one, then: > > 1) If the RP sends the IdP-specific identifier, the RP must keep > state to > maintain mapping to the portable identifier (bad), and I agree with that. > > 2) If the RP sends the portable identifier, an IdP is forced to do a > resolution a second time after the RP has already done resolution > (bad). No, the IdP is not forced to do a resolution. The IdP already knows that. > > OTOH, if the postulate is false, then a case can be made for OpenID > Authentication 2.0 having just one identifier parameter. > > PROOF > > CASE 1: the protocol supports only IdP-specific identifiers and no > portable > identifiers. > > RESULT: IdPs can achieve identifier lockin. Not acceptable. End of > Case 1. Agreed. > > CASE 2: the protocol supports only portable identifiers and no IdP- > specific > identifiers. > > RESULT: IdP is forced to know and store all portable identifiers > for a user, > including identifiers for which the IdP is not authoritative, and > users Why would the IdP need to know identifiers over which it is not authoritative? > would be forced to register all their portable identifiers with > their IdP, > and to update these registrations every time the user adds or > deletes a > portable identifier. Highly undesirable if not impossible. I don't see this as undesirable but as necessary. If I have a portable identifier and I configure it to point to some IdP for authentication it only makes sense for the IdP to know about the identifier as well. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
On Fri, 13 Oct 2006, Granqvist, Hans wrote:
> > "To achieve identifier portability in OpenID, it MUST be
> > possible for the RP and the IdP to identify the user using
> > two different identifiers: an identifier by which the RP
> > knows the user (the portable identifier), and an identifier
> > by which the IdP knows the user (the IdP-specific identifier)."
>
> There is no reason why the idp MUST require to know both
> identifiers for identifier portability to be possible in
> the system.
Existence proof: OpenID 1.1 does identifier portability without two
identifiers in the spec.
And despite all the "but it can't be stateless without two!" noise, it
actually can: you put the portable identifier in the return_to URL and
verify it again when you get the signature back from the IdP. That is,
verify the mapping from portable -> IdP-specific still holds. Because you
can't just trust the 1 (or 2) values you get back from the IdP, otherwise
the IdP (which could be malicious) could be fucking with you, asserting a
portable identifier which it's not actually permitted to do, according to
the portable identifer's YADIS//etc.
So with 1 or 2, you still need to verify, but that verification doesn't
have to be painful: you can cache it. "But that's state! omg!" Okay,
so don't cache it and re-check it. But OpenID's been all about the
state(caching) vs. roundtrip(slow) for some time, so it's a fair tradeoff.
Counter-argument: but OpenID 1.1 does have two parameters: one's just in
the return_to URL and managed by the client library, arguably in its own
ugly namespace (not IdP/RP managed, not "openid.", but something else...
the Perl library uses "oic." or something). So then it's harder to
document the correct behavior to people ("RPs should verify the mapping
when you get a signature!") because the parameter names aren't consistent
between RP clients.
So whether it's in the spec formally or not, I don't really care. But the
spec MUST contain details on the precautions a RP should take.
- Brad
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
> "To achieve identifier portability in OpenID, it MUST be > possible for the RP and the IdP to identify the user using > two different identifiers: an identifier by which the RP > knows the user (the portable identifier), and an identifier > by which the IdP knows the user (the IdP-specific identifier)." There is no reason why the idp MUST require to know both identifiers for identifier portability to be possible in the system. > I would submit that if this postulate is true, then OpenID > Authentication 2.0 requires two identifier parameters because > if the protocol only allows sending one, then: > > 1) If the RP sends the IdP-specific identifier, the RP must > keep state to maintain mapping to the portable identifier (bad), and Why is it so bad for an RP to be required to maintain such state? (Besides, an RP could advertise whether it is willing to keep that state, and the user would decide what to do.) Keeping such state seems a very slight inconvenience for a much greater goal: true portability of my identifiers. What the idp doesn't know, it cannot take away. > ... ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On Oct 13, 2006, at 12:59, Drummond Reed wrote: 1) If the RP sends the IdP-specific identifier, the RP must keep state to maintain mapping to the portable identifier (bad), and I agree, but I'm not sure that this is a big issue. Won't a simple cookie be sufficient? Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On Oct 13, 2006, at 12:59, Drummond Reed wrote: Yesterday we established consensus that with OpenID, identifier portability is sacred. Could somebody please post a succinct definition of "identifier portability" somewhere. If we have a new religion, we might as well agree what it is ;-) Preferably a public web page. Starting a list of "Design principles" comes to mind, I mean "List of sacred cows" or something ;-) Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Identifier portability: the fundamental issue
Yesterday we established consensus that with OpenID, identifier portability is sacred. Today I'd like to establish consensus on the following "postulate": "To achieve identifier portability in OpenID, it MUST be possible for the RP and the IdP to identify the user using two different identifiers: an identifier by which the RP knows the user (the portable identifier), and an identifier by which the IdP knows the user (the IdP-specific identifier)." I would submit that if this postulate is true, then OpenID Authentication 2.0 requires two identifier parameters because if the protocol only allows sending one, then: 1) If the RP sends the IdP-specific identifier, the RP must keep state to maintain mapping to the portable identifier (bad), and 2) If the RP sends the portable identifier, an IdP is forced to do a resolution a second time after the RP has already done resolution (bad). OTOH, if the postulate is false, then a case can be made for OpenID Authentication 2.0 having just one identifier parameter. PROOF CASE 1: the protocol supports only IdP-specific identifiers and no portable identifiers. RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. CASE 2: the protocol supports only portable identifiers and no IdP-specific identifiers. RESULT: IdP is forced to know and store all portable identifiers for a user, including identifiers for which the IdP is not authoritative, and users would be forced to register all their portable identifiers with their IdP, and to update these registrations every time the user adds or deletes a portable identifier. Highly undesirable if not impossible. * Please post if you do not agree with this postulate. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
