More on OpenID 2.0 vs. simpicity
OpenID 2.0 is coming. It has more stuff. More features etc. DHH worries that it will detract from the simplicity. (DHH would be David Heinemeier Hansson, Mr. Ruby on Rails) As quoted by: http://www.justinball.com/2007/05/18/openid-and-david-heinemeier- hansson/ Johannes Ernst NetMesh Inc. <><> http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: directed identity + HTML discovery: is this right?
On 18-May-07, at 2:19 PM, Peter Watkins wrote: > [...] > Would we put the OP-Local Identifier in both openid.claimed_id *and* > openid.identity? The user/OP can choose to send the local_id as the claimed identifier, or any other claimed identifier that delegates to the local_id sent as openid.identity in the response. > 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" It doesn't have to be a MUST. If the user has only one such identifier at the OP, there is no choice to be made. > 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"" The user/OP can choose a OP-local identifier as a claimed identifier (different than the one in the request) even if there is only one available. Also, "for which the user is authorized to issue authentication responses" is part of the definition of an OP-local identifier, so I wouldn't put that in. > 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? Yes. This is reinforced in 10.1, openid.identity : Note: Relying Parties SHOULD accept and verify assertions about Identifiers for which they have not requested authentication. OpenID Providers MAY assist the end user in selecting the Claimed and OP-Local Identifiers about which the assertion is made. > 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? The claimed identifier (after verification, of course). > Could the draft be updated to clarify the uses of these two > response items? I believe this is covered in 11.2 Verifying Discovered Information. Johnny ___ 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 https://id.plumbers.co/"; /> 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
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 "&", "<", ">", and """. 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
Err TOC 13 that is
On 5/18/07, Boris Erdmann <[EMAIL PROTECTED]> wrote: > > If these four issues are resolved, can we call the OpenID 2.0 > > Authentication specification done? Speak up if you have any other > > show-stoppers. > > I'd like to know WHERE to publish the below mentioned XRDS Document in 2_0-11 TOC 13. > > 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? > > -- Boris > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Please clarify 2.0 TOC 14 -- Re: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification
> If these four issues are resolved, can we call the OpenID 2.0 > Authentication specification done? Speak up if you have any other > show-stoppers. I'd like to know WHERE to publish the below mentioned XRDS Document in 2_0-11 TOC 14. 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? -- Boris ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification
Don, On 5/18/07, Don MacAskill <[EMAIL PROTECTED]> wrote: > My company, SmugMug, is an OpenID provider for hundreds of thousands of > "high value" paying accounts, and will shortly be a consumer as well. > I'll freely admit that I haven't fully digested 2.0's pre-spec, but at > least part of that reason is it looks like it adds a lot more > complexity. I can honestly say that if I had seen it as a spec, rather > than 1.1, I would have certainly put off implementation, possibly > indefinitely. As I have said a few times, the OpenID 2.0 specification is significantly longer than the OpenID 1.1 specification, but most of the length comes from being explicit and rigorous about things that the OpenID 1.1 specification is not. I welcome specific suggestions for simplifying or otherwise improving the specification. The more feedback that we get, the better. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 5/18/07, Dmitry Shechtman <[EMAIL PROTECTED]> wrote: > > I'm sure that this will break a few implementations > > It certainly will break PHP-OpenID. Which implementation are you referring to as "PHP-OpenID"? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Final outstanding issues with the OpenID 2.0 Authenticationspecification
> I'm sure that this will break a few implementations It certainly will break PHP-OpenID. Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0Authenticationspecification
David, On 18-May-07, at 11:09 AM, Recordon, David wrote: > Hey Marius, > Good point, committed a patch so please review! :) On 18-May-07, at 11:08 AM, [EMAIL PROTECTED] wrote: > + > + As discussed in the +target="compat_mode">OpenID Authentication 1.1 > +Compatibility mode section, these discovery tags > +are not the same as in previous versions of the protocol. > +While the same data is conveyed, the names have > changed which > +allows a Relying Party to determine the protocol version > +being used. A Relying Party MAY encounter a Claimed > Identifier > +which uses HTML-Based Discovery to advertise both > version 1.1 > +and 2.0 Providers. > + I believe we should make the above a bit more 'normative' for what the discovery elements should contain, rather than just warning RPs about what they MAY encounter. The qualifier for backwards compatibility is SHOULD / RECOMMENDED through the rest of the spec, so I propose we replace your text with: > For backwards compatibility, if supported by the OP, the HEAD > section of the document SHOULD also include OpenID 1.x discovery > elements: > > A tag with attributes "rel" set to "openid.server" and > "href" set to an OP Endpoint URL > A tag with attributes "rel" set to "openid.delegate" and > "href" set to the end user's OP-Local Identifier > > The protocol version when HTML discovery [...] an OpenID 1.x > endpoint is "http://openid.net/signon/1.1";. Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 18-May-07, at 11:45 AM, Josh Hoyt wrote: > On 5/18/07, Marius Scurtescu <[EMAIL PROTECTED]> wrote: >> On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote: >> In order to be backwards compatible the HTML page should have two >> sets of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing >> to the same OP endpoint URL. Otherwise an OpenID 1.1 RP will not be >> able to use the HTML page. > > Also note that it's allowed to put both values in the "rel" attribute > of one tag [1], which eliminates a little bit of bloat. Good point. I'm sure that this will break a few implementations, checking openid4java right now... Thanks, Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 5/18/07, Marius Scurtescu <[EMAIL PROTECTED]> wrote: > On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote: > In order to be backwards compatible the HTML page should have two > sets of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing > to the same OP endpoint URL. Otherwise an OpenID 1.1 RP will not be > able to use the HTML page. Also note that it's allowed to put both values in the "rel" attribute of one tag [1], which eliminates a little bit of bloat. Josh 1. http://www.w3.org/TR/html401/struct/links.html#adef-rel ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Final outstanding issues with the OpenID 2.0Authenticationspecification
On 18-May-07, at 11:09 AM, Recordon, David wrote: > Hey Marius, > Good point, committed a patch so please review! :) > http://openid.net/svn/diff.php?repname=specifications&path=% > 2Fauthentica > tion%2F2.0%2Ftrunk%2Fopenid-authentication.xml&rev=325&sc=1 That was fast :-) Looks good, but I would add to that a sentence stating that you SHOULD put both sets of tags when editing HTML pages in order to be backwards compatible. Thanks, Marius > > Thanks, > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Marius Scurtescu > Sent: Friday, May 18, 2007 10:48 AM > To: Dmitry Shechtman > Cc: 'OpenID specs list' > Subject: Re: Final outstanding issues with the OpenID > 2.0Authenticationspecification > > On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote: > >> 7.3.3. HTML-Based Discovery >> >> A tag MUST be included with attributes "rel" set to >> openid2.provider" >> and "href" set to an OP Endpoint URL >> >> A tag MAY be included with attributes "rel" set to >> "openid2.local_id" >> and "href" set to the end user's OP-Local Identifier >> >> >> Could somebody please enlighten me as to what's wrong with leaving >> those as "openid.server" and "openid.delegate" respectfully (i.e. >> backward-compatible)? > > The new attribute values are needed in order to signal an OpenID 2 > provider. > > But you bring up a good point, backwards compatibility can be easily > broken here. > > In order to be backwards compatible the HTML page should have two sets > of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing to > the > same OP endpoint URL. Otherwise an OpenID 1.1 RP will not be able > to use > the HTML page. > > Probably the spec should say this in section 7.3.3 and give clear > instructions regarding OpenID 1.1 tags. > > Marius > > ___ > 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: RFC: Final outstanding issues with the OpenID 2.0Authenticationspecification
David, See, here's the problem. When I'm saying "productive conversations", I usually mean they yield something. Getting no replies or replies such as "it should be done the way that it's intended" is counterproductive. Everybody who finds my questions/suggestions stupid, please speak up. Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Final outstanding issues with the OpenID 2.0Authenticationspecification
Hey Marius, Good point, committed a patch so please review! :) http://openid.net/svn/diff.php?repname=specifications&path=%2Fauthentica tion%2F2.0%2Ftrunk%2Fopenid-authentication.xml&rev=325&sc=1 Thanks, --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marius Scurtescu Sent: Friday, May 18, 2007 10:48 AM To: Dmitry Shechtman Cc: 'OpenID specs list' Subject: Re: Final outstanding issues with the OpenID 2.0Authenticationspecification On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote: > 7.3.3. HTML-Based Discovery > > A tag MUST be included with attributes "rel" set to > openid2.provider" > and "href" set to an OP Endpoint URL > > A tag MAY be included with attributes "rel" set to > "openid2.local_id" > and "href" set to the end user's OP-Local Identifier > > > Could somebody please enlighten me as to what's wrong with leaving > those as "openid.server" and "openid.delegate" respectfully (i.e. > backward-compatible)? The new attribute values are needed in order to signal an OpenID 2 provider. But you bring up a good point, backwards compatibility can be easily broken here. In order to be backwards compatible the HTML page should have two sets of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing to the same OP endpoint URL. Otherwise an OpenID 1.1 RP will not be able to use the HTML page. Probably the spec should say this in section 7.3.3 and give clear instructions regarding OpenID 1.1 tags. Marius ___ 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: Proposal for improved security of association establishment in OpenID 2.0
Guoping, I'm not an expert, but I do understand the attack that you're describing. I'm hesitant to make the change without input from Paul Crowley, who designed the key exchange mechanism in the first place. I hope that he will comment. It should be noted that a man-in-the-middle can still be a problem if they intercept (proxy) every message, and not just the association-related messages. This raises the bar for being a man-in-the-middle, but it does not eliminate the problem. Josh On 5/17/07, Guoping Liu <[EMAIL PROTECTED]> wrote: > Issue: Vulnerability to man-in-the-middle attacks > > The association algorithm with DH-SHA1 and DH-SHA256 defined in the > draft 11 is vulnerable to man-in-the-middle attacks if server > authentication with HTTPS is not used. Here is how: > > A RP sends an associate request an OP with following parameters: > > openid.dh_modulus = base64(btwoc(p)) > openid.dh_gen = base64(btwoc(g)) > openid.dh_consumer_public = base64(btwoc(g ^ xa mod p)) > > A middle man M intercepts the request. M then generates xc, creates a > new request to the OP with following parameters: > > openid.dh_modulus = base64(btwoc(p)) > openid.dh_gen = base64(btwoc(g)) > openid.dh_consumer_public = base64(btwoc(g ^ xc mod p)) > > The OP receives the request from M and sends following response to M > > dh_server_public = base64(btwoc(g ^ xb mod p)) > enc_mac_key = base64(H(btwoc(g ^ (xc * xb) mod p)) XOR MAC_key) > > M decrypts the MAC_key as follows: > > MAC_key = H(btwoc(g ^ (xc * xb) mod p)) XOR enc_mac_key > > M then sends a response to the RP with following parameters: > > dh_server_public = base64(btwoc(g ^ xc mod p)) > enc_mac_key = base64(H(btwoc(g ^ (xc * xa) mod p)) XOR MAC_key) > > Now, the RP, middle man M and OP all have the same MAC_key. > > > Proposed Solution: > > Do not send enc_mac_key in response. Both OP and RP generate a MAC key > as follows > > H(btwoc(g ^ (xa * xb) mod p)) > > We are NOT sending the MAC key over and are not vulnerable to man in the > middle attacks. > > Guoping Liu > ___ > 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: RFC: Final outstanding issues with the OpenID 2.0Authenticationspecification
Hi Dmitry, I don't think the solution is to "simple denounce OpenID 2.0", but that will rather only make it worse. Rather I'd invite you to continue these productive conversations to see if the issues can be resolved. I think it would be unfortunate for anyone to just give up. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry Shechtman Sent: Friday, May 18, 2007 8:09 AM To: 'Don MacAskill'; 'OpenID specs list' Subject: RE: RFC: Final outstanding issues with the OpenID 2.0Authenticationspecification > As a relative newcomer to the OpenID community, I realize this may > have been debated endlessly already, and I may just be shouted down. It definitely has been debated endlessly. > Or am I alone here? No, you aren't. There are many who agree with this entirely, some of whom have expressed their opinion on the various OpenID lists, but at no avail. My suggestion at this point would be to simply denounce OpenID 2.0. Regards, Dmitry =damnian ___ 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: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification
Hey Don, Certainly not alone, though I think what we really need to dig into is if the spec is actually more complex from a feature perspective or because it is much more verbose and adds clarity over 1.1. Splitting discovery into a separate spec I think will also help in the document being less intimidating. This is certainly an important issue though, OpenID has largely been successful because of how simple OpenID 1.1 + Yadis + SREG is compared to the value provided. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don MacAskill Sent: Friday, May 18, 2007 7:49 AM To: OpenID specs list Subject: Re: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification Josh Hoyt wrote: > If these four issues are resolved, can we call the OpenID 2.0 > Authentication specification done? Speak up if you have any other > show-stoppers. > > Josh > I hate to speak up last minute, but I was at a few tech conferences in the past month or two, and spoke with lots of passionate OpenID proponents. There was a common thread among our discussions: "OpenID 2.0 seems to be getting massively more complex without a clear reason to do so. One of the best things about OpenID 1.1 is how easy and simple it is to write for." My company, SmugMug, is an OpenID provider for hundreds of thousands of "high value" paying accounts, and will shortly be a consumer as well. I'll freely admit that I haven't fully digested 2.0's pre-spec, but at least part of that reason is it looks like it adds a lot more complexity. I can honestly say that if I had seen it as a spec, rather than 1.1, I would have certainly put off implementation, possibly indefinitely. As a relative newcomer to the OpenID community, I realize this may have been debated endlessly already, and I may just be shouted down. I'm a n00b, I get that. But are we really sure that a much more complex spec is in the best interests of the community? Or am I alone here? Thanks, Don ___ 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: Final outstanding issues with the OpenID 2.0Authenticationspecification
Hey Dmitry, When using Yadis you're able to advertise if you're speaking OpenID 1.1 or 2.0 and thus the RP know which version of the protocol the request should be made in. When using HTML-Based Discovery this is not possible unless the attributes are renamed or a third "version" tag is added which was not the preferred option. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry Shechtman Sent: Friday, May 18, 2007 1:00 AM To: 'Josh Hoyt'; 'OpenID specs list' Subject: RE: Final outstanding issues with the OpenID 2.0Authenticationspecification 7.3.3. HTML-Based Discovery A tag MUST be included with attributes "rel" set to openid2.provider" and "href" set to an OP Endpoint URL A tag MAY be included with attributes "rel" set to "openid2.local_id" and "href" set to the end user's OP-Local Identifier Could somebody please enlighten me as to what's wrong with leaving those as "openid.server" and "openid.delegate" respectfully (i.e. backward-compatible)? Regards, Dmitry =damnian ___ 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: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification
# I think in the past the idea was giving the HTML "form" element a # specific name in addition to the text field. This thus makes it # much easier to detect. And I believe it was also suggested that this is out of scope for the protocol spec itself and should be added to either another spec or a best practices document. -- Jonathan Daugherty JanRain, Inc. irc.freenode.net: cygnus in #openid cygnus.myopenid.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification
I think in the past the idea was giving the HTML "form" element a specific name in addition to the text field. This thus makes it much easier to detect. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry Shechtman Sent: Friday, May 18, 2007 12:47 AM To: 'Boris Erdmann'; 'Josh Hoyt' Cc: 'OpenID specs list' Subject: RE: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification > As of today browsers are forced to make untenable assumptions to > detect OPs or RPs. Read > http://openid.net/specs/openid-authentication-2_0-11.html#initiation: > "The form field's "name" attribute SHOULD have the value > "openid_identifier" is the only point for a browser to grip the > protocol. (And the field name is different from OpenID1.x) Indeed. Here's a suggestion that floated during that talk. The form field: a. SHOULD have "openid_identifier" as its "name" attribute's value, b. MUST have "openid" as a substring its "name" attribute's value and c. SHOULD be the only field in the entire document to satisfy (b). Regards, Dmitry =damnian ___ 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: Final outstanding issues with the OpenID 2.0Authenticationspecification
Please no talk of OpenID 3! If anything, 2.1 or the "next version". :) Thanks, --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, May 17, 2007 2:05 PM To: Alaric Dailey Cc: OpenID specs list Subject: Re: Final outstanding issues with the OpenID 2.0Authenticationspecification On 5/17/07, Alaric Dailey <[EMAIL PROTECTED]> wrote: > I hate to be a PITA but these issues were brought up a while ago by > Eddy Nigg and Myself. I understand, but at that time, as now, I was trying to get the spec to be finished. We've been in something of an informal feature-freeze for a while. Perhaps we should have explicit feature-freezes. I'd suggest starting an OpenID 3 thread to talk about the features that you want to add. That way, you can start trying to convince people that your features should go in without having to battle with people like me who just want to have a stable spec release with the improvements that we already have. Josh ___ 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: RFC: Final outstanding issues with the OpenID 2.0Authenticationspecification
I'm in support of doing this. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, May 17, 2007 1:40 PM To: Dmitry Shechtman Cc: OpenID specs list Subject: Re: RFC: Final outstanding issues with the OpenID 2.0Authenticationspecification On 5/17/07, Dmitry Shechtman <[EMAIL PROTECTED]> wrote: > "aside from XRI and Yadis"? XRI alone is twice as complex as OpenID 1.1! > > There has been a simplification suggestion floating around since long ago: > resolve i-names via http[s]://xri.net/. -1. If XRI is to be included, it should be done the way that it's intended. One possible solution that would address this problem as well as the unfinished XRI specification is to split out Yadis and XRI discovery out from the OpenID Authentication spec and into separate documents. That way, they could wait until the XRI specs are done and the OpenID spec will be shorter and easier to understand. Josh ___ 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: Final outstanding issues with the OpenID 2.0 Authenticationspecification
On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote: > 7.3.3. HTML-Based Discovery > > A tag MUST be included with attributes "rel" set to > openid2.provider" > and "href" set to an OP Endpoint URL > > A tag MAY be included with attributes "rel" set to > "openid2.local_id" > and "href" set to the end user's OP-Local Identifier > > > Could somebody please enlighten me as to what's wrong with leaving > those as > "openid.server" and "openid.delegate" respectfully (i.e. > backward-compatible)? The new attribute values are needed in order to signal an OpenID 2 provider. But you bring up a good point, backwards compatibility can be easily broken here. In order to be backwards compatible the HTML page should have two sets of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing to the same OP endpoint URL. Otherwise an OpenID 1.1 RP will not be able to use the HTML page. Probably the spec should say this in section 7.3.3 and give clear instructions regarding OpenID 1.1 tags. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification
> Is it critical? No. Could we drop the constraint as you list it? Yes, > I think. Now that I'm rethinking it, "the entire document" in (c) and (d) should be replaced with "the form"... Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal for improved security of association establishment in OpenID2.0
Hans: Thank you for your comments. I agree with you that "not vulnerable to *this* man in the middle attack" is more accurate. Regards, Guoping -Original Message- From: Granqvist, Hans [mailto:[EMAIL PROTECTED] Sent: Friday, May 18, 2007 10:14 AM To: Guoping Liu; OpenID specs list Subject: RE: Proposal for improved security of association establishment in OpenID2.0 Guoping Liu: Nice write-up! A comment though: This is a common MITM problem with DH key exchange. It seems if the MAC key was derived somehow from the negotiated secret, then this attack would not be possible. I never really grokked the XOR 'encryption' step, apart from its ease of implementation and what seemed reasonable protection, both of great value. Perhaps some early spec writers (Brad?) can shed some light? Was there ever a discussion pre 1.x on using a MAC key derived from (or maybe even being!) the negotiated secret, and if so, what's the weakness? Am I missing something obvious? Thanks, Hans PS. > We are NOT sending the MAC key over and are not vulnerable to > man in the middle attacks. Gutsy statement! Maybe "not vulnerable to *this* man in the middle attack" would be safer? ;) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Guoping Liu > Sent: Thursday, May 17, 2007 11:53 AM > To: OpenID specs list > Subject: Proposal for improved security of association > establishment in OpenID2.0 > > Issue: Vulnerability to man-in-the-middle attacks > > The association algorithm with DH-SHA1 and DH-SHA256 defined > in the draft 11 is vulnerable to man-in-the-middle attacks if > server authentication with HTTPS is not used. Here is how: > > A RP sends an associate request an OP with following parameters: > > openid.dh_modulus = base64(btwoc(p)) > openid.dh_gen = base64(btwoc(g)) > openid.dh_consumer_public = base64(btwoc(g ^ xa mod p)) > > A middle man M intercepts the request. M then generates xc, > creates a new request to the OP with following parameters: > > openid.dh_modulus = base64(btwoc(p)) > openid.dh_gen = base64(btwoc(g)) > openid.dh_consumer_public = base64(btwoc(g ^ xc mod p)) > > The OP receives the request from M and sends following response to M > > dh_server_public = base64(btwoc(g ^ xb mod p)) > enc_mac_key = base64(H(btwoc(g ^ (xc * xb) mod p)) > XOR MAC_key) > > M decrypts the MAC_key as follows: > > MAC_key = H(btwoc(g ^ (xc * xb) mod p)) XOR enc_mac_key > > M then sends a response to the RP with following parameters: > > dh_server_public = base64(btwoc(g ^ xc mod p)) > enc_mac_key = base64(H(btwoc(g ^ (xc * xa) mod p)) > XOR MAC_key) > > Now, the RP, middle man M and OP all have the same MAC_key. > > > Proposed Solution: > > Do not send enc_mac_key in response. Both OP and RP generate > a MAC key as follows > > H(btwoc(g ^ (xa * xb) mod p)) > > We are NOT sending the MAC key over and are not vulnerable to > man in the middle attacks. > > Guoping Liu > ___ > 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: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification
On May 18, 2007, at 0:54, Dmitry Shechtman wrote: d. MUST be the only form field in the entire document to satisfy (b). This doesn't work where a page offers a login form in more than one place -- not too unlikely in some ajaxy scenarios in my view. Is it critical? No. Could we drop the constraint as you list it? Yes, I think. Johannes Ernst NetMesh Inc. <><> http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal for improved security of association establishment in OpenID2.0
Guoping Liu: Nice write-up! A comment though: This is a common MITM problem with DH key exchange. It seems if the MAC key was derived somehow from the negotiated secret, then this attack would not be possible. I never really grokked the XOR 'encryption' step, apart from its ease of implementation and what seemed reasonable protection, both of great value. Perhaps some early spec writers (Brad?) can shed some light? Was there ever a discussion pre 1.x on using a MAC key derived from (or maybe even being!) the negotiated secret, and if so, what's the weakness? Am I missing something obvious? Thanks, Hans PS. > We are NOT sending the MAC key over and are not vulnerable to > man in the middle attacks. Gutsy statement! Maybe "not vulnerable to *this* man in the middle attack" would be safer? ;) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Guoping Liu > Sent: Thursday, May 17, 2007 11:53 AM > To: OpenID specs list > Subject: Proposal for improved security of association > establishment in OpenID2.0 > > Issue: Vulnerability to man-in-the-middle attacks > > The association algorithm with DH-SHA1 and DH-SHA256 defined > in the draft 11 is vulnerable to man-in-the-middle attacks if > server authentication with HTTPS is not used. Here is how: > > A RP sends an associate request an OP with following parameters: > > openid.dh_modulus = base64(btwoc(p)) > openid.dh_gen = base64(btwoc(g)) > openid.dh_consumer_public = base64(btwoc(g ^ xa mod p)) > > A middle man M intercepts the request. M then generates xc, > creates a new request to the OP with following parameters: > > openid.dh_modulus = base64(btwoc(p)) > openid.dh_gen = base64(btwoc(g)) > openid.dh_consumer_public = base64(btwoc(g ^ xc mod p)) > > The OP receives the request from M and sends following response to M > > dh_server_public = base64(btwoc(g ^ xb mod p)) > enc_mac_key = base64(H(btwoc(g ^ (xc * xb) mod p)) > XOR MAC_key) > > M decrypts the MAC_key as follows: > > MAC_key = H(btwoc(g ^ (xc * xb) mod p)) XOR enc_mac_key > > M then sends a response to the RP with following parameters: > > dh_server_public = base64(btwoc(g ^ xc mod p)) > enc_mac_key = base64(H(btwoc(g ^ (xc * xa) mod p)) > XOR MAC_key) > > Now, the RP, middle man M and OP all have the same MAC_key. > > > Proposed Solution: > > Do not send enc_mac_key in response. Both OP and RP generate > a MAC key as follows > > H(btwoc(g ^ (xa * xb) mod p)) > > We are NOT sending the MAC key over and are not vulnerable to > man in the middle attacks. > > Guoping Liu > ___ > 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: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification
> As a relative newcomer to the OpenID community, I realize this may have > been debated endlessly already, and I may just be shouted down. It definitely has been debated endlessly. > Or am I alone here? No, you aren't. There are many who agree with this entirely, some of whom have expressed their opinion on the various OpenID lists, but at no avail. My suggestion at this point would be to simply denounce OpenID 2.0. Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification
Josh Hoyt wrote: > If these four issues are resolved, can we call the OpenID 2.0 > Authentication specification done? Speak up if you have any other > show-stoppers. > > Josh > I hate to speak up last minute, but I was at a few tech conferences in the past month or two, and spoke with lots of passionate OpenID proponents. There was a common thread among our discussions: "OpenID 2.0 seems to be getting massively more complex without a clear reason to do so. One of the best things about OpenID 1.1 is how easy and simple it is to write for." My company, SmugMug, is an OpenID provider for hundreds of thousands of "high value" paying accounts, and will shortly be a consumer as well. I'll freely admit that I haven't fully digested 2.0's pre-spec, but at least part of that reason is it looks like it adds a lot more complexity. I can honestly say that if I had seen it as a spec, rather than 1.1, I would have certainly put off implementation, possibly indefinitely. As a relative newcomer to the OpenID community, I realize this may have been debated endlessly already, and I may just be shouted down. I'm a n00b, I get that. But are we really sure that a much more complex spec is in the best interests of the community? Or am I alone here? Thanks, Don ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Final outstanding issues with the OpenID 2.0 Authenticationspecification
7.3.3. HTML-Based Discovery A tag MUST be included with attributes "rel" set to openid2.provider" and "href" set to an OP Endpoint URL A tag MAY be included with attributes "rel" set to "openid2.local_id" and "href" set to the end user's OP-Local Identifier Could somebody please enlighten me as to what's wrong with leaving those as "openid.server" and "openid.delegate" respectfully (i.e. backward-compatible)? Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification
Oh my, I'm still asleep... Here's a better formulation. The form field: a. MUST have "openid" as a substring of its "name" attribute's value, b. SHOULD have "openid_identifier" as its "name" attribute's value, c. SHOULD be the only form field in the entire document to satisfy (a) and d. MUST be the only form field in the entire document to satisfy (b). Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification
> As of today browsers are forced to make untenable assumptions to > detect OPs or RPs. Read > http://openid.net/specs/openid-authentication-2_0-11.html#initiation: > "The form field's "name" attribute SHOULD have the value > "openid_identifier" is the only point for a browser to grip the > protocol. (And the field name is different from OpenID1.x) Indeed. Here's a suggestion that floated during that talk. The form field: a. SHOULD have "openid_identifier" as its "name" attribute's value, b. MUST have "openid" as a substring its "name" attribute's value and c. SHOULD be the only field in the entire document to satisfy (b). Regards, Dmitry =damnian ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification
> If these four issues are resolved, can we call the OpenID 2.0 > Authentication specification done? Speak up if you have any other > show-stoppers. > > Josh Yesterday, Dmitry and I had a long talk about browser support for OpenID. I think it is consensus between us two to state, that there are lots of snares for browsers, if there will be no ways for browsers to detect OPs or even RPs. As of today browsers are forced to make untenable assumptions to detect OPs or RPs. Read http://openid.net/specs/openid-authentication-2_0-11.html#initiation: "The form field's "name" attribute SHOULD have the value "openid_identifier" is the only point for a browser to grip the protocol. (And the field name is different from OpenID1.x) We also discussed the fact that the spec does not provide any hints WHEN in the flow of the protocol the RP-OP transition takes place. It is valid that between entering an openid at an RP site and redirecting to an OP lots of pages get displayed by the RP (as part of non sreg registration, for exampe). OpenID2.0 allowing for POST redirects adds to this. Therefor hints for robust OP detection would not hurt either. -- Boris ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
