Re: OpenID Security
On Fri, Feb 06, 2009 at 03:43:30PM -0500, McGovern, James F (HTSC, IT) wrote: 2. Which is worse, having to sort through false positives or to not perform static analysis at all and have OpenID fail once some bad guy busts the implementation so badly that everyone runs away from OpenID? What do you mean, the implementation? There is no the implementation. Are you arguing that for the OpenID *protocol* to succeed, every *implementation* has to be secure? That sounds like a marketing problem to me, and it's one you solve by having math/crypto experts ensure the *protocol* is good. Period. When someone finds a bug in Postfix, we don't say SMTP is broken and run away from email; we say Postfix version such-and-such is broken, Wietse fixes it, and we go on. I suppose you could argue for protocol compliance tools as part of protecting the OpenID image -- at least that might allow OpenID proponents to disown any insecure library that happened to fail the protocol tests. But I wouldn't expect too much from that, either. Automated testing is good for finding obvious problems, but it's no replacement for good, smart programming, and not a cure for bad code. I'd feel more comfortable with software that passed some long-running fuzzing tests, but you really don't want to be vouching for the security of specific implementations. That's just asking for trouble. -Peter ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Security certification
On Fri, Feb 06, 2009 at 01:34:33AM +0900, Nat Sakimura wrote: It might be worthwhile for somebody like OIDF to buy a license and run a certification program out of it. If OIDF wants to certify something, it should certify compliance to the OpenID standard. It would be good for OIDF to make any protocol certification tool freely available for developers to run on their own systems. -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 Thu, May 24, 2007 at 10:19:08AM -0700, Josh Hoyt wrote: 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. Speaking as a potential OP, I like the idea that I could support directed identity for all my users by simply adding a couple tags to a web page -- for instance, setting openid2.local_id to the identifier_select URL. HTML discovery's simplicity is appealing. It's also appealing to have a single URL that would be usable in an OpenID login form and would display helpful content to users. The XRI spec draft looks overwhelming. Yadis doesn't look too bad -- essentially, any old HTML page could be used, so long as it included one tag that contained the URL of an XRDS file. I would have found it valuable for the openid 2.0 spec to include an example of using a meta http-equiv tag for Yadis discovery. It's too bad Yadis doesn't allow embedding the XRDS document in something like a META tag to avoid that second Yadis HTTP request, but perhaps that's something I should take up at yadis.org. :-) Peter ___ 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: HTML discovery: SGML entities and charsets
On Mon, May 21, 2007 at 11:50:32AM -0700, Josh Hoyt wrote: On 5/20/07, Claus Färber [EMAIL PROTECTED] wrote: Peter Watkins schrieb: 7.3.3 in draft 11 says The openid2.provider and openid2.local_id URLs MUST NOT include entities other than amp;, lt;, gt;, and quot;. Other characters that would not be valid in the HTML document or that cannot be represented in the document's character encoding MUST be escaped using the percent-encoding (%xx) mechanism described in [RFC3986] (Berners-Lee, T., .Uniform Resource Identifiers (URI): Generic Syntax,. .). Please note that the draft is completely broken here: Can you suggest improvements and examples or test cases of how you think it should work? There has been a little discussion in the past about the restriction on allowed character entity references. I don't think there has been any about numeric character references, except in lumping them in with character entity references. These restrictions live on from the OpenID 1 specification, and were preserved primarily to ease backwards compatibility (IIRC). I don't think it's reasonable to expect RP code to be capable of parsing every possible charset in which an HTML page might be encoded. I also don't think it's reasonable to specify specific charsets that RPs should be able to decode and then require OpenID users to use those charsets in their web pages just so RPs can parse these two link elements. I believe the contents of those two tags' HREF attributes should be defined as UTF-8 representations of the URLs, encoded per RFC 3986. As Claus has pointed out, this is NOT a normal way of embedding *text* within an SGML/HTML document. That's true. Normally the HTML document would contain text either in the appropriate bytes for the page's charset or in SGML entity representations. That generally works for HTML because HTML is designed to be read by humans. If my browser doesn't understand the big5 charset used for Chinese text, that's normally OK because I cannot read Chinese. A link in a big5 HTML document to an internationalized URL may not be deciperable by my web browser, and that's normally OK because an internationalized Chinese URL in a Chinese-language document is probably nothing I could read, anyway. HTML is designed for human communication. But we're not talking about text here, and there's no expectation that the RP should be able to read the text in the HTML document at the user's claimed identity. Instead of thinking of the OpenID2 values as text, think of them as binary data that a machine needs to read. If an internationalized Chinese URL is converted to UTF-8 bytes and then URI-encoded, it is then reduced to lowest- common-denominator text: US-ASCII. It's an easy matter for the RP to extract that and convert it back to a Unicode string, and process it properly. Consider an identity URL like http://www.färber.de/claus In UTF-8, ä is represented by bytes 0xC3 and 0xA4, so a RFC3986 encoded UTF-8 representation of http://www.färber.de/claus would be http://www.f%C3%A4rber.de/claus If the OpenID 2.0 spec made it clear that the value of these HTML discovery attributes was to be decoded by 1st: applying RFC3986 decoding to convert %NN values to bytes 2nd: interpreting as UTF-8 then the string http://www.f%C3%A4rber.de/claus; is not ambiguous at all. This is a compromise -- making decoding simpler for RPs and allowing simple straight URLs for common ASCII-only URLs like https://www.faerber.de/claus;. It also seems to be in accord with the W3C's stance on Internationalized Resource Identifiers: http://www.w3.org/International/O-URL-and-ident.html URIs Internationalization of URIs is important because URIs may contain all kinds of information from all kinds of protocols or formats that use characters beyond ASCII. The URI syntax defined in RFC 2396 currently only allows as subset of ASCII, about 60 characters. It also defines a way to encode arbitrary bytes into URI characters: a % followed by two hexadecimal digits (%HH-escaping). However, for historical reasons, it does not define how arbitrary characters are encoded into bytes before using %HH-escaping. Among various solutions discussed a few years ago, the use of UTF-8 as the preferred character encoding for URIs was judged best. This is in line with the IRI-to-URI conversion, which uses encoding as UTF-8 and then escaping with %hh: As for Claus' HTML editing software dilemma, I retract my comment about the SGML entities enumerated in 7.3.3 of draft 11. My concrete suggestion: replace the current language Other characters that would not be valid in the HTML document or that cannot be represented in the document's character encoding MUST be escaped using the percent-encoding (%xx) mechanism described in [RFC3986]. with this: Any character in the href attributes MAY be represented as UTF-8 data escaped using the percent-encoding (%xx) mechanism described in [RFC3986
HTML discovery: SGML entities and charsets
7.3.3 in draft 11 says The openid2.provider and openid2.local_id URLs MUST NOT include entities other than amp;, lt;, gt;, and quot;. Other characters that would not be valid in the HTML document or that cannot be represented in the document's character encoding MUST be escaped using the percent-encoding (%xx) mechanism described in [RFC3986] (Berners-Lee, T., .Uniform Resource Identifiers (URI): Generic Syntax,. .). Questions: 1) Why are the characters , , , and allowed to be represented with those SGML entities? Why not require them to be encoded per RFC 3986 as %26, %3C, %3E, and %22? 2) Also, should 7.3.3 specify that, as with the key/value data pairs, these values be encoded in UTF-8? Requiring UTF-8 would free RP code from having to understand different HTML character sets, and would allow users to encode their HTML delivery pages in the charset of their choosing. As it stands, it appears that the HTML document containing the LINK tags could be encoded in any charset, with the RP responsible for decoding. With the existence of internationallized domain names, it's quite possible that the provider and local_id values will contain non-ASCII characters. Specifying UTF-8 encoding for HTML discovery will allow leaner, more reliable RP code. -Peter ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
directed identity + HTML discovery: is this right?
So I'd like my employer (for discussion purposes, The Great Plumbers Association, http://plumbers.co) to act as an OpenID OP. I want all our plumber members to use the same OP URL for OpenID authentication, let's say https://id.plumbers.co/ So the RP doesn't try XRI Resolution, and Yadis fails because we only support HTML Discovery. When the RP requests https://id.plumbers.co/ for HTML Discovery, per 7.3.3, we deliver a document with link rel=openid2.provider href=https://id.plumbers.co/; / link rel=openid2.local_id href=http://specs.openid.net/auth/2.0/identifier_select; / For normal authentication, the RP then has to send https://id.plumbers.co/; as the claimed_id and http://specs.openid.net/auth/2.0/identifier_select; as the identity param, per 9.1. This allows our OP (per 10) to choose a unique OP-Local Identifier for the user. Is that right? We could return an identifier of http://pin1234567890.id.plumbers.co; or https://id.plumbers.co/4c1ab4630af439e0c9be33be9615d165;, or whatever. Would we put the OP-Local Identifier in both openid.claimed_id *and* openid.identity? I'm confused about section 10.1's discussion of openid.claimed_id: Note: The end user MAY choose to use an OP-Local Identifier as a Claimed Identifier. This reads like a slight restatement of the earlier language suggesting users' choosing their own OP-Local Identifier (section 10, If the relying party requested OP-driven identifier selection... the OP SHOULD allow the end user to choose which Identifier to use.), but it's subtly different and suggests two things to me: 1) a user interface requirement on the OP side (the user cannot choose an identifier after the RP authentication request and before the OP's authentication response unless the OP has some sort of user interface to allow the user to make such a choice, so this looks like it might be equivalent to something like the OP MUST allow the end user to choose an OP-Local Identifier for use in the response 2) that the OP might return a Claimed ID of the user's choosing even if the RP did not send the identifier_select identity request param Should this read The OP MAY allow the end user to choose an OP-Local Identifier as a Claimed Identifier if there are multiple Identifiers for which the end user is authorized to issue authentication responses and the relying party requested OP-driven identifier selection by setting openid.identity to http://specs.openid.net/auth/2.0/identifier_select; Also, this MAY language suggests that openid.claimed_id in the response can itself be an OP-Local Identifier and differ from the openid.claimed_id value that the RP passed in the authentication request. Is that correct? In an OpenID 2.0 transaction, if openid.claimed_id and openid.identity in the response differ, which value is the RP to use as the user's URL? Could the draft be updated to clarify the uses of these two response items? Thanks, Peter ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
On Wed, Nov 08, 2006 at 11:16:41PM -0500, David Fuelling wrote: Couldn't one make the opposite argument -- that most people's email address NOT working when they plug it into the OpenId login field could actually be a good thing? (especially in the beginning of OpenID) Scenario #2 (WITH email allowed in the OpenId login form): User encounters an openid enabled site, and decides they are curious about the new way to login. If their email domain supports OpenId, then there's really no reason for a novice user NOT to use OpenId -- it works with the email address. On the other hand, if the RP determines that the specified email address doesn't support OpenId, it (the RP) then comes back to the User with an educational page explaining why the email doesn't work, perhaps with a call your email provider and encourage them to adopt openid...and here's why. This makes a lot of sense to me. What's appealing to me about OpenID is that it's a very easy (user- and admin- friendly) system for ad-hoc federation/assertions. Relying Parties don't need any special out-of-band pre-authentication setup with IdPs. Nor is there a need for new PKI infrastructures -- the PKI behind https suffices. For users, no special client software is needed. Why try to teach users this homesite/unique OpenID identifier URL concept when OpenID could use an identifier the user already understands has, like an email address, for locating the user's IdP? -Peter -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 5:06 PM To: David Fuelling Cc: specs@openid.net Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers A Homesite is a new concept for users, so when they see a prompt for it, they will know they have one or not. They are not just typing in a random URL. Pretty much every user has an email address, so a prompt asking for an email would suggest to user that their email will work -- which of course hardly any will. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
