RE: OpenID Provider Authentication Policy Extension
Great work, David. +1 to Han's comments -- they are good points. Coming up with a better semantic identifier for the phishing-resistant policy isn't easy but I like his point that it really comes down to the definition that no shared secret is available to a third party. Perhaps non-shared-secret? omnidirectional-token? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hans Granqvist Sent: Friday, June 22, 2007 3:50 PM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID Provider Authentication Policy Extension A few comments: * Would be great if all the namespace URLs resolved into live links. It always helps in the XML world and probably would in here too. * Section 4 Defined Authentication Policies We've talked about this before, but I just want to restate that it is a bad idea to name a policy based on its inferred values. Phishing-resistant implies a quality that is not necessarily measurable. Quality can also shift over time. The other policies are measurable (you can count number of factors used, for example). I'd strongly advise renaming phishing-resistant to something like no-secrets-shared (you can probably come up with a more succinct term) * 5.2 response params Requiring openid.pape.auth_policies to have a null value if no policies were met seems odd (and it may break processing where a value is always expected by the parser). Better would be to explicitly state that no policies were met by a predefined literal or URL. For example openid.pape.auth_policies=http://schemas.openid.net/pape/policies/2007/06/no ne * Section 7 Examples I wanted to see some examples on how PAPE is used in the messages. Maybe add a few? I like the work. However, the spec is optional. I was hoping finalizing auth 2.0 would be top priority. -Hans On 6/22/07, Recordon, David [EMAIL PROTECTED] wrote: Over the past few weeks I've been working on the OpenID Provider Authentication Policy Extension which is designed to replace the work I did last year with the Assertion Quality Extension. Generally, the goal of this extension is to provide Relying Parties with more information about how the End User authenticated to their Provider. This is done by a mix of the RP requesting certain policies (such as phishing-resistant or multi-factor), the OP helping the End User through the authentication process, and then in the OpenID Authentication response including the policies that were met as well as optionally a strength level for the overall authentication. This extension doesn't speak at all toward trust of the End User or Provider, so RPs will still have to decide if they believe the information returned about the authentication in the response. So please, check it out and let me know what you think...especially around the questions in the Editorial Comments section at the end. http://openid.net/specs/openid-provider-authentication-policy-extension- 1_0-01.html http://openid.net/specs/openid-provider-authentication-policy-extension- 1_0-01.txt Thanks, --David ___ 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
Writeup of XRDS Canonical ID verification for URLs and XRIs
Dick Hardt wrote: Just to clarify, I do *not* propose we add support for multiple identifiers in OpenID 2.0 -- but hope that this discussion sheds light that there are other ways of solving the problem besides having a permanent directory of identifiers aka the i-names/i-numbers mechanisms. After discussion at IIW, and subsequently on this list last week, the OASIS XRI TC held a special telecon on Monday to discuss extending XRDS Canonical ID verification to URLs as well as XRIs. This approach addresses Dick's issue by enabling verification of any mapping of reassignable to canonical identifiers (URL-to-URL, URL-to-XRI, XRI-to-URL, XRI-to-XRI). In short, it would give OpenID users the same choice over their canonical identifier that they currently have over their claimed identifier. With the Yadis specification now included in section 4 of XRI Resolution Working Draft 11 (see http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris for a copy of the text of this section -- thanks to David, Johnny, and Rowan for feedback on the first draft), extending Canonical ID verification to cover any combination of URLs and XRIs is quite straightforward. The formal proposal is now fully written up on the XRI TC wiki. The first link below is to the full page; the second takes you directly to the example section. http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification?action=show#h ead-a68aa13f6815124db6fbf909f172529e2783ae62 Feedback actively solicited -- further discussion is planned on the XRI TC telecon at 10AM Pacific tomorrow morning. If anyone would like to join that call, just send me email for an invitation. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Generalized solution to OpenID recycling (was RE: The WordPress User Problem)
David Recordon wrote: snip of explanation of problems with fragment solution to OpenID recycling 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, first I just want to point out that XRI i-numbers are no more centralized than DNS, so I don't think there's any difference between #2 and #3 other than #2 uses XRI registries and #3 uses DNS registries. Second, I agree with you that the better architectural approach to the OpenID recycling problem is to provide a standard reassignable-to-persistent synonym mapping capability that will work for both URLs and XRIs (and even URNs). This solves the problem by allowing *any* reassignable identifier (either a URL, or an XRI i-name) to be mapped to *any* persistent identifier (either a persistent URL, an XRI i-number, or even a resolvable URN). The fragment solution is in fact just a special case of this architecture, i.e., it maps a URL-without-a-fragment (reassignable) to the-same-URL-with-a-fragment (persistent). It does have some special issues due to the use of URL fragments vs. other components of a URI, but otherwise it is just one option that could be implemented to map a reassignable to a persistent identifier. As Martin has pointed out, the purpose of the CanonicalID element in XRDS is to support reassignable-to-persistent identifier mapping. Although this is a native function of XRI resolution (because XRI architecture was explicitly designed to address the reassignable-to-persistent synonym mapping problem and thus has explicit syntax for reassignable and persistent identifiers), there is nothing to prevent CanonicalID mapping from being done with URLs. Discussion on this thread so far has only entertained using this mechanism to handle reassignable-URL to persistent-XRI mapping, however there's nothing to prevent it being used for reassignable-URL to persistent-URL mapping, or even reassignable-URL to persistent-URN mapping (as long as the URN is resolveable, such as a Handle ID). Everything is already in place in XRDS architecture except the Canonical ID verification rules. The OASIS XRI TC has already published the reassignable-XRI-to-persistent-XRI Canonical ID verification rules in the first editor's draft of XRI Resolution 2.0 Working Draft 11 (a more detailed explanation of those rules will be in the second editor's draft due out tomorrow). Per Martin's suggestion, in the second editor's draft will also add the Canonical ID verification rules for reassignable-URL-to-persistent-XRI mapping. I see no reason we can't add the rules for reassignable-URL-to-persistent-URL mapping as well, since it's simply a matter of the RP confirming that the persistent identifier is also authoritative for the XRDS. If we approached it this way, all the OpenID Authentication 2.0 spec would need to do is specify the use of Canonical ID verification as part of the OpenID discovery process, and then everyone -- users, OPs, and RPs, would be able to use any reassignable-OpenID-identifier-to-persistent-OpenID-identifier mapping process that worked best for them. Thoughts? =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: The WordPress User Problem (WAS: RE: Specifying identifierrecycling)
Josh Hoyt wrote: 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). Isn't this a core flaw with the fragment approach? That if you lose control of the base identifier, you lose control of any fragment? Wouldn't it be fairly easy -- precisely because the fragment is not secret -- for the party that takes over the base identifer to discover the fragment(s) that have been used earlier, and thus for the new owner to then be able to spoof any fragment that has been issued? I supposed this doesn't apply to large sites, where all identifiers are managed in trust for users and they can enforce non-access to previous fragments. But for personal URLs it doesn't appear to work at all. Am I missing anything? =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: The WordPress User Problem (WAS: RE: Specifying identifierrecycling)
David, just want to reinforce that the CanonicalID element in XRDS has always been defined as containing anyURI, so it's been there to support mapping of any reassignable identifier to any persistent identifier (or, technically, any canonical identifier, even if not persistent, though persistence is the main use case for it). I'm happy to help with the writeup -- I've already spent a not-insignificant portion of my lifespan dealing with this issue ;-) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Tuesday, June 05, 2007 3:50 PM To: Johnny Bufu Cc: OpenID specs list Subject: RE: The WordPress User Problem (WAS: RE: Specifying identifierrecycling) 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 ___ 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 on the
