Re: Please clarify 2.0 TOC 14 -- Re: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification
Kevin, thanks for commenting on that. But no, openid.realm is not an URL, it's a pattern (see 2.0-11, 9.2 Realms). The spec currently doesn't tell how to derive the XRDS URL from openid.realm. So the question remains, where to publish that document? Other uses? Well, I'm running an OP in germany, and the phishing issue is quite a show stopper over here. So I am trying to change that. After some posts to these lists and a lengthy talk between Dmitry and me last week, there is at least consensus between us two, that the protocol as-is offers little to no help for user agents to get a grip on it. Now, letting user agents detect RPs or OPs based on guesswork isn't exactly helpful to the phishing topic (imo). Unfortunately (and that may be my fault, failing *how* to say it) my suggestions didn't go down particularly well here. So, letting UAs detect an RP by its XRDS document would just be a start, though I'm still of the opinion that detecting an OP is much more important and that it cannot be done robustly by joining in at the RP -- mostly, because the protocol defines no constraints for continuity regarding the RP-OP transition (which in the short-run would be wrong anyway, I think). OTOH, talking to the responsible mozilla (sub)project lead, gets me to the conclusion (which may be wrong) that they still dont't have too many ideas about how a user agent could support OpenID in detail. So, I'm hoping to be not too obtrusive repeating this very same issue over and over, but I think it's still valid. regards -- Boris On 5/23/07, Kevin Turner [EMAIL PROTECTED] wrote: On Fri, 2007-05-18 at 22:21 +0200, Boris Erdmann wrote: http://openid.net/specs/openid-authentication-2_0-11.html#anchor34 Should the document be placed under http://relyingparty.com/ or http://relyingparty.com/return_to_url? or does it have to be link rel'ed in every page? For the proposed check against realm forgery, you'll want to make sure it's available at the URL given in the openid.realm parameter of your checkid request. Josh is currently writing up the details on that. For other uses, I think the answer is it depends; what are those uses? Publishing it at return_to_url doesn't seem to be very useful, because it's the return_to url that the seeker would be trying to discover. That would be the equivalent of a sign saying you are here and nothing more. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
clarifying section 11.2 in draft 11 for HTML discovery?
Section 11.2 states If the Claimed Identifier was not present in the request (openid.identity was http://specs.openid.net/auth/2.0/identifier_select;), the Relying Party MUST perform discovery on the Claimed Identifier in the response to make sure that the OP is authorized to make assertions about the Claimed Identifier. It then goes on to illustrate how an XRDS document could be constucted for verifying an OP's authority in such a post-assertion discovery process. It would seem logical that HTML discovery should be an option here, and that a confirming HTML document would include the usual LINK elements. For instance, if the OP Endpoint URL was https://id.plumbers.co/ and the identifier in the assertion was https://id.plumbers.co/users/1234 then HTML discovery for 11.2 would work by requesting the URL https://id.plumbers.co/users/1234 and verfiying that its HREF for openid2.provider was https://id.plumbers.co/; and the HREF for openid2.local_id was https://id.plumbers.co/users/1234;. But as it stands, only XRDS (XRI/Yadis?) post-assertion discovery is discussed. Shouldn't the spec clarify what is required for an HTML discovery to uphold an assertion that triggers 11.2's discovery process? -Peter ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: clarifying section 11.2 in draft 11 for HTML discovery?
On 24-May-07, at 8:19 AM, Peter Watkins wrote: Section 11.2 states If the Claimed Identifier was not present in the request (openid.identity was http://specs.openid.net/auth/2.0/ identifier_select), the Relying Party MUST perform discovery on the Claimed Identifier in the response to make sure that the OP is authorized to make assertions about the Claimed Identifier. It then goes on to illustrate how an XRDS document could be constucted for verifying an OP's authority in such a post-assertion discovery process. It would seem logical that HTML discovery should be an option here, and that a confirming HTML document would include the usual LINK elements. For instance, if the OP Endpoint URL was https:// id.plumbers.co/ and the identifier in the assertion was https://id.plumbers.co/ users/1234 then HTML discovery for 11.2 would work by requesting the URL https://id.plumbers.co/users/1234 and verfiying that its HREF for openid2.provider was https://id.plumbers.co/; and the HREF for openid2.local_id was https://id.plumbers.co/users/1234;. But as it stands, only XRDS (XRI/Yadis?) post-assertion discovery is discussed. Shouldn't the spec clarify what is required for an HTML discovery to uphold an assertion that triggers 11.2's discovery process? Section 11 is, again, about how RPs consume the assertions; specifically, it explains how the mappings between discovered information and assertion data must be checked. Discovery is covered in detail in section 7.3 (and referenced from section 11). If we go into too many details about discovery in section 11, it may lead readers to believe that is the authoritative section about discovery, and possibly overlook important items specified in section 7.3 (not to mention adding to the perceived complexity of the spec...) That's why a short, non-normative example was preferred in that place. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: clarifying section 11.2 in draft 11 for HTML discovery?
On 5/24/07, Peter Watkins [EMAIL PROTECTED] wrote: Shouldn't the spec clarify what is required for an HTML discovery to uphold an assertion that triggers 11.2's discovery process? The spec as it is currently written does not support using identifier selection with HTML discovery. That was intentional, to keep things simpler. A user should never have to add markup to trigger identifier selection. That is the responsibility of the OpenID provider. I don't think we need to add a way to trigger identifier selection with HTML discovery. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Realm spoofing spec patch
Hello, I've added a section to the specification[1] about performing verification on the realm to avoid realm spoofing. In short, realm spoofing is the problem of exploiting a bug on a site that a user would trust to trick them into sending their information to a site that they would not trust. This is very similar to many phishing attacks. The difference between this type of attack and a standard phishing attack is that the user will (usually) only see the realm, and the realm may actually be trusted, so even an educated user who's paying attention may be vulnerable. There are also (minor) changes to the section on discovering relying parties[2]. The fix that is described is for the relying party to provide a whitelist of URL patterns that should be usable as return_to URLs. Relying parties should be as restrictive as possible when specifying return_to URLs. This is the fix that was discussed at the Internet Identity Workshop, by all of the spec editors and several prominent members of the OpenID community. Please review the additions. If you'd like to see the specific changes, you can look at the diffs in revision control[3]. Josh 1. http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn-327.html#return_to_verification 2. http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn-327.html#return_to_verification 3. http://openid.net/svn/listing.php?repname=specificationspath=rev=326sc=1 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
attribute exchange value encoding
Hello list, While at IIW, I asked around what people thought about the encoding mechanisms we've added recently, in order to allow for transferring any data types. The consensus was that everyone would prefer something simpler and lighter. So I've rewritten the encoding section, such that: - for strings, only the newline (and percent) characters are required to be escaped, (to comply with OpenID's data formats), using percent-encoding; - base64 must be used for encoding binary data, and defined an additional field for this: openid.ax.encoding.alias=base64 Please review section 3.3 Attribute Values to see if there are any issues. One remaining question is about the choice of encoding for strings. Percent-encoding (RFC3968) seems the simplest from a spec perspective, however some libraries provide (better) support for the older URL-encoding (RFC1738), which throws '+' characters into the mix. Which do you think would work best for implementers, users, and would cause less interop problems? Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Realm spoofing spec patch
Hey Josh, Thanks for writing this up! I'm a bit confused by the number of SHOULDs in this patch. +Relying Parties SHOULD use the Yadis protocol to publish their +valid return_to URLs. The relying party MAY publish this +information at any URL, and SHOULD publish it under the realm +so that providers can verify return_to URLs. +OpenID providers SHOULD verify that the return_to URL +specified in the request is an OpenID relying party +endpoint. +If verification is attempted and fails, the provider +SHOULD NOT send a positive assertion to that return_to +URL. It seems that this methodology only works if either: 1) Every site (RP or proxy) publishes their return_to endpoints or that they don't have any. 2) An OP refuses to let the user login to a RP which doesn't publish their return_to endpoint. I'm unconvinced that either of those situations will actually become prevalent and thus worried about the effectiveness of this methodology. Using the same example from IIW, I am logging into http://evilrp.com/return_to which is proxying itself through http://www.google.com/translate/. If my OP were to prompt me, We're unable to verify the site (http://www.google.com/translate/?http://evilrp.com/return_to) you're logging into, you should use caution when proceeding I'm unsure how many users would actually not proceed, or rather see google.com and decide it is alright. I guess since we're unable to fully resolve this issue from a technical perspective, and no I don't have a better technical solution, I'm wondering if this should actually be an extension to the core protocol versus seeming like a resolution to the problem when it really doesn't completely solve it. In some senses I see this as a larger problem around trust of Relying Parties. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, May 24, 2007 4:19 PM To: OpenID specs list Subject: Realm spoofing spec patch Hello, I've added a section to the specification[1] about performing verification on the realm to avoid realm spoofing. In short, realm spoofing is the problem of exploiting a bug on a site that a user would trust to trick them into sending their information to a site that they would not trust. This is very similar to many phishing attacks. The difference between this type of attack and a standard phishing attack is that the user will (usually) only see the realm, and the realm may actually be trusted, so even an educated user who's paying attention may be vulnerable. There are also (minor) changes to the section on discovering relying parties[2]. The fix that is described is for the relying party to provide a whitelist of URL patterns that should be usable as return_to URLs. Relying parties should be as restrictive as possible when specifying return_to URLs. This is the fix that was discussed at the Internet Identity Workshop, by all of the spec editors and several prominent members of the OpenID community. Please review the additions. If you'd like to see the specific changes, you can look at the diffs in revision control[3]. Josh 1. http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn- 327.html#return_to_verification 2. http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn- 327.html#return_to_verification 3. http://openid.net/svn/listing.php?repname=specificationspath=rev=326; sc=1 ___ 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: attribute exchange value encoding
On 24-May-07, at 5:15 PM, Johnny Bufu wrote: Please review section 3.3 Attribute Values to see if there are any issues. Of course it helps if there's a link to click on... I missed it in the previous message: http://openid.net/svn/filedetails.php?repname=specificationspath=% 2Fattribute_exchange%2F1.0%2Ftrunk%2Fopenid-attribute- exchange.htmlrev=0sc=0 Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
