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: Final outstanding issues with the OpenID 2.0 Authenticationspecification
Claus Färber wrote: Marius Scurtescu schrieb: The new attribute values are needed in order to signal an OpenID 2 provider. Why is this necessary? Is OpenID 2 incompatible? In other words, what happens if an OpenID 2 Relying Party tries to talk to an OpenID 1.x Provider? If the OpenID 1.x Provider just ignores additional message fields (i.e. treats them like an unknown extension), then no new rel values are needed. If this is not the case, maybe the OID 2 spec can be changed to make it possible. One incompatibility that springs to mind is that it is permissable to talk to a 2.0 OP via a POST request with the arguments in the entity body, while a 1.1 will likely barf on this since 1.1 only allowed for GET requests with the arguments in the query string. A 2.0 RP that uses a GET request and uses extension prefixes that match the ad-hoc field names used for the 1.1 extensions could, in theory, talk to a 1.1 OP without any problems. That is, unless I've missed something. :) ___ 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
