The WordPress User Problem (WAS: RE: Specifying identifier recycling)
I think the largest concern I have with fragments, or really any pair-wise shared secret which can't be renegotiated, is that while it solves issues for the large service providers it actually inhibits OpenID within the grassroots community. Imagine if I install WordPress (or insert other app here) on https://davidrecordon.com and check the Use fragments to protect my OpenID box. A few months later I decide to remove WordPress, or an upgrade blows away my OpenID extension data, or I'm using an extension which stores the fragments in /tmp/ and they get blown away. I now no longer have access to my accounts on all the relying parties I've visited. Now what do I do? We can't count on each RP implementing an account recovery mechanism; remember OpenID outsources account management so you can focus on building you application. I can't call up my service provider and ask them to fix it, since well I was using my own provider. I could try to call up my webhost and see if they can restore from a backup, but I'd guess by the time I realize what that check box in my WordPress extension settings did there may not even be backups anymore. In the end, I'd be extremely frustrated that OpenID didn't work for me and I'd write a really obnoxious blog post about how much OpenID sucks. So while we solve one aspect of the recycling problem, we end up creating a larger problem from the opposite side of the equation. I'm certainly not arguing that we shouldn't solve this problem, nor that participation from large providers isn't vital, but would hate to see us create a problem for all of the people out there that have really helped gain OpenID traction. I don't want to say that I have the answers here, since I don't think I do. I do however see the following possible solutions: 1) The core specification only talks about fragments in relation to Relying Parties, to the extent that they should be stripped from display though used as a unique key. We do however need to address how a RP should handle display and account management differences when a fragment changes. I'm guessing it is unreasonable to expect every instance of https://davidrecordon.com to be replaced with https://davidrecordon.com/#231hwqai21jb when the fragment changes (not to mention that the fragment *must* remain private between the OP and RP to be effective). An extension is then written describing fragment usage from the OP perspective with huge warnings about how it should only be used by large service providers who know what they're doing. 2) We use a centralized canonical id approach like i-numbers. Basically somebody issues unique and never reassigned ids. 3) We use a distributed canonical id approach. Providers issue an ugly non-reassignable URL which points at the pretty one and vice-versa. Thus https://davidrecordon.com says its canonical is https://12jbd9210.pip.verisignlabs.com which in turn says it is https://davidrecordon.com. We could even kill two birds with one stone and use link rel='me' / to do this and setup an easy way to create identifier equality. 4) We use public/private key pairs, though this has the traditional private key revocation issues. I think my preference is #3, though I'm sure it has its own issues. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Sunday, June 03, 2007 6:35 PM To: Recordon, David Cc: Johannes Ernst; OpenID specs list Subject: Re: Specifying identifier recycling On 3-Jun-07, at 1:46 AM, Recordon, David wrote: I thought at IIW we agreed that if we could come to quick consensus on a way to resolve the problem it would be a part of 2.0, otherwise it would not... Agreed, nobody wants to delay 2.0 indefinitely if we can't agree on how to solve this issue. But the issue was deemed important enough to be one of the only two on the 2.0 agenda. As concerns with the fragment proposal have been raised, which had the most agreement at IIW, it seems we no longer have consensus. I haven't seen many actually; checking this thread for what can count as concerns reveals only: a) Josh's initial email b) Johannes' +1 to not adopting a solution that doesn't actually work c) David acknowledging the concerns This doesn't seem to me to carry enough weight to veto the fragment proposal, especially when a) has been / can still be addressed, and the fragment proposal made sense to a dozen people at that meeting. As seen in this thread, there are a wide variety of opinions as to how to resolve this concern. I thus think merely picking one for the sake of putting something into 2.0 would be misguided. True, there have been a few (I definitely wouldn't call it a wide variety) possible solutions mentioned, but none very well defined, and none had the support of 10+ people like the fragment did. I have argued that it will have to be core (whether 2.0 or 3.0). I guess we should ask ourselves then if we really want this addressed in 2.0
Re: The WordPress User Problem (WAS: RE: Specifying identifier recycling)
On 5-Jun-07, at 8:00 AM, Recordon, David wrote: I think the largest concern I have with fragments, or really any pair-wise shared secret which can't be renegotiated, is that while it solves issues for the large service providers it actually inhibits OpenID within the grassroots community. This concern is definitely something new; I haven't seen it expressed before. Imagine if I install WordPress (or insert other app here) on https://davidrecordon.com and check the Use fragments to protect my OpenID box. A few months later I decide to remove WordPress, or an upgrade blows away my OpenID extension data, or I'm using an extension which stores the fragments in /tmp/ and they get blown away. I now no longer have access to my accounts on all the relying parties I've visited. Now what do I do? What do you do today, if you forget your slashdot password and slashdot didn't implement account recovery? Most (if not all) RPs today do implement account recovery - they don't want to loose users, and they know users make mistakes and forget passwords. We can't count on each RP implementing an account recovery mechanism; remember OpenID outsources account management so you can focus on building you application. I can't call up my service provider and ask them to fix it, since well I was using my own provider. You should call up your OP then. I could try to call up my webhost and see if they can restore from a backup, but I'd guess by the time I realize what that check box in my WordPress extension settings did there may not even be backups anymore. In the end, I'd be extremely frustrated that OpenID didn't work for me and I'd write a really obnoxious blog post about how much OpenID sucks. So while we solve one aspect of the recycling problem, we end up creating a larger problem from the opposite side of the equation. I'm certainly not arguing that we shouldn't solve this problem, nor that participation from large providers isn't vital, but would hate to see us create a problem for all of the people out there that have really helped gain OpenID traction. I don't want to say that I have the answers here, since I don't think I do. I do however see the following possible solutions: 1) The core specification only talks about fragments in relation to Relying Parties, to the extent that they should be stripped from display though used as a unique key. We do however need to address how a RP should handle display and account management differences when a fragment changes. I'm guessing it is unreasonable to expect every instance of https://davidrecordon.com to be replaced with https://davidrecordon.com/#231hwqai21jb when the fragment changes (not to mention that the fragment *must* remain private between the OP and RP to be effective). An extension is then written describing fragment usage from the OP perspective with huge warnings about how it should only be used by large service providers who know what they're doing. I believe it could work with REQUIREments in the core for RPs (discovery, verification), and OPTIONAL / extension for the OPs. Though the gained simplicity I think would be minimal. But if the other advantage is that OPs don't carelessly implement this feature without knowing what they are doing, then it may be better overall. Totally agree with the warnings / raising awareness that identifier recycling is an advanced feature. I believe this is part of a more general problem: by being decentralized, OpenID gives power to everyone (anyone can be an OP); while being an RP is / should be simple, doing the OP job right is not. 2) We use a centralized canonical id approach like i-numbers. Basically somebody issues unique and never reassigned ids. 3) We use a distributed canonical id approach. Providers issue an ugly non-reassignable URL which points at the pretty one and vice- versa. Thus https://davidrecordon.com says its canonical is https://12jbd9210.pip.verisignlabs.com which in turn says it is https://davidrecordon.com. We could even kill two birds with one stone and use link rel='me' / to do this and setup an easy way to create identifier equality. I think my preference is #3, though I'm sure it has its own issues. Do you have a more detailed proposal on how this would work? I do see a couple important / possibly show-stopper issues here, but I haven't really explored this direction for a solution. If you have, I would definitely be interested to learn more. However, I still believe #1 is our best bet, if we can focus our efforts to make it work in such a way to address your grassroots adoption concerns. #1 did have (and still has, I hope) the support of a good many people, and has a concrete and detailed proposal. If we agree that _some_ changes to the core are required, then #1 has also the time advantage. 4) We use public/private key pairs, though this has the
Re: The WordPress User Problem (WAS: RE: Specifying identifier recycling)
On 6/5/07, Recordon, David [EMAIL PROTECTED] wrote: Imagine if I install WordPress (or insert other app here) on https://davidrecordon.com and check the Use fragments to protect my OpenID box. A few months later I decide to remove WordPress, or an upgrade blows away my OpenID extension data, or I'm using an extension which stores the fragments in /tmp/ and they get blown away. I now no longer have access to my accounts on all the relying parties I've visited. Now what do I do? The fragment is not secret. It is not protecting your OpenID. You should be able to get the fragment from any relying party that you visited. You might choose to use a fragment if you have acquired a recycled identifier, but you can choose the fragment. It protects *nothing* if you control the base identifier (to the point that you can choose an OpenID provider). I'm not arguing for or against a particular approach here, but I think your argument is flawed. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The WordPress User Problem (WAS: RE: Specifying identifier recycling)
On 5-Jun-07, at 11:12 AM, Josh Hoyt wrote: On 6/5/07, Recordon, David [EMAIL PROTECTED] wrote: Imagine if I install WordPress (or insert other app here) on https://davidrecordon.com and check the Use fragments to protect my OpenID box. A few months later I decide to remove WordPress, or an upgrade blows away my OpenID extension data, or I'm using an extension which stores the fragments in /tmp/ and they get blown away. I now no longer have access to my accounts on all the relying parties I've visited. Now what do I do? The fragment is not secret. It is not protecting your OpenID. You should be able to get the fragment from any relying party that you visited. I believe David's point is that you cannot retrieve the fragment from the RP if you have lost it and are no longer able to log into any RPs. (Unless there's an account recovery mechanism either on the RP or the OP.) The RPs know it, but are not supposed to display / disclose it. You might choose to use a fragment if you have acquired a recycled identifier, but you can choose the fragment. It protects *nothing* if you control the base identifier (to the point that you can choose an OpenID provider). Agreed - if you loose control over the URL, you can no longer use your old online identity. However, the issue / feature this does address is protect your RP accounts if you loose your identity. (The new owner of davidrecordon.com would not be able to sign into the old davidrecordon.com's digg account.) Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: The WordPress User Problem (WAS: RE: Specifying identifier recycling)
On 5-Jun-07, at 11:58 AM, Josh Hoyt wrote: The relying parties SHOULD make the fragment available to software agents, at least, so that it's possible to compare identifiers across sites. If the fragment is never available, then there is confusion about which user of an identifier is responsible for content that has been posted. One use case where software agents having access to the fragment is particularly important is if the identifier is used for access control, and the access control list is retrieved from off-site (e.g. from a social networking site). The implementation that seems most sane is for places that display the identifier for human reading look like: a href=http://josh.example.com/#this-is-intended-for-machine- consumption http://josh.example.com//a so that the software agent would see the fragment, but the user wouldn't have to. On 5-Jun-07, at 2:55 PM, Recordon, David wrote: I thought the fragment was to be secret so that for the case of using a personal domain you don't have to own joshhoyt.com forever. Rather as long as your fragments are secret, someone else can buy joshhoyt.com and not be you. If this is no longer a requirement then it certainly changes the game, though also doesn't solve one of the other aspects of identifier recycling. I thought so too, but I believe Josh is right - the lost domain cell with an X in it (for URL + public fragment) supports Josh's statement: http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling So if we're not dealing with this use case, it becomes actually simpler to address just the identifier recycling for big OPs, where loosing the domain is not an issue. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: The WordPress User Problem (WAS: RE: Specifying identifier recycling)
At that point I'd be concerned as to solving the big OP issue while not solving the lost domain issue when some of the proposals could possible solve both. This largely focuses around using an XRI-style canonical id, whether that be an i-number or just another ugly URL which points back at the pretty one. I know I need to write this up more... --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 05, 2007 3:18 PM To: Recordon, David Cc: Josh Hoyt; Johannes Ernst; OpenID specs list Subject: Re: The WordPress User Problem (WAS: RE: Specifying identifier recycling) On 5-Jun-07, at 11:58 AM, Josh Hoyt wrote: The relying parties SHOULD make the fragment available to software agents, at least, so that it's possible to compare identifiers across sites. If the fragment is never available, then there is confusion about which user of an identifier is responsible for content that has been posted. One use case where software agents having access to the fragment is particularly important is if the identifier is used for access control, and the access control list is retrieved from off-site (e.g. from a social networking site). The implementation that seems most sane is for places that display the identifier for human reading look like: a href=http://josh.example.com/#this-is-intended-for-machine- consumption http://josh.example.com//a so that the software agent would see the fragment, but the user wouldn't have to. On 5-Jun-07, at 2:55 PM, Recordon, David wrote: I thought the fragment was to be secret so that for the case of using a personal domain you don't have to own joshhoyt.com forever. Rather as long as your fragments are secret, someone else can buy joshhoyt.com and not be you. If this is no longer a requirement then it certainly changes the game, though also doesn't solve one of the other aspects of identifier recycling. I thought so too, but I believe Josh is right - the lost domain cell with an X in it (for URL + public fragment) supports Josh's statement: http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling So if we're not dealing with this use case, it becomes actually simpler to address just the identifier recycling for big OPs, where loosing the domain is not an issue. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
For posterity, here's how I'd summarize this thread about using public keys as persistent identifiers: 1) Yes, a public key could be used as an identifier, and could serve as a persistent identifier if it was not reassignable. 2) The issue of it becoming invalid as a credential if the private key was compromised is orthogonal to its use purely as an identifier, i.e., as Johannes points out, if the private key was compromised, use of the public key could revert to the role of serving purely as an identifier, and another set of credentials (such as another public/private key pair) could be assigned. 3) In this light, the primary drawbacks I see to public keys as identifiers are: a) They are typically much larger than other persistent identifiers designed for this purpose (e.g., XRI i-numbers as issued by XDI.org or Handles as issued by CNRI). b) I am not aware of a resolution protocol designed for them, with the exception that I believe syntactially they could be used as XRI i-numbers. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Tuesday, June 05, 2007 7:27 PM To: =nat Cc: 'OpenID specs list' Subject: Re: Specifying identifier recycling I think you are making an invalid analogy. What prevents you from setting up a private key reset function the same way you set up a password reset function, using an alternate credential? You allow for this for non-public-key credentials but not for others ... But I don't want to perpetuate this thread given the general reluctance of the community to think about public key cryptography at this time ... I just want to go on record that I find the arguments made counter public keys on this thread non-persuasive and want to pick it back up when the community is ready to go there ... (note also that the security industry would not exist in the shape it does if we didn't have public key crypto, so that technology does contribute something somewhere ... perhaps also to OpenID?) Just follow the following argument ... let's assume that the problem that started this thread ... can be solved by adding a number to the URL identifier (using a fragment syntax or an i-number or whatever other approaches were discussed) ... then it also can be solved by adding a large number instead of just any number ... then it also can be solved by adding a large number that could be a public key, which is nothing but a large number ... which, therefore, makes a public-key-based approach at least as powerful as a plain number Just some stuff for thought ... ;-) Cheers, Johannes. On Jun 5, 2007, at 17:58, =nat wrote: Hi. Ok. Now I see the heart of the topic :-) Fundamental difference is that you postulate that one cannot lose one's credential including all the information that bears onto establish one's identity while I do not postulate so. For example, one can loose one's password and reset it. You can loose your credit card and replace it. Doing so has not nullished your identity. You still are yourself. Your identity itself and the attribute associated with it apart from this particular lost credential data (whether it was a password or credit card) stays intact. This picture changes dramatically when you use public key as your main identity address. If you lose your private key, that's the end of story. Your relationships with all the RPs are ruined. That is why I believe that we should not be using this kind of public key as the identification data for RPs. Also, mandating OPs to specify a unique opaque string as the identification data would be much simpler than requiring parties to do public key verification, I think :-) Having said that, I do agree that we should be completing 2.0 cycle quickly and making it SIMPLE! Nat -Original Message- From: Johannes Ernst [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 05, 2007 1:45 PM To: =nat Cc: 'OpenID specs list' Subject: Re: Specifying identifier recycling I would postulate that if you want to be able to prove your identity, you cannot allow your credential to be lost, interpreting credential to be all the information that bears onto establishing your identity. (saying it this way, it is a tautology.) This is independent of whether anybody uses public keys, or any other technology. So I very strongly suspect that while it may be more apparent to you guys that the issue exists for public key technology, it also exists for all other approaches, whether we know them at this time or not! However, I can readily see that strong voices (that'd be you guys ;-)) are not ready to adopt any kind of public key technology into the OpenID family, never mind whether X or Y wins this particular argument. So we don't need to continue this thread. I continue to believe, however, as I have said before, that we don't have enough of an agreement
RE: Specifying identifier recycling
Hi. My comments in-line below: On Saturday, June 02, 2007 5:40 AM, Johannes Ernst wrote: On May 31, 2007, at 18:41, Nat Sakimura wrote: Public key idea is somewhat attractive to me, but there are some issues that comes up in my mind as well. Bring them on ;-) 1) Storing many users' private key on the server in decryptable format is not very safe. In your proposal, it looks like that OP is going to hold the private key for each user in decryptable format. Considering that most large scale privacy leakage happens at the server side, I have got a feeling that such thing like private key in a shared location. How would this be less safe than storing many shared secrets (per OpenID Auth) in decryptable format, or clear-text (more likely) on the server? Well, we should not store any :-) We would not need them, do we? Just hashes would do. Note that these private keys would not be general-purpose private keys, but only for the specific purpose we are discussing here. Actually, by Dick's comment, I am now realizing what was making me uneasy. I feel (sort of) ok on storing one's special purpose secret key on the server just like server-side wallet, but I want it to be replaceable without impacting my identity. i.e., it is ok to use the key to sign a message, but not make the pub-key my identifier. (Having said that, I am still not clear why we should need this for just AuthN. OP sigining the response on authenticating the user does not seem much different. Also, keeping one key in HSM and securely operating is easier than having millions of keys...) Also, I suspect that the use of these keys would be fairly infrequent compared to other operations, so conceivably one could add additional safeguards of various kinds if that was needed. 2) It may mean a high cost operation for OPs. If we do this, it makes OP operation very high cost because to make the service safe, it would require a lot of measures. (NRI is providing similar kind of service but it indeed is very high cost operation.) Nice thing about i-number is that it has no value like public key except for its resolvability. Even if it leaks, that's kind of ok so operational risk is low. This comparison does not work very well for me. However: I don't know the details of how to avoid impersonation via i-numbers (in case of key pairs, it would be private key leaks and is reused by attacker -- what would be the equivalent for i-numbers?), but I suspect there are some measures that prevent attackers from impersonation by using somebody else's i-number? If so, aren't they similarly susceptible to attack? In the scenario that OP signs a unique string (whether it is i-number or something else), impersonization happens when OP's key is stolen. However, as Dick points out, we have a way to re-setup the keys between OP and RP. In case of user private key as a part of identity leaks, we do not have a very good way of replacing it. (Well, we cannot, as if we could, this will contradict its purpose as counter id recycling measure. Note, if it is not part of identity string and just used to sign something with public key discovery protocol, that is ok.) ( I also would like to point out that OP's key leaking is much easier to monitor and detect than user's. ) Actually, these private key pain may be eased by IBE (Identity Based Encryption) but I need some more time to contemplate on it. I had somebody else mention this to me -- I wonder whether anybody could put together an actual proposal. After some thinking, I started to think that this might not be a good idea after all. 3) Since OPs has an access to the users' private key, they may recycle them as well. IMHO, recycling is operational problem as well as a technical one. i-number from a certified i-broker is somewhat trustable on the account of no recycling because of this operational restriction. Could there be operational restriction similart to that for general OPs as well? There could, and -- I suspect -- in the longer term there probably will, but the whole point about a decentralized system like OpenID is to keep the playing field level without a central entity in the middle for the maximum length of time and scope possible. Well, I am not talking about a central authority kind of thing. Having a uniquely identifying filed (whether canonicalID or fragment) in the spec would suffice because this will imply that an OP that does not meet this operation practice is not OpenID spec compliant. Some OP may opt to elect a third party auditor to prove their parctice, while some other would not. Also, reputation service kind of thing would be nice. This is all de-centralized. No central authority would be required. In any case, I think we should use the approach to use (decentralized) technology to the maximum extent possible, and
RE: Specifying identifier recycling
So I ask again - does anyone see any issues with the fragments being used like this: http://openid.net/pipermail/specs/2007-May/001767.html Seems reasonable in essence. But it adds complexity and removes some immediacy of URL identifiers-as-is. Do fragments need special handling just to handle id recycling risks? I'm probably missing some context, but can't the issuing OP make sure to issue unique IDs, like http://example.com/user1234 instead of http://example.com/user#1234 ? Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
On 4-Jun-07, at 7:51 AM, Granqvist, Hans wrote: So I ask again - does anyone see any issues with the fragments being used like this: http://openid.net/pipermail/specs/2007-May/001767.html Seems reasonable in essence. But it adds complexity and removes some immediacy of URL identifiers-as-is. Do fragments need special handling just to handle id recycling risks? I'm probably missing some context, but can't the issuing OP make sure to issue unique IDs, like http://example.com/user1234 instead of http://example.com/user#1234 ? Just to clarify the issue: Users like to have memorable usernames, and likely memorable OpenIDs. So http://example.com/hans would be a desirable URL at example.com. For OPs with literally 100Ms of users, http://example.com/hans would be a coveted URL and if it is not being used, example.com would like to issue it to someone else. I think the tradeoff of RPs understanding to strip fragments when displaying them is worth removing a barrier for very large OPs from joining OpenID. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
I would postulate that if you want to be able to prove your identity, you cannot allow your credential to be lost, interpreting credential to be all the information that bears onto establishing your identity. (saying it this way, it is a tautology.) This is independent of whether anybody uses public keys, or any other technology. So I very strongly suspect that while it may be more apparent to you guys that the issue exists for public key technology, it also exists for all other approaches, whether we know them at this time or not! However, I can readily see that strong voices (that'd be you guys ;-)) are not ready to adopt any kind of public key technology into the OpenID family, never mind whether X or Y wins this particular argument. So we don't need to continue this thread. I continue to believe, however, as I have said before, that we don't have enough of an agreement on the solution to be able to standardize any of them at this time. (Personally, I don't think we have agreement on the problems to be solved either.) I'd much rather see our creative juices flowing on the much larger problem of simplifying the OpenID Auth draft in a manner that people say this is much easier than 1.1 instead of the opposite. On Jun 3, 2007, at 23:11, =nat wrote: Dick's concern is very valid, I think. I do not even want to think of the consequence of losing my own main identity secret :-p =nat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Sunday, June 03, 2007 8:24 PM To: Johannes Ernst Cc: OpenID specs list Subject: Re: Specifying identifier recycling There is a huge difference between the OP/RP shared secret and using a shared secret as an identifier. The secret between the OP and RP has a mechanism for it to be recycled. If it happens to be lost, then the pair can set up a new secret. If the user's secret is lost, then that identifier and any accounts that it was used for are lost. -- Dick ___ 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: Specifying identifier recycling
I thought at IIW we agreed that if we could come to quick consensus on a way to resolve the problem it would be a part of 2.0, otherwise it would not... As concerns with the fragment proposal have been raised, which had the most agreement at IIW, it seems we no longer have consensus. As seen in this thread, there are a wide variety of opinions as to how to resolve this concern. I thus think merely picking one for the sake of putting something into 2.0 would be misguided. --David -Original Message- From: Johnny Bufu [mailto:[EMAIL PROTECTED] Sent: Saturday, June 02, 2007 10:12 PM To: Recordon, David Cc: Johannes Ernst; OpenID specs list Subject: Re: Specifying identifier recycling On 2-Jun-07, at 5:14 PM, Recordon, David wrote: I'd like to see this written as an extension so that if the first approach doesn't work, the Auth spec itself doesn't have to be reverted. Rather we can finish 2.0 and try implementing different approaches before deciding on the final way to solve this problem. I thought we had agreed at IIW (for good reason) to address this in 2.0. Other than the actual solution not being 100% clear, has anything changed? Arguments for not putting it into an extension: - users of provider's X who employs 'identifier recycling extension' would not be able to log into RP Y who doesn't understand the extension - it's likely that whatever solution we come up with affects the discovery / verification processes, in which case it couldn't be pushed to an extension (we're trying to patch something about the _identifier_ itself, which is the center of each openid transaction). Also, I believe the fragment approach can actually work, as detailed here: http://openid.net/pipermail/specs/2007-May/001767.html I haven't seen any replies to this, so would appreciate if others would go through the proposed changes and see if they all makes sense of I've overlooked something. Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
On 3-Jun-07, at 2:14 AM, Recordon, David wrote: Overall, I'm not sure we are ready in this community to pick one alternative over another as the standards. I have my views, (many) others have (many) others -- and I don't think that any of this has to be in an Authentication 1.x (x1) or 2.0 spec, whatever it will be. This seems like a clean add-on. I also agree with Johannes here. I'd like to see this written as an extension so that if the first approach doesn't work, the Auth spec itself doesn't have to be reverted. Rather we can finish 2.0 and try implementing different approaches before deciding on the final way to solve this problem. I don't see how we can solve this problem as an extension as we need the RP to know that a memorable identifier has some extra info that makes it unique when reused. This is core to OpenID. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
There is a huge difference between the OP/RP shared secret and using a shared secret as an identifier. The secret between the OP and RP has a mechanism for it to be recycled. If it happens to be lost, then the pair can set up a new secret. If the user's secret is lost, then that identifier and any accounts that it was used for are lost. -- Dick On 31-May-07, at 7:30 AM, Johannes Ernst wrote: If we cannot assume that nobody manages to obtain a secret they should not have gotten in the first place, then OpenID as it stands is rather useless as we cannot trust its authentication scheme. Note that the surface through which the D-H shared secret can escape is about twice as large as the surface through which a private key can escape -- because an RP does not have access to the private key. In other words, if I was an attacker, I'd go after a lot of things first before I'd try to obtain a private key. Note also that public keys would make rather good i-numbers -- for those who would like to, they can ignore that they are public keys and do i-number-based verification only, because they are simply numbers. For those who don't care about i-numbers, they use their public key aspects. Win-win, perhaps? There is also the case -- which Stefan Brands would undoubtedly bring up if he was on this list -- that the IdP may be hostile, or may become hostile. (think of, say, a large OpenID provider going out of business, and being bought out by spammer.com -- or just the domain name whose registration lapsed) A scheme that is public key based is inherently more resilient towards this than one that is not. You certainly don't want to trust spammer.com to honor whatever conventions the previous owner of the domain put in place to disambiguate their users. -- Overall, I'm not sure we are ready in this community to pick one alternative over another as the standards. I have my views, (many) others have (many) others -- and I don't think that any of this has to be in an Authentication 1.x (x1) or 2.0 spec, whatever it will be. This seems like a clean add-on. On May 30, 2007, at 22:01, Drummond Reed wrote: Johannes: What about the point Dick posted earlier in this thread, that the problem with using a public key is if the private key gets compromised? Persistent identifiers need to persist independent of any attribute changing or being revoked. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Wednesday, May 30, 2007 9:54 PM To: OpenID specs list Subject: Re: Specifying identifier recycling On May 30, 2007, at 21:02, Johnny Bufu wrote: ...The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Public keys ... public keys ... with the added benefit that no centralized or trusted verification service needs to be employed whatsoever ... Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net 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: Specifying identifier recycling
On 3-Jun-07, at 1:46 AM, Recordon, David wrote: I thought at IIW we agreed that if we could come to quick consensus on a way to resolve the problem it would be a part of 2.0, otherwise it would not... Agreed, nobody wants to delay 2.0 indefinitely if we can't agree on how to solve this issue. But the issue was deemed important enough to be one of the only two on the 2.0 agenda. As concerns with the fragment proposal have been raised, which had the most agreement at IIW, it seems we no longer have consensus. I haven't seen many actually; checking this thread for what can count as concerns reveals only: a) Josh's initial email b) Johannes' +1 to not adopting a solution that doesn't actually work c) David acknowledging the concerns This doesn't seem to me to carry enough weight to veto the fragment proposal, especially when a) has been / can still be addressed, and the fragment proposal made sense to a dozen people at that meeting. As seen in this thread, there are a wide variety of opinions as to how to resolve this concern. I thus think merely picking one for the sake of putting something into 2.0 would be misguided. True, there have been a few (I definitely wouldn't call it a wide variety) possible solutions mentioned, but none very well defined, and none had the support of 10+ people like the fragment did. I have argued that it will have to be core (whether 2.0 or 3.0). I guess we should ask ourselves then if we really want this addressed in 2.0, and if yes then try to make it work. So I ask again - does anyone see any issues with the fragments being used like this: http://openid.net/pipermail/specs/2007-May/001767.html If not, I have a hard time understanding where exactly the consensus was lost. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
Johnny Bufu wrote: We did look at this (with Drummond) in December. The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Martin Atkins wrote: Indeed, CanonicalID verification would be necessary, but it's already necessary if you want to accept XRI-based logins anyway. Last time we were talking about this CanonicalID verification for XRI was not yet specified. Is it now specified somewhere? Martin, it's been specified in draft form since last October on the XRI TC wiki at: http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification The content there was moved week before last into the first editor's draft of XRI Resolution 2.0 Working Draft 11 at: http://www.oasis-open.org/committees/download.php/24096/xri-resolution-v2.0- wd-11-ed-01.doc The new Canonical ID Verification section is #11. Note that the verification rules currently only cover if the XRDS is discovered from an XRI. In the second editor's draft, due this Wednesday, we will add rules for verification if the XRDS is discovered from a URL. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
Nat Sakimura schrieb: 1) Storing many users' private key on the server in decryptable format is not very safe. In your proposal, it looks like that OP is going to hold the private key for each user in decryptable format. Considering that most large scale privacy leakage happens at the server side, I have got a feeling that such thing like private key in a shared location. If you can't trust your OP to keep your secrets secret, there's nothing you can do about that. Of course, you would not use a key that's valid as a key for anything else than OpenID. It's also possible that the OP does not know the private key by using two key pairs: . pers_secret, pers_public (the identity) . temp_secret, temp_public The OpenID Povider only has the following: . pers_public . temp_secret, temp_public . cert = sign(temp_public, with_key=pers_secret) The _real_ private key, pers_secret, is kept by the user. If the server is compromised (or becomes rouge, trying to steal the identity), the user can still take his identity elsewhere by signing the tmp2_public key of another server. Claus ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
Overall, I'm not sure we are ready in this community to pick one alternative over another as the standards. I have my views, (many) others have (many) others -- and I don't think that any of this has to be in an Authentication 1.x (x1) or 2.0 spec, whatever it will be. This seems like a clean add-on. I also agree with Johannes here. I'd like to see this written as an extension so that if the first approach doesn't work, the Auth spec itself doesn't have to be reverted. Rather we can finish 2.0 and try implementing different approaches before deciding on the final way to solve this problem. SREG shows how 1.1 can be extended, 2.0 clarifies this mechanism and makes it more robust, let's take advantage of it especially given that not all providers require this feature (whether via fragments or public keys). --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Wednesday, May 30, 2007 10:30 PM To: OpenID specs list Subject: Re: Specifying identifier recycling If we cannot assume that nobody manages to obtain a secret they should not have gotten in the first place, then OpenID as it stands is rather useless as we cannot trust its authentication scheme. Note that the surface through which the D-H shared secret can escape is about twice as large as the surface through which a private key can escape -- because an RP does not have access to the private key. In other words, if I was an attacker, I'd go after a lot of things first before I'd try to obtain a private key. Note also that public keys would make rather good i-numbers -- for those who would like to, they can ignore that they are public keys and do i-number-based verification only, because they are simply numbers. For those who don't care about i-numbers, they use their public key aspects. Win-win, perhaps? There is also the case -- which Stefan Brands would undoubtedly bring up if he was on this list -- that the IdP may be hostile, or may become hostile. (think of, say, a large OpenID provider going out of business, and being bought out by spammer.com -- or just the domain name whose registration lapsed) A scheme that is public key based is inherently more resilient towards this than one that is not. You certainly don't want to trust spammer.com to honor whatever conventions the previous owner of the domain put in place to disambiguate their users. -- Overall, I'm not sure we are ready in this community to pick one alternative over another as the standards. I have my views, (many) others have (many) others -- and I don't think that any of this has to be in an Authentication 1.x (x1) or 2.0 spec, whatever it will be. This seems like a clean add-on. On May 30, 2007, at 22:01, Drummond Reed wrote: Johannes: What about the point Dick posted earlier in this thread, that the problem with using a public key is if the private key gets compromised? Persistent identifiers need to persist independent of any attribute changing or being revoked. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Wednesday, May 30, 2007 9:54 PM To: OpenID specs list Subject: Re: Specifying identifier recycling On May 30, 2007, at 21:02, Johnny Bufu wrote: ...The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Public keys ... public keys ... with the added benefit that no centralized or trusted verification service needs to be employed whatsoever ... Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net 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: Specifying identifier recycling
On 2-Jun-07, at 5:14 PM, Recordon, David wrote: I'd like to see this written as an extension so that if the first approach doesn't work, the Auth spec itself doesn't have to be reverted. Rather we can finish 2.0 and try implementing different approaches before deciding on the final way to solve this problem. I thought we had agreed at IIW (for good reason) to address this in 2.0. Other than the actual solution not being 100% clear, has anything changed? Arguments for not putting it into an extension: - users of provider's X who employs 'identifier recycling extension' would not be able to log into RP Y who doesn't understand the extension - it's likely that whatever solution we come up with affects the discovery / verification processes, in which case it couldn't be pushed to an extension (we're trying to patch something about the _identifier_ itself, which is the center of each openid transaction). Also, I believe the fragment approach can actually work, as detailed here: http://openid.net/pipermail/specs/2007-May/001767.html I haven't seen any replies to this, so would appreciate if others would go through the proposed changes and see if they all makes sense of I've overlooked something. Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
I wasn't in that session (as far as I recall ;-)) so I don't know either what was agreed on, or who agreed, or for what reasons ... the thread so far does not look like it was a very stable agreement ;-) On Jun 2, 2007, at 22:11, Johnny Bufu wrote: On 2-Jun-07, at 5:14 PM, Recordon, David wrote: I'd like to see this written as an extension so that if the first approach doesn't work, the Auth spec itself doesn't have to be reverted. Rather we can finish 2.0 and try implementing different approaches before deciding on the final way to solve this problem. I thought we had agreed at IIW (for good reason) to address this in 2.0. Other than the actual solution not being 100% clear, has anything changed? Arguments for not putting it into an extension: - users of provider's X who employs 'identifier recycling extension' would not be able to log into RP Y who doesn't understand the extension - it's likely that whatever solution we come up with affects the discovery / verification processes, in which case it couldn't be pushed to an extension (we're trying to patch something about the _identifier_ itself, which is the center of each openid transaction). Also, I believe the fragment approach can actually work, as detailed here: http://openid.net/pipermail/specs/2007-May/001767.html I haven't seen any replies to this, so would appreciate if others would go through the proposed changes and see if they all makes sense of I've overlooked something. Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
Johnny Bufu wrote: We did look at this (with Drummond) in December. The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Indeed, CanonicalID verification would be necessary, but it's already necessary if you want to accept XRI-based logins anyway. Last time we were talking about this CanonicalID verification for XRI was not yet specified. Is it now specified somewhere? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
Just for reference, this draft spec takes a look at key discovery for OpenID URLs. http://openid.net/specs/openid-service-key-discovery-1_0-01.html --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Friday, June 01, 2007 1:40 PM To: Nat Sakimura Cc: 'OpenID specs list' Subject: Re: Specifying identifier recycling On May 31, 2007, at 18:41, Nat Sakimura wrote: Public key idea is somewhat attractive to me, but there are some issues that comes up in my mind as well. Bring them on ;-) 1) Storing many users' private key on the server in decryptable format is not very safe. In your proposal, it looks like that OP is going to hold the private key for each user in decryptable format. Considering that most large scale privacy leakage happens at the server side, I have got a feeling that such thing like private key in a shared location. How would this be less safe than storing many shared secrets (per OpenID Auth) in decryptable format, or clear-text (more likely) on the server? Note that these private keys would not be general-purpose private keys, but only for the specific purpose we are discussing here. Also, I suspect that the use of these keys would be fairly infrequent compared to other operations, so conceivably one could add additional safeguards of various kinds if that was needed. 2) It may mean a high cost operation for OPs. If we do this, it makes OP operation very high cost because to make the service safe, it would require a lot of measures. (NRI is providing similar kind of service but it indeed is very high cost operation.) Nice thing about i-number is that it has no value like public key except for its resolvability. Even if it leaks, that's kind of ok so operational risk is low. This comparison does not work very well for me. However: I don't know the details of how to avoid impersonation via i-numbers (in case of key pairs, it would be private key leaks and is reused by attacker -- what would be the equivalent for i-numbers?), but I suspect there are some measures that prevent attackers from impersonation by using somebody else's i-number? If so, aren't they similarly susceptible to attack? Actually, these private key pain may be eased by IBE (Identity Based Encryption) but I need some more time to contemplate on it. I had somebody else mention this to me -- I wonder whether anybody could put together an actual proposal. 3) Since OPs has an access to the users' private key, they may recycle them as well. IMHO, recycling is operational problem as well as a technical one. i-number from a certified i-broker is somewhat trustable on the account of no recycling because of this operational restriction. Could there be operational restriction similart to that for general OPs as well? There could, and -- I suspect -- in the longer term there probably will, but the whole point about a decentralized system like OpenID is to keep the playing field level without a central entity in the middle for the maximum length of time and scope possible. In any case, I think we should use the approach to use (decentralized) technology to the maximum extent possible, and only add operational requirements when unavoidable. (And I know that many people on this list would scream bloody murder if anybody seriously proposed such a centralized requirement for OpenID usage ...) Personally I would feel we didn't think hard enough on this particular problem if the solution to this problem required us to use centralization of some kind. =nat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Thursday, May 31, 2007 2:30 PM To: OpenID specs list Subject: Re: Specifying identifier recycling If we cannot assume that nobody manages to obtain a secret they should not have gotten in the first place, then OpenID as it stands is rather useless as we cannot trust its authentication scheme. Note that the surface through which the D-H shared secret can escape is about twice as large as the surface through which a private key can escape -- because an RP does not have access to the private key. In other words, if I was an attacker, I'd go after a lot of things first before I'd try to obtain a private key. Note also that public keys would make rather good i-numbers -- for those who would like to, they can ignore that they are public keys and do i-number-based verification only, because they are simply numbers. For those who don't care about i-numbers, they use their public key aspects. Win-win, perhaps? There is also the case -- which Stefan Brands would undoubtedly bring up if he was on this list -- that the IdP may be hostile, or may become hostile. (think of, say, a large OpenID provider going out of business, and being bought out by spammer.com -- or just
RE: Specifying identifier recycling
Public key idea is somewhat attractive to me, but there are some issues that comes up in my mind as well. 1) Storing many users' private key on the server in decryptable format is not very safe. In your proposal, it looks like that OP is going to hold the private key for each user in decryptable format. Considering that most large scale privacy leakage happens at the server side, I have got a feeling that such thing like private key in a shared location. 2) It may mean a high cost operation for OPs. If we do this, it makes OP operation very high cost because to make the service safe, it would require a lot of measures. (NRI is providing similar kind of service but it indeed is very high cost operation.) Nice thing about i-number is that it has no value like public key except for its resolvability. Even if it leaks, that's kind of ok so operational risk is low. Actually, these private key pain may be eased by IBE (Identity Based Encryption) but I need some more time to contemplate on it. 3) Since OPs has an access to the users' private key, they may recycle them as well. IMHO, recycling is operational problem as well as a technical one. i-number from a certified i-broker is somewhat trustable on the account of no recycling because of this operational restriction. Could there be operational restriction similart to that for general OPs as well? =nat -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Thursday, May 31, 2007 2:30 PM To: OpenID specs list Subject: Re: Specifying identifier recycling If we cannot assume that nobody manages to obtain a secret they should not have gotten in the first place, then OpenID as it stands is rather useless as we cannot trust its authentication scheme. Note that the surface through which the D-H shared secret can escape is about twice as large as the surface through which a private key can escape -- because an RP does not have access to the private key. In other words, if I was an attacker, I'd go after a lot of things first before I'd try to obtain a private key. Note also that public keys would make rather good i-numbers -- for those who would like to, they can ignore that they are public keys and do i-number-based verification only, because they are simply numbers. For those who don't care about i-numbers, they use their public key aspects. Win-win, perhaps? There is also the case -- which Stefan Brands would undoubtedly bring up if he was on this list -- that the IdP may be hostile, or may become hostile. (think of, say, a large OpenID provider going out of business, and being bought out by spammer.com -- or just the domain name whose registration lapsed) A scheme that is public key based is inherently more resilient towards this than one that is not. You certainly don't want to trust spammer.com to honor whatever conventions the previous owner of the domain put in place to disambiguate their users. -- Overall, I'm not sure we are ready in this community to pick one alternative over another as the standards. I have my views, (many) others have (many) others -- and I don't think that any of this has to be in an Authentication 1.x (x1) or 2.0 spec, whatever it will be. This seems like a clean add-on. On May 30, 2007, at 22:01, Drummond Reed wrote: Johannes: What about the point Dick posted earlier in this thread, that the problem with using a public key is if the private key gets compromised? Persistent identifiers need to persist independent of any attribute changing or being revoked. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Wednesday, May 30, 2007 9:54 PM To: OpenID specs list Subject: Re: Specifying identifier recycling On May 30, 2007, at 21:02, Johnny Bufu wrote: ...The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Public keys ... public keys ... with the added benefit that no centralized or trusted verification service needs to be employed whatsoever ... Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net 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: Specifying identifier recycling
On May 30, 2007, at 13:28, Josh Hoyt wrote: After thinking this over for a while, I'm no longer convinced that using URI fragments as the uniquifying value is the right approach. I agree with you. Our reasons may differ slightly, but the result is the same. I have no problem in not solving this problem this time around. I would have a problem with adding a solution to the spec that turns out to not be a solution after all. ;-) Cheers, Johannes. Johannes Ernst NetMesh Inc. inline: openid-relying-party-authenticated.gifinline: lid.gif http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
At some point, the weak link will be humans trying to disambiguate http://joe.example.org/ from http://joe.example.org/2 (or http://joe.example.org/#2). I don't think there's a big difference between the two in that context, and I don't think that OID2 needs to solve this more deeply than allowing unique-URL. But would this be an additional requirement placed on OPs? (Query: I assume a 302 redirect from http://joe.example.org to http://joe.example.org/2 will work?) Has there been a discussion about an extension to map to/from i-numbers via AX? If there were a generic attribute you could stuff an i-number or a hash of an internal ID in there to help solve the disambiguation problem. Alternatively it'd be nice to have a way to ask when the account was created, if the OP is amenable. -John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
John Panzer wrote: Has there been a discussion about an extension to map to/from i-numbers via AX? If there were a generic attribute you could stuff an i-number or a hash of an internal ID in there to help solve the disambiguation problem. Alternatively it'd be nice to have a way to ask when the account was created, if the OP is amenable. If you're going to use i-numbers, then there's no reason at all not to use the XRD CanonicalID element. The same mechanism that's used to map i-names onto i-numbers can also be used to map URLs onto i-numbers, or URLs onto other URLs. I'm sure Drummond can talk in more detail about this. We did discuss it briefly at IIW, but once the majority had decided that the fragment approach was the way to go we didn't get a chance to investigate this further. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
On 30-May-07, at 6:21 PM, Martin Atkins wrote: John Panzer wrote: Has there been a discussion about an extension to map to/from i- numbers via AX? If there were a generic attribute you could stuff an i- number or a hash of an internal ID in there to help solve the disambiguation problem. Alternatively it'd be nice to have a way to ask when the account was created, if the OP is amenable. If you're going to use i-numbers, then there's no reason at all not to use the XRD CanonicalID element. The same mechanism that's used to map i-names onto i-numbers can also be used to map URLs onto i-numbers, or URLs onto other URLs. I'm sure Drummond can talk in more detail about this. We did discuss it briefly at IIW, but once the majority had decided that the fragment approach was the way to go we didn't get a chance to investigate this further. We did look at this (with Drummond) in December. The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
On 30-May-07, at 1:28 PM, Josh Hoyt wrote: How should the discovery process work? How should fragments work with delegation (both as the claimed identifier and the provider-local identifier)? Here's how I see the fragments approach working: a) Discovery: strip the fragment from the user-supplied identifier before initiating discovery. b) Auth response: if a different op-local identifier is not specified, the claimed identifier sans fragment MUST be used as the value for openid.identity. c) Verification of discovered information against auth response fields: strip_fragment(openid.claimed_id) == discovered claimed id openid.identity == discovered op-local id (no change) d) Identifying the user: openid.claimed_id in auth response SHOULD be used as a key (no change) strip_fragment(openid.claimed_id) MAY be used as user-visible id From your list of issues: 1. Using a URI fragment with a uniquifying value: * Potential problems with initiation and discovery No issues with the proposal above (but please think over and confirm!) * Potential problems with inconsistent behaviours on OpenID 1 sites OPs should send claimed IDs with fragments only for OpenID2 messages. * URLs that user see may be ugly or inconsistent across sites (if some relying parties do and others do not strip the fragment before display) Maybe enforce that fragments SHOULD NOT be used for display? * There is no difference between different versions of a *user-displayed* identifier (users can't tell if a reference to a URL in the wild belongs to the current ownder of a URL or another user). Not sure how RPs can be notified and then how they should act when an identifier gets recycled. Do we need to deal with this? Here are three scenarios and what would happen in each case: -- no delegation: user-supplied id: http://example.com/user#1234 or: user-supplied id: http://example.com/user discovery: claimed id = http://example.com/user op-local id = http://example.com/user auth request: openid.claimed_id=http://example.com/user openid.identity=http://example.com/user auth response: openid.claimed_id=http://example.com/user#1234 openid.identity=http://example.com/user -- delegation (1): user-supplied id=http://blog.com/ http://blog.com/ delegates to http://op.com/user#4567 discovery: claimed id=http://blog.com/ op-local id=http://op.com/user#4567 auth request: openid.claimed_id=http://blog.com/ openid.identity=http://op.com/user#4567 auth response: openid.claimed_id=http://blog.com/ openid.identity=http://op.com/user#4567 -- delegation (2): user-supplied id=http://blog.com/#1234 http://blog.com/ delegates to http://op.com/user#4567 discovery: claimed id=http://blog.com/ op-local id=http://op.com/user#4567 auth request: openid.claimed_id=http://blog.com/ openid.identity=http://op.com/user#4567 auth response: openid.claimed_id=http://blog.com/#1234 openid.identity=http://op.com/user#4567 - a binding between http://op.com/user#4567 and the http://blog.com/ #1234 claimed id must be done somehow by the OP - do we need to support this use case? -- Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
Josh, On 30-May-07, at 1:28 PM, Josh Hoyt wrote: Providers can also provide a redirect from the general form of the identifier to the current version of the identifier so that users do not need to remember or type the uniquified version. This is pretty much equivalent to the fragment scheme, except: * It does not require spec changes (and is backwards-compatible!) * The uniquifying component is user-visible I'd like to hear opinions on whether this unique-URL solution is good enough to solve the problem. If Dick's original assessment on the requirements is right: Motivating use case: For large OPs, user identifier namespace is a scarce resource and they need to be able to recycle human readable identifiers Design Considerations: + Existing identifiers continue to work + A human readable, memorable identifier can be entered by the user and displayed to other users + A globally unique identifier is user by RPs that is different for different users of the same human readable identifier ... by pushing the uniquifying part into the displayed URL the displayed identifiers become unfriendly / human-unreadable. It would be great the ones who consider identifier recycling a show stopper agreed that your proposal is good enough. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
John Panzer wrote: Has there been a discussion about an extension to map to/from i- numbers via AX? If there were a generic attribute you could stuff an i- number or a hash of an internal ID in there to help solve the disambiguation problem. Alternatively it'd be nice to have a way to ask when the account was created, if the OP is amenable. Martin Atkins wrote If you're going to use i-numbers, then there's no reason at all not to use the XRD CanonicalID element. The same mechanism that's used to map i-names onto i-numbers can also be used to map URLs onto i-numbers, or URLs onto other URLs. I'm sure Drummond can talk in more detail about this. We did discuss it briefly at IIW, but once the majority had decided that the fragment approach was the way to go we didn't get a chance to investigate this further. Johnny Bufu wrote; We did look at this (with Drummond) in December. The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Johnny: Martin, Gabe, and I discussed this at IIW, and the CanonicalID verification process that's specified in the XRI Resolution 2.0 Working Draft 11 specification (of which the first editor's draft has now been posted - see below) could be applied even if the XRDS was discovered via a URL. To do this, RP code would need to confirm the CanonicalID i-number was authoritative for the XRDS, which is essentially the same process the RP has to go through anyway when the OP returns a different identifier than the one the user originally entered at the RP (such as in the directed identity flow). In the first editor's draft of WD11, we only specified Canonical ID verification when an XRDS was discovered from an XRI. But in the second editor's draft (due early next week), we could add text specifying how to do Canonical ID verification when the XRDS is discovered from a URL. Although it's not yet content complete, you can review the Canonical ID verification section (section 11) as well as the Yadis section (section 8) in the first editor's draft of WD11 at: http://www.oasis-open.org/committees/download.php/24096/xri-resolution-v2.0- wd-11-ed-01.doc To make it easier to review, we've also posted section 8 (the Yadis section) as a wiki page on the XRI TC wiki. See my next message about that. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Specifying identifier recycling
Johannes: What about the point Dick posted earlier in this thread, that the problem with using a public key is if the private key gets compromised? Persistent identifiers need to persist independent of any attribute changing or being revoked. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Wednesday, May 30, 2007 9:54 PM To: OpenID specs list Subject: Re: Specifying identifier recycling On May 30, 2007, at 21:02, Johnny Bufu wrote: ...The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Public keys ... public keys ... with the added benefit that no centralized or trusted verification service needs to be employed whatsoever ... Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Specifying identifier recycling
If we cannot assume that nobody manages to obtain a secret they should not have gotten in the first place, then OpenID as it stands is rather useless as we cannot trust its authentication scheme. Note that the surface through which the D-H shared secret can escape is about twice as large as the surface through which a private key can escape -- because an RP does not have access to the private key. In other words, if I was an attacker, I'd go after a lot of things first before I'd try to obtain a private key. Note also that public keys would make rather good i-numbers -- for those who would like to, they can ignore that they are public keys and do i-number-based verification only, because they are simply numbers. For those who don't care about i-numbers, they use their public key aspects. Win-win, perhaps? There is also the case -- which Stefan Brands would undoubtedly bring up if he was on this list -- that the IdP may be hostile, or may become hostile. (think of, say, a large OpenID provider going out of business, and being bought out by spammer.com -- or just the domain name whose registration lapsed) A scheme that is public key based is inherently more resilient towards this than one that is not. You certainly don't want to trust spammer.com to honor whatever conventions the previous owner of the domain put in place to disambiguate their users. -- Overall, I'm not sure we are ready in this community to pick one alternative over another as the standards. I have my views, (many) others have (many) others -- and I don't think that any of this has to be in an Authentication 1.x (x1) or 2.0 spec, whatever it will be. This seems like a clean add-on. On May 30, 2007, at 22:01, Drummond Reed wrote: Johannes: What about the point Dick posted earlier in this thread, that the problem with using a public key is if the private key gets compromised? Persistent identifiers need to persist independent of any attribute changing or being revoked. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst Sent: Wednesday, May 30, 2007 9:54 PM To: OpenID specs list Subject: Re: Specifying identifier recycling On May 30, 2007, at 21:02, Johnny Bufu wrote: ...The bottom line is that it can't be done easily - a mechanism similar to XRI's canonical ID verification would have to be employed, to confirm that the i- number actually 'belongs' to the URL on which discovery was initiated. (Otherwise anyone could put any i-number in their URL- based XRDS files.) Public keys ... public keys ... with the added benefit that no centralized or trusted verification service needs to be employed whatsoever ... Johannes Ernst NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
