Re[6]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Hi Johannes, Yep - that's right. "Browser++" might also be an identity provision service (eg: web site), or combination of service and browser component. Component will need to be a browser plugin with access to the source of the page, and opportunity to enact changes to it (eg: fill in the username), which will mean it probably supplies JavaScript extensions into the page itself. Your items 2, 3, 4, and 5 may also all be "grouped" into a single automatic response in the case where a user has elected "single sign on". Kind Regards, Chris Drake Sunday, October 22, 2006, 9:03:30 AM, you wrote: JE> Chris, thanks for the answer, but I'm afraid I'm just as confused as JE> before. I think I don't understand your scenario. So: JE> 1) User navigates to a relying party JE> 2) Browser++ (i.e. browser with some kind of extension) detects the JE> fact that this a relying party (and the means by which that occurs is JE> the subject of this discussion) JE> 3) Browser++ shows some kind of user interface that's implemented by JE> the browser++ instead of the relying party for identity selection etc. JE> 4) User fills out whatever needs filling out / approving etc. in the JE> browser++ user interface JE> 5) Browser++ submits (e..g HTTP POST) to relying party at the right URL JE> Did I get this right? I must be missing something, though, given the JE> constraints you are listing? JE> On Oct 21, 2006, at 8:17, Chris Drake wrote: >> Hi Johannes, >> >> JavaScript can't talk Yadis, cannot maintain "state" between pages, >> and is highly likely to be blocked from external resources by >> cross-site-scripting security restrictions. Even if it could go out >> and resolve the OpenID info it needs from external resources, it would >> halve the loading speed of every page involved. >> >> We should not ignore the opportunities that Identity 2.0 is presenting >> to OpenID, so we need to ensure that hooks put in place to enable >> Identity systems to use OpenID are added in a useable way. >> >> Kind Regards, >> Chris Drake >> >> >> Friday, October 20, 2006, 3:03:25 PM, you wrote: >> >> JE> Chris, I'm a little slow here, please bear with me. What's the >> JE> reasoning for "without accessing other resources"? >> >> JE> I am with you if you said "we can't ask a user agent to first do a >> JE> MIME type of XRDS". But what's the difference between adding a >> new ad- >> JE> hoc link tag in the HTML to the Yadis tag in the HTML or the HTTP >> JE> header? >> >> >> >> JE> On Oct 19, 2006, at 19:44, Chris Drake wrote: >> >>>> Hi Johannes, >>>> >>>> No - Yadis is inappropriate because user agents need to be able to >>>> identify an OpenID login page (and endpoint if possible) *without* >>>> accessing other resources. >>>> >>>> Kind Regards, >>>> Chris Drake >>>> >>>> >>>> Friday, October 20, 2006, 10:33:40 AM, you wrote: >>>> >>>> JE> Isn't this a case where the Yadis infrastructure should be used >>>> JE> instead of Yet Another Link Tag? >>>> >>>> >>>> JE> On Oct 19, 2006, at 8:21, Drummond Reed wrote: >>>> >>>>>> Martin, I agree with Dick, this is a fascinating idea. P3P had the >>>>>> same idea >>>>>> notion for a site advertising the location of the P3P privacy >>>>>> policy: it >>>>>> defined a standard HTML/XHTML link tag that could be put on any >>>>>> page of a >>>>>> site that told the browser where to locate the P3P policy document >>>>>> for the >>>>>> site (or for any portion of the site). >>>>>> >>>>>> http://www.w3.org/TR/P3P/#ref_syntax >>>>>> >>>>>> Are you proposing the same thing for OpenID login? >>>>>> >>>>>> (Kewl!) >>>>>> >>>>>> =Drummond >>>>>> >>>>>> -Original Message- >>>>>> From: [EMAIL PROTECTED] >>>>>> [mailto:[EMAIL PROTECTED] On >>>>>> Behalf >>>>>> Of Dick Hardt >>>>>> Sent: Thursday, October 19, 2006 12:53 AM >>>>>> To: Martin Atkins >>>>>> Cc: specs@openid.net >>>>>> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >>>
Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
Title: Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4) Feel free to write a patch for that section. :) --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED]] Sent: Saturday, October 21, 2006 06:21 PM Pacific Standard Time To: Recordon, David Cc: Josh Hoyt; specs@openid.net Subject: Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4) Missed that section. It is not clear what the return_to URL is though. The return_to URL may not be the same thing as the action URL from the login form. What we wanted was the action URL since we want to POST openid_identifier= to that URL. This would be a different message then the indirect response message from the IdP which is signed etc. I think this is the right direction, we just need to clarify more what that end point is. -- Dick On 19-Oct-06, at 11:21 AM, Recordon, David wrote: > Which is still described in the latest draft, see > http://openid.net/specs/openid-authentication-2_0-10.html#anchor42. > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On > Behalf Of Josh Hoyt > Sent: Thursday, October 19, 2006 1:24 PM > To: Dick Hardt > Cc: specs@openid.net > Subject: Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4) > > On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> I like your proposal. I would tweak the name: >> >> http://my.rp.com/openid/blah.cgi"> > > This is what Yadis was designed for. Since OpenID already requires > Yadis, this should be implemented as a Service entry in the Yadis > document for any page on which you want that information. > > 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: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
Missed that section. It is not clear what the return_to URL is though. The return_to URL may not be the same thing as the action URL from the login form. What we wanted was the action URL since we want to POST openid_identifier= to that URL. This would be a different message then the indirect response message from the IdP which is signed etc. I think this is the right direction, we just need to clarify more what that end point is. -- Dick On 19-Oct-06, at 11:21 AM, Recordon, David wrote: > Which is still described in the latest draft, see > http://openid.net/specs/openid-authentication-2_0-10.html#anchor42. > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Josh Hoyt > Sent: Thursday, October 19, 2006 1:24 PM > To: Dick Hardt > Cc: specs@openid.net > Subject: Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4) > > On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> I like your proposal. I would tweak the name: >> >> http://my.rp.com/openid/blah.cgi";> > > This is what Yadis was designed for. Since OpenID already requires > Yadis, this should be implemented as a Service entry in the Yadis > document for any page on which you want that information. > > 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: Re[4]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Chris, thanks for the answer, but I'm afraid I'm just as confused as before. I think I don't understand your scenario. So: 1) User navigates to a relying party 2) Browser++ (i.e. browser with some kind of extension) detects the fact that this a relying party (and the means by which that occurs is the subject of this discussion) 3) Browser++ shows some kind of user interface that's implemented by the browser++ instead of the relying party for identity selection etc. 4) User fills out whatever needs filling out / approving etc. in the browser++ user interface 5) Browser++ submits (e..g HTTP POST) to relying party at the right URL Did I get this right? I must be missing something, though, given the constraints you are listing? On Oct 21, 2006, at 8:17, Chris Drake wrote: Hi Johannes, JavaScript can't talk Yadis, cannot maintain "state" between pages, and is highly likely to be blocked from external resources by cross-site-scripting security restrictions. Even if it could go out and resolve the OpenID info it needs from external resources, it would halve the loading speed of every page involved. We should not ignore the opportunities that Identity 2.0 is presenting to OpenID, so we need to ensure that hooks put in place to enable Identity systems to use OpenID are added in a useable way. Kind Regards, Chris Drake Friday, October 20, 2006, 3:03:25 PM, you wrote: JE> Chris, I'm a little slow here, please bear with me. What's the JE> reasoning for "without accessing other resources"? JE> I am with you if you said "we can't ask a user agent to first do a JE> MIME type of XRDS". But what's the difference between adding a new ad- JE> hoc link tag in the HTML to the Yadis tag in the HTML or the HTTP JE> header? JE> On Oct 19, 2006, at 19:44, Chris Drake wrote: Hi Johannes, No - Yadis is inappropriate because user agents need to be able to identify an OpenID login page (and endpoint if possible) *without* accessing other resources. Kind Regards, Chris Drake Friday, October 20, 2006, 10:33:40 AM, you wrote: JE> Isn't this a case where the Yadis infrastructure should be used JE> instead of Yet Another Link Tag? JE> On Oct 19, 2006, at 8:21, Drummond Reed wrote: Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea notion for a site advertising the location of the P3P privacy policy: it defined a standard HTML/XHTML link tag that could be put on any page of a site that told the browser where to locate the P3P policy document for the site (or for any portion of the site). http://www.w3.org/TR/P3P/#ref_syntax Are you proposing the same thing for OpenID login? (Kewl!) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 12:53 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: Dick Hardt wrote: In order for the RUA to detect that a site supports OpenID, it sees a form with a single input with a "name" of openid_identiifier. The RUA can then look at the action and post the data directly to the RP. I think it'd be better to implement this as either a META or a LINK element alongside a standard protocol for communicating with the nominated URL. This way the site can declare on *all pages*, rather than on the forms-based login page, that it accepts OpenID auth. This allows the user to go to the RP's home page (or any other page) and click the "OpenID Login" button on the browser's toolbar and have it work. That is an interesting idea. Would you like to take a stab at more specifics? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs JE> Johannes Ernst JE> NetMesh Inc. JE> Johannes Ernst JE> NetMesh Inc. Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[4]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Hi Johannes, JavaScript can't talk Yadis, cannot maintain "state" between pages, and is highly likely to be blocked from external resources by cross-site-scripting security restrictions. Even if it could go out and resolve the OpenID info it needs from external resources, it would halve the loading speed of every page involved. We should not ignore the opportunities that Identity 2.0 is presenting to OpenID, so we need to ensure that hooks put in place to enable Identity systems to use OpenID are added in a useable way. Kind Regards, Chris Drake Friday, October 20, 2006, 3:03:25 PM, you wrote: JE> Chris, I'm a little slow here, please bear with me. What's the JE> reasoning for "without accessing other resources"? JE> I am with you if you said "we can't ask a user agent to first do a JE> MIME type of XRDS". But what's the difference between adding a new ad- JE> hoc link tag in the HTML to the Yadis tag in the HTML or the HTTP JE> header? JE> On Oct 19, 2006, at 19:44, Chris Drake wrote: >> Hi Johannes, >> >> No - Yadis is inappropriate because user agents need to be able to >> identify an OpenID login page (and endpoint if possible) *without* >> accessing other resources. >> >> Kind Regards, >> Chris Drake >> >> >> Friday, October 20, 2006, 10:33:40 AM, you wrote: >> >> JE> Isn't this a case where the Yadis infrastructure should be used >> JE> instead of Yet Another Link Tag? >> >> >> JE> On Oct 19, 2006, at 8:21, Drummond Reed wrote: >> >>>> Martin, I agree with Dick, this is a fascinating idea. P3P had the >>>> same idea >>>> notion for a site advertising the location of the P3P privacy >>>> policy: it >>>> defined a standard HTML/XHTML link tag that could be put on any >>>> page of a >>>> site that told the browser where to locate the P3P policy document >>>> for the >>>> site (or for any portion of the site). >>>> >>>>http://www.w3.org/TR/P3P/#ref_syntax >>>> >>>> Are you proposing the same thing for OpenID login? >>>> >>>> (Kewl!) >>>> >>>> =Drummond >>>> >>>> -Original Message- >>>> From: [EMAIL PROTECTED] >>>> [mailto:[EMAIL PROTECTED] On >>>> Behalf >>>> Of Dick Hardt >>>> Sent: Thursday, October 19, 2006 12:53 AM >>>> To: Martin Atkins >>>> Cc: specs@openid.net >>>> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >>>> >>>> >>>> On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: >>>> >>>>> Dick Hardt wrote: >>>>>> >>>>>> In order for the RUA to detect that a site supports OpenID, it >>>>>> sees a >>>>>> form with a single input with a "name" of openid_identiifier. The >>>>>> RUA >>>>>> can then look at the action and post the data directly to the RP. >>>>>> >>>>> >>>>> I think it'd be better to implement this as either a META or a LINK >>>>> element alongside a standard protocol for communicating with the >>>>> nominated URL. >>>>> >>>>> This way the site can declare on *all pages*, rather than on the >>>>> forms-based login page, that it accepts OpenID auth. This allows >>>>> the >>>>> user to go to the RP's home page (or any other page) and click the >>>>> "OpenID Login" button on the browser's toolbar and have it work. >>>> >>>> That is an interesting idea. Would you like to take a stab at more >>>> specifics? >>>> >>>> -- Dick >>>> ___ >>>> specs mailing list >>>> specs@openid.net >>>> http://openid.net/mailman/listinfo/specs >>>> >>>> ___ >>>> specs mailing list >>>> specs@openid.net >>>> http://openid.net/mailman/listinfo/specs >> >> JE> Johannes Ernst >> JE> NetMesh Inc. >> >> >> JE> Johannes Ernst JE> NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Chris, I'm a little slow here, please bear with me. What's the reasoning for "without accessing other resources"? I am with you if you said "we can't ask a user agent to first do a MIME type of XRDS". But what's the difference between adding a new ad- hoc link tag in the HTML to the Yadis tag in the HTML or the HTTP header? On Oct 19, 2006, at 19:44, Chris Drake wrote: Hi Johannes, No - Yadis is inappropriate because user agents need to be able to identify an OpenID login page (and endpoint if possible) *without* accessing other resources. Kind Regards, Chris Drake Friday, October 20, 2006, 10:33:40 AM, you wrote: JE> Isn't this a case where the Yadis infrastructure should be used JE> instead of Yet Another Link Tag? JE> On Oct 19, 2006, at 8:21, Drummond Reed wrote: Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea notion for a site advertising the location of the P3P privacy policy: it defined a standard HTML/XHTML link tag that could be put on any page of a site that told the browser where to locate the P3P policy document for the site (or for any portion of the site). http://www.w3.org/TR/P3P/#ref_syntax Are you proposing the same thing for OpenID login? (Kewl!) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 12:53 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: Dick Hardt wrote: In order for the RUA to detect that a site supports OpenID, it sees a form with a single input with a "name" of openid_identiifier. The RUA can then look at the action and post the data directly to the RP. I think it'd be better to implement this as either a META or a LINK element alongside a standard protocol for communicating with the nominated URL. This way the site can declare on *all pages*, rather than on the forms-based login page, that it accepts OpenID auth. This allows the user to go to the RP's home page (or any other page) and click the "OpenID Login" button on the browser's toolbar and have it work. That is an interesting idea. Would you like to take a stab at more specifics? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs JE> Johannes Ernst JE> NetMesh Inc. Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
On Oct 19, 2006, at 14:56, Josh Hoyt wrote: I'm in favor of keeping the OpenID Authentication Protocol specification as small as possible, with as few restrictions as possible to get useful behavior. Fully agree. The genius of HTTP and RSS and mass-market protocols like them was not in what they included, but what they left out. There are some lessons that we can learn here. The more we can reduce the scope, the more likely it is that we can develop a tight, usable specification that does not hold anyone back and is easy to implement. Exactly. There are a couple of different insights that are common to OpenID, SXIP, LID, and the myriad other URL-based single-sign-on solutions that are out there. I want to codify the things that we all agree on and allow innovation around the things that we do not. Hey, Josh, what happened, you are taking the words out of my mouth today!! ;-) I do not feel strongly about this particular issue, but I do feel strongly that if possible, we should REDUCE the scope as much as possible. Yes yes and more Yes. If there is a way to accomplish your goal without changing OpenID, then DON'T CHANGE OPENID. It's easy to put stuff in the next revision, but it's hard to take stuff out. OpenID has been successful because its scope was intentionally extremely narrow. Lets keep it that way. Absolutely. Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Hi Johannes, No - Yadis is inappropriate because user agents need to be able to identify an OpenID login page (and endpoint if possible) *without* accessing other resources. Kind Regards, Chris Drake Friday, October 20, 2006, 10:33:40 AM, you wrote: JE> Isn't this a case where the Yadis infrastructure should be used JE> instead of Yet Another Link Tag? JE> On Oct 19, 2006, at 8:21, Drummond Reed wrote: >> Martin, I agree with Dick, this is a fascinating idea. P3P had the >> same idea >> notion for a site advertising the location of the P3P privacy >> policy: it >> defined a standard HTML/XHTML link tag that could be put on any >> page of a >> site that told the browser where to locate the P3P policy document >> for the >> site (or for any portion of the site). >> >> http://www.w3.org/TR/P3P/#ref_syntax >> >> Are you proposing the same thing for OpenID login? >> >> (Kewl!) >> >> =Drummond >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On >> Behalf >> Of Dick Hardt >> Sent: Thursday, October 19, 2006 12:53 AM >> To: Martin Atkins >> Cc: specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> >> On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: >> >>> Dick Hardt wrote: >>>> >>>> In order for the RUA to detect that a site supports OpenID, it >>>> sees a >>>> form with a single input with a "name" of openid_identiifier. The >>>> RUA >>>> can then look at the action and post the data directly to the RP. >>>> >>> >>> I think it'd be better to implement this as either a META or a LINK >>> element alongside a standard protocol for communicating with the >>> nominated URL. >>> >>> This way the site can declare on *all pages*, rather than on the >>> forms-based login page, that it accepts OpenID auth. This allows the >>> user to go to the RP's home page (or any other page) and click the >>> "OpenID Login" button on the browser's toolbar and have it work. >> >> That is an interesting idea. Would you like to take a stab at more >> specifics? >> >> -- Dick >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs JE> Johannes Ernst JE> NetMesh Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Isn't this a case where the Yadis infrastructure should be used instead of Yet Another Link Tag? On Oct 19, 2006, at 8:21, Drummond Reed wrote: Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea notion for a site advertising the location of the P3P privacy policy: it defined a standard HTML/XHTML link tag that could be put on any page of a site that told the browser where to locate the P3P policy document for the site (or for any portion of the site). http://www.w3.org/TR/P3P/#ref_syntax Are you proposing the same thing for OpenID login? (Kewl!) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 12:53 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: Dick Hardt wrote: In order for the RUA to detect that a site supports OpenID, it sees a form with a single input with a "name" of openid_identiifier. The RUA can then look at the action and post the data directly to the RP. I think it'd be better to implement this as either a META or a LINK element alongside a standard protocol for communicating with the nominated URL. This way the site can declare on *all pages*, rather than on the forms-based login page, that it accepts OpenID auth. This allows the user to go to the RP's home page (or any other page) and click the "OpenID Login" button on the browser's toolbar and have it work. That is an interesting idea. Would you like to take a stab at more specifics? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
Recordon, David wrote: Combining this with the fact that there is no viable way to enforce sections 8.1 or A.4 being MUSTs, I do not believe that they should be changed from SHOULDs. The only conceivable way I could see of enforcing something like this is telling a Relying Party that they cannot use OpenID Authentication if they don't follow these non-essential markup requirements; that is not something I am willing to do. "Be liberal in what you accept, be conservative in what you send." Enforcement is not a requirement. Having said that, I think I agree with you: SHOULD is probably strong enough to ensure that those who can, will. -- Pete smime.p7s Description: S/MIME Cryptographic Signature ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
On 10/19/06, Jonathan Daugherty <[EMAIL PROTECTED]> wrote: > I think it's there for convenience because no practices document > existed when that was inserted. I think Josh was considering removing > it anyway, though. I'm in favor of keeping the OpenID Authentication Protocol specification as small as possible, with as few restrictions as possible to get useful behavior. I think this kind of thing could go in another, companion specification, so that if people want to experiment, they can, without having to re-invent the parts that work. This is similar to my response to Dick in which I said that ideally identifier discovery and verification would be in another specification. The more we can reduce the scope, the more likely it is that we can develop a tight, usable specification that does not hold anyone back and is easy to implement. There are a couple of different insights that are common to OpenID, SXIP, LID, and the myriad other URL-based single-sign-on solutions that are out there. I want to codify the things that we all agree on and allow innovation around the things that we do not. I do not feel strongly about this particular issue, but I do feel strongly that if possible, we should REDUCE the scope as much as possible. If there is a way to accomplish your goal without changing OpenID, then DON'T CHANGE OPENID. It's easy to put stuff in the next revision, but it's hard to take stuff out. OpenID has been successful because its scope was intentionally extremely narrow. Lets keep it that way. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: PROPOSAL: OpenID Form Clarification (A.4)
Yes, section 8.1 is legacy from OpenID Auth 1.x as no best practices document existed at the time, nor does one exist today separate from the spec. If one did exist, I'd imagine that sections 8.1 and A.4 would reference it saying Relying Parties SHOULD follow it. Looking at ftp://ftp.isi.edu/in-notes/rfc2119.txt: > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. To me, that is the correct level of force for all of section 8.1 and A.4. The RFC goes on to say: > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for In no case does the non-existence of anything described in 8.1 or A.4 cause the protocol, as described by the specification, to no longer interoperate, between End Users, Relying Parties, and Identity Providers, nor does it limit behavior as described by the specification. This would certainly be different if this was an OpenID Rich Client specification. I'm certainly not saying it should actively try to limit development atop it, but we must be pragmatic or we'll end up shooting ourselves in the foot. Combining this with the fact that there is no viable way to enforce sections 8.1 or A.4 being MUSTs, I do not believe that they should be changed from SHOULDs. The only conceivable way I could see of enforcing something like this is telling a Relying Party that they cannot use OpenID Authentication if they don't follow these non-essential markup requirements; that is not something I am willing to do. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Daugherty Sent: Thursday, October 19, 2006 5:37 PM To: Pete Rowley Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) # A procedural point: If it is out of scope why is 8.1, and in # particular that line, in the spec? I submit that it evidently _is_ # in scope since it is there. I think it's there for convenience because no practices document existed when that was inserted. I think Josh was considering removing it anyway, though. -- Jonathan Daugherty JanRain, 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
Re: PROPOSAL: OpenID Form Clarification (A.4)
# A procedural point: If it is out of scope why is 8.1, and in # particular that line, in the spec? I submit that it evidently _is_ # in scope since it is there. I think it's there for convenience because no practices document existed when that was inserted. I think Josh was considering removing it anyway, though. -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
Jonathan Daugherty wrote: # This is true only if you never consider use cases for your protocol # which cover usability. That would be unwise. I don't think I know of # a protocol that was developed without regard to how it would be # used. I have said before that the form element name proposal is a good one, and I don't think anyone else disagrees that having a consistent name would be good for usability. Regardless, this design choice is out of scope for the OpenID 2.0 authentication spec. A procedural point: If it is out of scope why is 8.1, and in particular that line, in the spec? I submit that it evidently _is_ in scope since it is there. -- Pete smime.p7s Description: S/MIME Cryptographic Signature ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
# This is true only if you never consider use cases for your protocol # which cover usability. That would be unwise. I don't think I know of # a protocol that was developed without regard to how it would be # used. I have said before that the form element name proposal is a good one, and I don't think anyone else disagrees that having a consistent name would be good for usability. Regardless, this design choice is out of scope for the OpenID 2.0 authentication spec. -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
Jonathan Daugherty wrote: # we already know that browser-chrome plugins will be supporting # OpenID - as soon as an RP picks some other field name, he'll get a # flood of complains from users who can't log in to his site. And that has nothing to do with the *protocol*. Put it in a Best Practices document instead. Or create an OpenID Rich Client specification. This is true only if you never consider use cases for your protocol which cover usability. That would be unwise. I don't think I know of a protocol that was developed without regard to how it would be used. -- Pete smime.p7s Description: S/MIME Cryptographic Signature ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
On 19-Oct-06, at 10:23 AM, Josh Hoyt wrote: > On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> I like your proposal. I would tweak the name: >> >> http://my.rp.com/openid/blah.cgi";> > > This is what Yadis was designed for. Since OpenID already requires > Yadis, this should be implemented as a Service entry in the Yadis > document for any page on which you want that information. Just to clarify then, you would suggest that the RP include a meta tag with a reference to the RPs Yadis document? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
Which is still described in the latest draft, see http://openid.net/specs/openid-authentication-2_0-10.html#anchor42. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, October 19, 2006 1:24 PM To: Dick Hardt Cc: specs@openid.net Subject: Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4) On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > I like your proposal. I would tweak the name: > > http://my.rp.com/openid/blah.cgi";> This is what Yadis was designed for. Since OpenID already requires Yadis, this should be implemented as a Service entry in the Yadis document for any page on which you want that information. 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: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Drummond Reed wrote: > Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea > notion for a site advertising the location of the P3P privacy policy: it > defined a standard HTML/XHTML link tag that could be put on any page of a > site that told the browser where to locate the P3P policy document for the > site (or for any portion of the site). > > http://www.w3.org/TR/P3P/#ref_syntax > > Are you proposing the same thing for OpenID login? > Yes, that is the idea. I don't have time at this moment to write out a full proposal, so I'll just quickly summarize/ramble... Right then. On any page of the RP, they can write: http://www.mysite.com/openid"; /> [1] Now, if we make to that URL the same kind of request that a return_to URL expects to receive, the RP has almost everything it needs to get going with the request. Unless I've missed something, all it's missing is the public identifier the user has selected — what he would have entered into the form under normal circumstances. So we define an extra parameter oirp.identifier to carry that. Now with only minimal changes to the RP we have an interface that a clever client can use to login without forms. This just leaves the rich client to IdP communication. As I noted in a similar message on the other mailing list, this doesn't actually *need* to be a standard at all — the IdP could just issue a plugin which works only with that IdP. That's a lot of duplication of work, however. So what we need is another standard protocol by which the rich client can request a signature; the input argument is the IdP Token, or claimed_identity as the auth spec calls it. Since there has thus far been no communication between RP and IdP, "dumb mode" must be used; the IdP returns a signature and a handle to the rich client, which it then sends on to openid.rp as described above. The RP can then resolve the presented identity to find the IdP and validate the signature. This is really just a variation on the HTTP auth proposal. The differences are: * Rich client passes args to RP via query string rather than WWW-Authenticate header. * We actually specify a protocol for the communication between the rich client and the IdP, unlike my HTTP auth proposal which left that out of scope. Note that HTTP auth can potentially make use of this protocol too. * There's a separation between the URL where you discover the OpenID support and the URL where you make use of it. With HTTP auth, you just make a request and get back a 401 Unauthorized, or you just "know" the URL ahead of time. Really, the above could use the HTTP auth protocol to talk to the RP's endpoint, but I selected the above because it makes the required RP changes much simpler — just support an extra argument in your return_to handler. [1] This is just an example. We'd probably use Yadis in practice, since that would give us versioning for free and the ability to add other services. However, this would make implementation marginally harder for plugin developers as they now need to do more than just grovel around in the DOM of each page as it is loaded, and it'll create an extra overhead for any page that has an X-Yadis-Location, regardless of whether this particular service is listed. I'll leave it to others to debate whether to use Yadis, a custom LINK REL, or some META element. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > Just to clarify then, you would suggest that the RP include a meta > tag with a reference to the RPs Yadis document? Any URL that wants to have a login URL associated with it can use whichever of the mechanisms provided by Yadis to point to a Yadis document with the login information in it. Including a meta tag that points to a single, site-wide XRDS document is one valid instance of that. I would expect that most Web apps would prefer to send the "XRDS-Location" header if possible, and also support content-negotiation to obtain the XRDS document. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > I like your proposal. I would tweak the name: > > http://my.rp.com/openid/blah.cgi";> This is what Yadis was designed for. Since OpenID already requires Yadis, this should be implemented as a Service entry in the Yadis document for any page on which you want that information. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
# we already know that browser-chrome plugins will be supporting # OpenID - as soon as an RP picks some other field name, he'll get a # flood of complains from users who can't log in to his site. And that has nothing to do with the *protocol*. Put it in a Best Practices document instead. Or create an OpenID Rich Client specification. -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
Hey Chris, I like your proposal. I would tweak the name: http://my.rp.com/openid/blah.cgi";> Perhaps you can write it up and put a link on David's proposal wiki at: http://www.lifewiki.net/openid/OpenIDProposals I think I chewed through my proposal quota a while ago. ;-) -- Dick On 19-Oct-06, at 9:45 AM, Chris Drake wrote: > Hi David, > > Besides other DIX lurkers, we know for sure that Dick, Andy, and > myself are all building "chrome" extensions and/or rich-clients, so I > think you'll have no problems getting a "consensus" on this. > > My personal vote is for something like this:- > http://my.rp.com/openid/blah.cgi";> > either on the page with the login , or even every page on an > OpenID 2.0 enabled site. > > Browser agents and IdP's alike can use this information not just for > facilitating chrome etc, but also for privacy protection, *true* > single-signon, identifier selection, and a range of other things. > > Kind Regards, > Chris Drake > > > Thursday, October 19, 2006, 3:33:31 PM, you wrote: > > RD> This isn't worth me standing in the way. If you can get general > RD> consensus of those actively participating in the spec process > then I > RD> won't stand in the way of the community, in fact if this > happens I'd be > RD> happy to make the change to the spec. > > RD> There seems to be other ways to deal with this though, since > you're > RD> going to have to deal with the case of a RP not having this > markup. > RD> Giving the rich client an icon like the SSL padlock which > lights up when > RD> the user visits a RP that supports it and then the user > clicking it, or > RD> submitting the form, to start the flow seems like one viable entry > RD> point. To deal with a RP with no markup, the user would not > see the > RD> icon illuminate, position their cursor within the OpenID field, > and then > RD> click the icon which would indicate to the client that this > actually is > RD> a RP as well as let it capture the field within the DOM to > interact > RD> with. > > RD> --David > > RD> -Original Message- > RD> From: Dick Hardt [mailto:[EMAIL PROTECTED] > RD> Sent: Thursday, October 19, 2006 1:04 AM > RD> To: Recordon, David > RD> Cc: Jonathan Daugherty; specs@openid.net > RD> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) > > RD> Unfortunate that was not captured in the notes. When I said > that we > RD> needed tags to detect, there was consensus that was not a problem. > > RD> We are building a rich client. It will be available in the not- > too- > RD> distant-future. > > RD> We are working on what it will take to implement, and have > figured out > RD> how to make it all work, but need to detect that the site is an > RP. > > RD> Lack of clarity on what MUST happen adding many, many lines of > code to > RD> the early browsers. It would be good to not repeat that mistake. > > RD> I really don't see how making this a MUST instead of SHOULD > would slow > RD> specs or implementation as I am sure most people will just do > it anyway. > > RD> I've made my case and will let it rest. > > RD> -- Dick > > > RD> On 18-Oct-06, at 9:55 PM, Recordon, David wrote: > >>> Here are notes from the June meeting, which we all looked over >>> before >>> I sent them out. All I see in relation to rich clients is that DIX >>> supported them, though I don't remember any decision being made >>> that a > >>> requirement of OpenID Authentication was every relying party >>> enabling >>> the use of a rich client. >>> http://lists.danga.com/pipermail/yadis/2006-June/002648.html >>> >>> I don't think this should be a MUST as it adds one more requirement >>> which we can't even effectively enforce. If/when rich client >>> software > >>> gets out there and is being actively used, I'd be much more inclined >>> to change this to a MUST. Right now I think we should just get this >>> spec done, get people using it, and see what develops and thus >>> how it >>> needs to evolve! >>> >>> --David >>> >>> -Original Message- >>> From: Dick Hardt [mailto:[EMAIL PROTECTED] >>> Sent: Thursday, October 19, 2006 12:44 AM >>> To: Recordon, David >>> Cc: Jonathan Daugherty; specs@openid.net >>> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >>> &
Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
Hi David, Besides other DIX lurkers, we know for sure that Dick, Andy, and myself are all building "chrome" extensions and/or rich-clients, so I think you'll have no problems getting a "consensus" on this. My personal vote is for something like this:- http://my.rp.com/openid/blah.cgi";> either on the page with the login , or even every page on an OpenID 2.0 enabled site. Browser agents and IdP's alike can use this information not just for facilitating chrome etc, but also for privacy protection, *true* single-signon, identifier selection, and a range of other things. Kind Regards, Chris Drake Thursday, October 19, 2006, 3:33:31 PM, you wrote: RD> This isn't worth me standing in the way. If you can get general RD> consensus of those actively participating in the spec process then I RD> won't stand in the way of the community, in fact if this happens I'd be RD> happy to make the change to the spec. RD> There seems to be other ways to deal with this though, since you're RD> going to have to deal with the case of a RP not having this markup. RD> Giving the rich client an icon like the SSL padlock which lights up when RD> the user visits a RP that supports it and then the user clicking it, or RD> submitting the form, to start the flow seems like one viable entry RD> point. To deal with a RP with no markup, the user would not see the RD> icon illuminate, position their cursor within the OpenID field, and then RD> click the icon which would indicate to the client that this actually is RD> a RP as well as let it capture the field within the DOM to interact RD> with. RD> --David RD> -Original Message- RD> From: Dick Hardt [mailto:[EMAIL PROTECTED] RD> Sent: Thursday, October 19, 2006 1:04 AM RD> To: Recordon, David RD> Cc: Jonathan Daugherty; specs@openid.net RD> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) RD> Unfortunate that was not captured in the notes. When I said that we RD> needed tags to detect, there was consensus that was not a problem. RD> We are building a rich client. It will be available in the not-too- RD> distant-future. RD> We are working on what it will take to implement, and have figured out RD> how to make it all work, but need to detect that the site is an RP. RD> Lack of clarity on what MUST happen adding many, many lines of code to RD> the early browsers. It would be good to not repeat that mistake. RD> I really don't see how making this a MUST instead of SHOULD would slow RD> specs or implementation as I am sure most people will just do it anyway. RD> I've made my case and will let it rest. RD> -- Dick RD> On 18-Oct-06, at 9:55 PM, Recordon, David wrote: >> Here are notes from the June meeting, which we all looked over before >> I sent them out. All I see in relation to rich clients is that DIX >> supported them, though I don't remember any decision being made that a >> requirement of OpenID Authentication was every relying party enabling >> the use of a rich client. >> http://lists.danga.com/pipermail/yadis/2006-June/002648.html >> >> I don't think this should be a MUST as it adds one more requirement >> which we can't even effectively enforce. If/when rich client software >> gets out there and is being actively used, I'd be much more inclined >> to change this to a MUST. Right now I think we should just get this >> spec done, get people using it, and see what develops and thus how it >> needs to evolve! >> >> --David >> >> -Original Message- >> From: Dick Hardt [mailto:[EMAIL PROTECTED] >> Sent: Thursday, October 19, 2006 12:44 AM >> To: Recordon, David >> Cc: Jonathan Daugherty; specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> That is news to me that supporting Rich Clients is not a requirement. >> Rich client support was a discussion point back in July at the meeting >> in VeriSign, and there was consensus to support Rich Clients then >> >> Would you point me to the list of requirements so that we can all get >> on the same page on what they are? >> >> I am really confused why you would not want this to be a MUST. >> >> -- Dick >> >> On 18-Oct-06, at 9:35 PM, Recordon, David wrote: >> >>> The spec is an authentication spec which does not discuss rich >>> clients >> >>> anywhere. >>> >>> As I've said, and I'd think others would agree, it is not a >>> requirement of the spec to enable rich clients. It is great to have >>> them and great for it to enable them. Whether the spec says this is >>>
Re[2]: PROPOSAL: OpenID Form Clarification (A.4)
Hi Jonathan, I vote for MUST. The opinion of unenforcability isn't a justification for SHOULD, and I disagree with that opinion anyhow: we already know that browser-chrome plugins will be supporting OpenID - as soon as an RP picks some other field name, he'll get a flood of complains from users who can't log in to his site. Kind Regards, Chris Drake Thursday, October 19, 2006, 5:27:02 PM, you wrote: JD> # Why SHOULD rather then MUST? [1] JD> # JD> # What valid reason is there for an RP to not have that field name? JD> The simple reason is that one can't enforce a MUST in this case. (And JD> even if one ammends the spec to make the field name a prerequisite for JD> OpenID, I question whether that is a good design choice.) JD> I agree that it would be extremely useful to have a consistent form JD> field name for just the reasons you cited, and the current spec JD> reflects that. If the spec is the place one would put preferences, JD> then they should be RECOMMENDEDs or SHOULDs: not MUSTs. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea notion for a site advertising the location of the P3P privacy policy: it defined a standard HTML/XHTML link tag that could be put on any page of a site that told the browser where to locate the P3P policy document for the site (or for any portion of the site). http://www.w3.org/TR/P3P/#ref_syntax Are you proposing the same thing for OpenID login? (Kewl!) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 12:53 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: > Dick Hardt wrote: >> >> In order for the RUA to detect that a site supports OpenID, it sees a >> form with a single input with a "name" of openid_identiifier. The RUA >> can then look at the action and post the data directly to the RP. >> > > I think it'd be better to implement this as either a META or a LINK > element alongside a standard protocol for communicating with the > nominated URL. > > This way the site can declare on *all pages*, rather than on the > forms-based login page, that it accepts OpenID auth. This allows the > user to go to the RP's home page (or any other page) and click the > "OpenID Login" button on the browser's toolbar and have it work. That is an interesting idea. Would you like to take a stab at more specifics? -- Dick ___ 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: OpenID Form Clarification (A.4)
On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: > Dick Hardt wrote: >> >> In order for the RUA to detect that a site supports OpenID, it sees a >> form with a single input with a "name" of openid_identiifier. The RUA >> can then look at the action and post the data directly to the RP. >> > > I think it'd be better to implement this as either a META or a LINK > element alongside a standard protocol for communicating with the > nominated URL. > > This way the site can declare on *all pages*, rather than on the > forms-based login page, that it accepts OpenID auth. This allows the > user to go to the RP's home page (or any other page) and click the > "OpenID Login" button on the browser's toolbar and have it work. That is an interesting idea. Would you like to take a stab at more specifics? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
Dick Hardt wrote: > > In order for the RUA to detect that a site supports OpenID, it sees a > form with a single input with a "name" of openid_identiifier. The RUA > can then look at the action and post the data directly to the RP. > I think it'd be better to implement this as either a META or a LINK element alongside a standard protocol for communicating with the nominated URL. This way the site can declare on *all pages*, rather than on the forms-based login page, that it accepts OpenID auth. This allows the user to go to the RP's home page (or any other page) and click the "OpenID Login" button on the browser's toolbar and have it work. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
# Why SHOULD rather then MUST? [1] # # What valid reason is there for an RP to not have that field name? The simple reason is that one can't enforce a MUST in this case. (And even if one ammends the spec to make the field name a prerequisite for OpenID, I question whether that is a good design choice.) I agree that it would be extremely useful to have a consistent form field name for just the reasons you cited, and the current spec reflects that. If the spec is the place one would put preferences, then they should be RECOMMENDEDs or SHOULDs: not MUSTs. -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
On 18-Oct-06, at 10:33 PM, Recordon, David wrote: > This isn't worth me standing in the way. If you can get general > consensus of those actively participating in the spec process then I > won't stand in the way of the community, in fact if this happens > I'd be > happy to make the change to the spec. thanks, I think :) > > There seems to be other ways to deal with this though, since you're > going to have to deal with the case of a RP not having this markup. > Giving the rich client an icon like the SSL padlock which lights up > when > the user visits a RP that supports it and then the user clicking > it, or > submitting the form, to start the flow seems like one viable entry > point. To deal with a RP with no markup, the user would not see the > icon illuminate, position their cursor within the OpenID field, and > then > click the icon which would indicate to the client that this > actually is > a RP as well as let it capture the field within the DOM to interact > with. Presenting an interface for the user to interact with when the form is detected is easy for the user to grasp. We have something that sits on top of the form so it is clear to the user. Teaching them to select some chrome when the tag is missing is tough to do. This will be much more clear when you get to see a demo! -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: PROPOSAL: OpenID Form Clarification (A.4)
This isn't worth me standing in the way. If you can get general consensus of those actively participating in the spec process then I won't stand in the way of the community, in fact if this happens I'd be happy to make the change to the spec. There seems to be other ways to deal with this though, since you're going to have to deal with the case of a RP not having this markup. Giving the rich client an icon like the SSL padlock which lights up when the user visits a RP that supports it and then the user clicking it, or submitting the form, to start the flow seems like one viable entry point. To deal with a RP with no markup, the user would not see the icon illuminate, position their cursor within the OpenID field, and then click the icon which would indicate to the client that this actually is a RP as well as let it capture the field within the DOM to interact with. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 1:04 AM To: Recordon, David Cc: Jonathan Daugherty; specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) Unfortunate that was not captured in the notes. When I said that we needed tags to detect, there was consensus that was not a problem. We are building a rich client. It will be available in the not-too- distant-future. We are working on what it will take to implement, and have figured out how to make it all work, but need to detect that the site is an RP. Lack of clarity on what MUST happen adding many, many lines of code to the early browsers. It would be good to not repeat that mistake. I really don't see how making this a MUST instead of SHOULD would slow specs or implementation as I am sure most people will just do it anyway. I've made my case and will let it rest. -- Dick On 18-Oct-06, at 9:55 PM, Recordon, David wrote: > Here are notes from the June meeting, which we all looked over before > I sent them out. All I see in relation to rich clients is that DIX > supported them, though I don't remember any decision being made that a > requirement of OpenID Authentication was every relying party enabling > the use of a rich client. > http://lists.danga.com/pipermail/yadis/2006-June/002648.html > > I don't think this should be a MUST as it adds one more requirement > which we can't even effectively enforce. If/when rich client software > gets out there and is being actively used, I'd be much more inclined > to change this to a MUST. Right now I think we should just get this > spec done, get people using it, and see what develops and thus how it > needs to evolve! > > --David > > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 19, 2006 12:44 AM > To: Recordon, David > Cc: Jonathan Daugherty; specs@openid.net > Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) > > That is news to me that supporting Rich Clients is not a requirement. > Rich client support was a discussion point back in July at the meeting > in VeriSign, and there was consensus to support Rich Clients then > > Would you point me to the list of requirements so that we can all get > on the same page on what they are? > > I am really confused why you would not want this to be a MUST. > > -- Dick > > On 18-Oct-06, at 9:35 PM, Recordon, David wrote: > >> The spec is an authentication spec which does not discuss rich >> clients > >> anywhere. >> >> As I've said, and I'd think others would agree, it is not a >> requirement of the spec to enable rich clients. It is great to have >> them and great for it to enable them. Whether the spec says this is >> a > >> MUST or not you'll still have to tell users that not all relying >> parties will support the use of the rich client. It seems >> presumptuous for us to think that by making this a MUST we'll be able >> to force every relying party into doing it, when to them not doing it >> doesn't actually break anything within the authentication protocol. >> >> Six months from now this may be a different story, but for now I >> guess > >> we just don't see eye to eye on the issue. :-\ >> >> --David >> >> -Original Message- >> From: Dick Hardt [mailto:[EMAIL PROTECTED] >> Sent: Thursday, October 19, 2006 12:08 AM >> To: Recordon, David >> Cc: Jonathan Daugherty; specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> Please see the RFC. SHOULD is used if there is a valid reason for it >> not being a MUST. >> >> If the RP does not have the tag, the a rich client will not work. >> Authentication cannot procee
Re: PROPOSAL: OpenID Form Clarification (A.4)
Well, not quite let it rest. :-) There was no comment on the "action" in the form for check_immediate. Is that ok to go in the spec if it is a SHOULD? -- Dick On 18-Oct-06, at 10:04 PM, Dick Hardt wrote: > Unfortunate that was not captured in the notes. When I said that we > needed tags to detect, there was consensus that was not a problem. > > We are building a rich client. It will be available in the not-too- > distant-future. > > We are working on what it will take to implement, and have figured > out how to make it all work, but need to detect that the site is an > RP. > > Lack of clarity on what MUST happen adding many, many lines of code > to the early browsers. It would be good to not repeat that mistake. > > I really don't see how making this a MUST instead of SHOULD would > slow specs or implementation as I am sure most people will just do it > anyway. > > I've made my case and will let it rest. > > -- Dick > > > On 18-Oct-06, at 9:55 PM, Recordon, David wrote: > >> Here are notes from the June meeting, which we all looked over >> before I >> sent them out. All I see in relation to rich clients is that DIX >> supported them, though I don't remember any decision being made >> that a >> requirement of OpenID Authentication was every relying party enabling >> the use of a rich client. >> http://lists.danga.com/pipermail/yadis/2006-June/002648.html >> >> I don't think this should be a MUST as it adds one more requirement >> which we can't even effectively enforce. If/when rich client >> software >> gets out there and is being actively used, I'd be much more >> inclined to >> change this to a MUST. Right now I think we should just get this >> spec >> done, get people using it, and see what develops and thus how it >> needs >> to evolve! >> >> --David >> >> -Original Message- >> From: Dick Hardt [mailto:[EMAIL PROTECTED] >> Sent: Thursday, October 19, 2006 12:44 AM >> To: Recordon, David >> Cc: Jonathan Daugherty; specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> That is news to me that supporting Rich Clients is not a requirement. >> Rich client support was a discussion point back in July at the >> meeting >> in VeriSign, and there was consensus to support Rich Clients then >> >> Would you point me to the list of requirements so that we can all >> get on >> the same page on what they are? >> >> I am really confused why you would not want this to be a MUST. >> >> -- Dick >> >> On 18-Oct-06, at 9:35 PM, Recordon, David wrote: >> >>> The spec is an authentication spec which does not discuss rich >>> clients >> >>> anywhere. >>> >>> As I've said, and I'd think others would agree, it is not a >>> requirement of the spec to enable rich clients. It is great to have >>> them and great for it to enable them. Whether the spec says this >>> is a >> >>> MUST or not you'll still have to tell users that not all relying >>> parties will support the use of the rich client. It seems >>> presumptuous for us to think that by making this a MUST we'll be >>> able >>> to force every relying party into doing it, when to them not >>> doing it >>> doesn't actually break anything within the authentication protocol. >>> >>> Six months from now this may be a different story, but for now I >>> guess >> >>> we just don't see eye to eye on the issue. :-\ >>> >>> --David >>> >>> -Original Message- >>> From: Dick Hardt [mailto:[EMAIL PROTECTED] >>> Sent: Thursday, October 19, 2006 12:08 AM >>> To: Recordon, David >>> Cc: Jonathan Daugherty; specs@openid.net >>> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >>> >>> Please see the RFC. SHOULD is used if there is a valid reason for it >>> not being a MUST. >>> >>> If the RP does not have the tag, the a rich client will not work. >>> Authentication cannot proceed. That is broken as far as the user is >>> concerned. >>> >>> What if doing HTML disco was a SHOULD instead of a MUST? Then >>> that RP >>> would not work with certain identifiers. >>> >>> -- Dick >>> >>> On 18-Oct-06, at 8:58 PM, Recordon, David wrote: >>> >>>> In my view, it is because the authentication protocol can proceed &
Re: PROPOSAL: OpenID Form Clarification (A.4)
Unfortunate that was not captured in the notes. When I said that we needed tags to detect, there was consensus that was not a problem. We are building a rich client. It will be available in the not-too- distant-future. We are working on what it will take to implement, and have figured out how to make it all work, but need to detect that the site is an RP. Lack of clarity on what MUST happen adding many, many lines of code to the early browsers. It would be good to not repeat that mistake. I really don't see how making this a MUST instead of SHOULD would slow specs or implementation as I am sure most people will just do it anyway. I've made my case and will let it rest. -- Dick On 18-Oct-06, at 9:55 PM, Recordon, David wrote: > Here are notes from the June meeting, which we all looked over > before I > sent them out. All I see in relation to rich clients is that DIX > supported them, though I don't remember any decision being made that a > requirement of OpenID Authentication was every relying party enabling > the use of a rich client. > http://lists.danga.com/pipermail/yadis/2006-June/002648.html > > I don't think this should be a MUST as it adds one more requirement > which we can't even effectively enforce. If/when rich client software > gets out there and is being actively used, I'd be much more > inclined to > change this to a MUST. Right now I think we should just get this spec > done, get people using it, and see what develops and thus how it needs > to evolve! > > --David > > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 19, 2006 12:44 AM > To: Recordon, David > Cc: Jonathan Daugherty; specs@openid.net > Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) > > That is news to me that supporting Rich Clients is not a requirement. > Rich client support was a discussion point back in July at the meeting > in VeriSign, and there was consensus to support Rich Clients then > > Would you point me to the list of requirements so that we can all > get on > the same page on what they are? > > I am really confused why you would not want this to be a MUST. > > -- Dick > > On 18-Oct-06, at 9:35 PM, Recordon, David wrote: > >> The spec is an authentication spec which does not discuss rich >> clients > >> anywhere. >> >> As I've said, and I'd think others would agree, it is not a >> requirement of the spec to enable rich clients. It is great to have >> them and great for it to enable them. Whether the spec says this >> is a > >> MUST or not you'll still have to tell users that not all relying >> parties will support the use of the rich client. It seems >> presumptuous for us to think that by making this a MUST we'll be able >> to force every relying party into doing it, when to them not doing it >> doesn't actually break anything within the authentication protocol. >> >> Six months from now this may be a different story, but for now I >> guess > >> we just don't see eye to eye on the issue. :-\ >> >> --David >> >> -Original Message- >> From: Dick Hardt [mailto:[EMAIL PROTECTED] >> Sent: Thursday, October 19, 2006 12:08 AM >> To: Recordon, David >> Cc: Jonathan Daugherty; specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> Please see the RFC. SHOULD is used if there is a valid reason for it >> not being a MUST. >> >> If the RP does not have the tag, the a rich client will not work. >> Authentication cannot proceed. That is broken as far as the user is >> concerned. >> >> What if doing HTML disco was a SHOULD instead of a MUST? Then that RP >> would not work with certain identifiers. >> >> -- Dick >> >> On 18-Oct-06, at 8:58 PM, Recordon, David wrote: >> >>> In my view, it is because the authentication protocol can proceed >>> with >> >>> no problems if this field is named something different. As things >>> won't break, as far as the protocol is concerned, this would also be >>> nearly impossible to enforce or justify. It is easy to tell a >>> developer to fix how they're creating signatures, authentication >>> transactions do not complete, but enforcing convention around form >>> fields seems difficult at best. I'd imagine that if a RP does not >>> follow this recommendation then a rich client should treat it as not >>> being a relying party. >>> >>> --David >>> >>> -Original Message- >>> From: Di
RE: PROPOSAL: OpenID Form Clarification (A.4)
Here are notes from the June meeting, which we all looked over before I sent them out. All I see in relation to rich clients is that DIX supported them, though I don't remember any decision being made that a requirement of OpenID Authentication was every relying party enabling the use of a rich client. http://lists.danga.com/pipermail/yadis/2006-June/002648.html I don't think this should be a MUST as it adds one more requirement which we can't even effectively enforce. If/when rich client software gets out there and is being actively used, I'd be much more inclined to change this to a MUST. Right now I think we should just get this spec done, get people using it, and see what develops and thus how it needs to evolve! --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 12:44 AM To: Recordon, David Cc: Jonathan Daugherty; specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) That is news to me that supporting Rich Clients is not a requirement. Rich client support was a discussion point back in July at the meeting in VeriSign, and there was consensus to support Rich Clients then Would you point me to the list of requirements so that we can all get on the same page on what they are? I am really confused why you would not want this to be a MUST. -- Dick On 18-Oct-06, at 9:35 PM, Recordon, David wrote: > The spec is an authentication spec which does not discuss rich clients > anywhere. > > As I've said, and I'd think others would agree, it is not a > requirement of the spec to enable rich clients. It is great to have > them and great for it to enable them. Whether the spec says this is a > MUST or not you'll still have to tell users that not all relying > parties will support the use of the rich client. It seems > presumptuous for us to think that by making this a MUST we'll be able > to force every relying party into doing it, when to them not doing it > doesn't actually break anything within the authentication protocol. > > Six months from now this may be a different story, but for now I guess > we just don't see eye to eye on the issue. :-\ > > --David > > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 19, 2006 12:08 AM > To: Recordon, David > Cc: Jonathan Daugherty; specs@openid.net > Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) > > Please see the RFC. SHOULD is used if there is a valid reason for it > not being a MUST. > > If the RP does not have the tag, the a rich client will not work. > Authentication cannot proceed. That is broken as far as the user is > concerned. > > What if doing HTML disco was a SHOULD instead of a MUST? Then that RP > would not work with certain identifiers. > > -- Dick > > On 18-Oct-06, at 8:58 PM, Recordon, David wrote: > >> In my view, it is because the authentication protocol can proceed >> with > >> no problems if this field is named something different. As things >> won't break, as far as the protocol is concerned, this would also be >> nearly impossible to enforce or justify. It is easy to tell a >> developer to fix how they're creating signatures, authentication >> transactions do not complete, but enforcing convention around form >> fields seems difficult at best. I'd imagine that if a RP does not >> follow this recommendation then a rich client should treat it as not >> being a relying party. >> >> --David >> >> -Original Message- >> From: Dick Hardt [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, October 18, 2006 11:35 PM >> To: Recordon, David >> Cc: Jonathan Daugherty; specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> Why SHOULD rather then MUST? [1] >> >> What valid reason is there for an RP to not have that field name? >> >> [1] http://www.ietf.org/rfc/rfc2119.txt >> >> -- Dick >> >> On 18-Oct-06, at 1:28 PM, Recordon, David wrote: >> >>> Agreed, just like the spec already says "The form field's "name" >>> attribute SHOULD have the value "openid_identifier" as to allow User >>> Agents to automatically prefill the End User's Identifier when >>> visiting a Relying Party." >>> >>> I'm all for this feature, as well as even identifying the form >>> itself, >> >>> though don't see how it should be a MUST over a SHOULD for a Relying >>> Party. >>> >>> --David >>> >>> -Original Message- >>> From
Re: PROPOSAL: OpenID Form Clarification (A.4)
That is news to me that supporting Rich Clients is not a requirement. Rich client support was a discussion point back in July at the meeting in VeriSign, and there was consensus to support Rich Clients then Would you point me to the list of requirements so that we can all get on the same page on what they are? I am really confused why you would not want this to be a MUST. -- Dick On 18-Oct-06, at 9:35 PM, Recordon, David wrote: > The spec is an authentication spec which does not discuss rich clients > anywhere. > > As I've said, and I'd think others would agree, it is not a > requirement > of the spec to enable rich clients. It is great to have them and > great > for it to enable them. Whether the spec says this is a MUST or not > you'll still have to tell users that not all relying parties will > support the use of the rich client. It seems presumptuous for us to > think that by making this a MUST we'll be able to force every relying > party into doing it, when to them not doing it doesn't actually break > anything within the authentication protocol. > > Six months from now this may be a different story, but for now I guess > we just don't see eye to eye on the issue. :-\ > > --David > > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 19, 2006 12:08 AM > To: Recordon, David > Cc: Jonathan Daugherty; specs@openid.net > Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) > > Please see the RFC. SHOULD is used if there is a valid reason for > it not > being a MUST. > > If the RP does not have the tag, the a rich client will not work. > Authentication cannot proceed. That is broken as far as the user is > concerned. > > What if doing HTML disco was a SHOULD instead of a MUST? Then that RP > would not work with certain identifiers. > > -- Dick > > On 18-Oct-06, at 8:58 PM, Recordon, David wrote: > >> In my view, it is because the authentication protocol can proceed >> with > >> no problems if this field is named something different. As things >> won't break, as far as the protocol is concerned, this would also be >> nearly impossible to enforce or justify. It is easy to tell a >> developer to fix how they're creating signatures, authentication >> transactions do not complete, but enforcing convention around form >> fields seems difficult at best. I'd imagine that if a RP does not >> follow this recommendation then a rich client should treat it as not >> being a relying party. >> >> --David >> >> -Original Message- >> From: Dick Hardt [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, October 18, 2006 11:35 PM >> To: Recordon, David >> Cc: Jonathan Daugherty; specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> Why SHOULD rather then MUST? [1] >> >> What valid reason is there for an RP to not have that field name? >> >> [1] http://www.ietf.org/rfc/rfc2119.txt >> >> -- Dick >> >> On 18-Oct-06, at 1:28 PM, Recordon, David wrote: >> >>> Agreed, just like the spec already says "The form field's "name" >>> attribute SHOULD have the value "openid_identifier" as to allow User >>> Agents to automatically prefill the End User's Identifier when >>> visiting a Relying Party." >>> >>> I'm all for this feature, as well as even identifying the form >>> itself, >> >>> though don't see how it should be a MUST over a SHOULD for a Relying >>> Party. >>> >>> --David >>> >>> -Original Message- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >>> Behalf Of Jonathan Daugherty >>> Sent: Wednesday, October 18, 2006 2:33 PM >>> To: Dick Hardt >>> Cc: specs@openid.net >>> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >>> >>> # Proposal >>> # >>> # Modify 8.1 to: >>> # ... >>> # >>> # The form field's "name" attribute MUST have the value # >>> "openid_identifier" as to allow User Agents to automatically prefill >>> # >> >>> the End User's Identifier when visiting a Relying Party. >>> >>> This should be a SHOULD, not a MUST. >>> >>> -- >>> Jonathan Daugherty >>> JanRain, 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
RE: PROPOSAL: OpenID Form Clarification (A.4)
The spec is an authentication spec which does not discuss rich clients anywhere. As I've said, and I'd think others would agree, it is not a requirement of the spec to enable rich clients. It is great to have them and great for it to enable them. Whether the spec says this is a MUST or not you'll still have to tell users that not all relying parties will support the use of the rich client. It seems presumptuous for us to think that by making this a MUST we'll be able to force every relying party into doing it, when to them not doing it doesn't actually break anything within the authentication protocol. Six months from now this may be a different story, but for now I guess we just don't see eye to eye on the issue. :-\ --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 12:08 AM To: Recordon, David Cc: Jonathan Daugherty; specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) Please see the RFC. SHOULD is used if there is a valid reason for it not being a MUST. If the RP does not have the tag, the a rich client will not work. Authentication cannot proceed. That is broken as far as the user is concerned. What if doing HTML disco was a SHOULD instead of a MUST? Then that RP would not work with certain identifiers. -- Dick On 18-Oct-06, at 8:58 PM, Recordon, David wrote: > In my view, it is because the authentication protocol can proceed with > no problems if this field is named something different. As things > won't break, as far as the protocol is concerned, this would also be > nearly impossible to enforce or justify. It is easy to tell a > developer to fix how they're creating signatures, authentication > transactions do not complete, but enforcing convention around form > fields seems difficult at best. I'd imagine that if a RP does not > follow this recommendation then a rich client should treat it as not > being a relying party. > > --David > > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 18, 2006 11:35 PM > To: Recordon, David > Cc: Jonathan Daugherty; specs@openid.net > Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) > > Why SHOULD rather then MUST? [1] > > What valid reason is there for an RP to not have that field name? > > [1] http://www.ietf.org/rfc/rfc2119.txt > > -- Dick > > On 18-Oct-06, at 1:28 PM, Recordon, David wrote: > >> Agreed, just like the spec already says "The form field's "name" >> attribute SHOULD have the value "openid_identifier" as to allow User >> Agents to automatically prefill the End User's Identifier when >> visiting a Relying Party." >> >> I'm all for this feature, as well as even identifying the form >> itself, > >> though don't see how it should be a MUST over a SHOULD for a Relying >> Party. >> >> --David >> >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Jonathan Daugherty >> Sent: Wednesday, October 18, 2006 2:33 PM >> To: Dick Hardt >> Cc: specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> # Proposal >> # >> # Modify 8.1 to: >> # ... >> # >> # The form field's "name" attribute MUST have the value # >> "openid_identifier" as to allow User Agents to automatically prefill >> # > >> the End User's Identifier when visiting a Relying Party. >> >> This should be a SHOULD, not a MUST. >> >> -- >> Jonathan Daugherty >> JanRain, 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
Re: PROPOSAL: OpenID Form Clarification (A.4)
Please see the RFC. SHOULD is used if there is a valid reason for it not being a MUST. If the RP does not have the tag, the a rich client will not work. Authentication cannot proceed. That is broken as far as the user is concerned. What if doing HTML disco was a SHOULD instead of a MUST? Then that RP would not work with certain identifiers. -- Dick On 18-Oct-06, at 8:58 PM, Recordon, David wrote: > In my view, it is because the authentication protocol can proceed with > no problems if this field is named something different. As things > won't > break, as far as the protocol is concerned, this would also be nearly > impossible to enforce or justify. It is easy to tell a developer > to fix > how they're creating signatures, authentication transactions do not > complete, but enforcing convention around form fields seems > difficult at > best. I'd imagine that if a RP does not follow this recommendation > then > a rich client should treat it as not being a relying party. > > --David > > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 18, 2006 11:35 PM > To: Recordon, David > Cc: Jonathan Daugherty; specs@openid.net > Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) > > Why SHOULD rather then MUST? [1] > > What valid reason is there for an RP to not have that field name? > > [1] http://www.ietf.org/rfc/rfc2119.txt > > -- Dick > > On 18-Oct-06, at 1:28 PM, Recordon, David wrote: > >> Agreed, just like the spec already says "The form field's "name" >> attribute SHOULD have the value "openid_identifier" as to allow User >> Agents to automatically prefill the End User's Identifier when >> visiting a Relying Party." >> >> I'm all for this feature, as well as even identifying the form >> itself, > >> though don't see how it should be a MUST over a SHOULD for a Relying >> Party. >> >> --David >> >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Jonathan Daugherty >> Sent: Wednesday, October 18, 2006 2:33 PM >> To: Dick Hardt >> Cc: specs@openid.net >> Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) >> >> # Proposal >> # >> # Modify 8.1 to: >> # ... >> # >> # The form field's "name" attribute MUST have the value # >> "openid_identifier" as to allow User Agents to automatically >> prefill # > >> the End User's Identifier when visiting a Relying Party. >> >> This should be a SHOULD, not a MUST. >> >> -- >> Jonathan Daugherty >> JanRain, 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
RE: PROPOSAL: OpenID Form Clarification (A.4)
In my view, it is because the authentication protocol can proceed with no problems if this field is named something different. As things won't break, as far as the protocol is concerned, this would also be nearly impossible to enforce or justify. It is easy to tell a developer to fix how they're creating signatures, authentication transactions do not complete, but enforcing convention around form fields seems difficult at best. I'd imagine that if a RP does not follow this recommendation then a rich client should treat it as not being a relying party. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 11:35 PM To: Recordon, David Cc: Jonathan Daugherty; specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) Why SHOULD rather then MUST? [1] What valid reason is there for an RP to not have that field name? [1] http://www.ietf.org/rfc/rfc2119.txt -- Dick On 18-Oct-06, at 1:28 PM, Recordon, David wrote: > Agreed, just like the spec already says "The form field's "name" > attribute SHOULD have the value "openid_identifier" as to allow User > Agents to automatically prefill the End User's Identifier when > visiting a Relying Party." > > I'm all for this feature, as well as even identifying the form itself, > though don't see how it should be a MUST over a SHOULD for a Relying > Party. > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jonathan Daugherty > Sent: Wednesday, October 18, 2006 2:33 PM > To: Dick Hardt > Cc: specs@openid.net > Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) > > # Proposal > # > # Modify 8.1 to: > # ... > # > # The form field's "name" attribute MUST have the value # > "openid_identifier" as to allow User Agents to automatically prefill # > the End User's Identifier when visiting a Relying Party. > > This should be a SHOULD, not a MUST. > > -- > Jonathan Daugherty > JanRain, 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
Re: PROPOSAL: OpenID Form Clarification (A.4)
We are the counter-example at NetMesh. The field names in our code precede OpenID and its conventions, and we would like to keep the names of our fields without running afoul of the OpenID spec. Granted, it wouldn't be terrible if we had to change the name of our fields, but then, I think this is exactly why this kind of thing should be a SHOULD not a MUST. I agree with David on this, naturally. On Oct 18, 2006, at 20:34, Dick Hardt wrote: Why SHOULD rather then MUST? [1] What valid reason is there for an RP to not have that field name? [1] http://www.ietf.org/rfc/rfc2119.txt -- Dick On 18-Oct-06, at 1:28 PM, Recordon, David wrote: Agreed, just like the spec already says "The form field's "name" attribute SHOULD have the value "openid_identifier" as to allow User Agents to automatically prefill the End User's Identifier when visiting a Relying Party." I'm all for this feature, as well as even identifying the form itself, though don't see how it should be a MUST over a SHOULD for a Relying Party. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Daugherty Sent: Wednesday, October 18, 2006 2:33 PM To: Dick Hardt Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) # Proposal # # Modify 8.1 to: # ... # # The form field's "name" attribute MUST have the value # "openid_identifier" as to allow User Agents to automatically prefill # the End User's Identifier when visiting a Relying Party. This should be a SHOULD, not a MUST. -- Jonathan Daugherty JanRain, 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 Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
Why SHOULD rather then MUST? [1] What valid reason is there for an RP to not have that field name? [1] http://www.ietf.org/rfc/rfc2119.txt -- Dick On 18-Oct-06, at 1:28 PM, Recordon, David wrote: > Agreed, just like the spec already says "The form field's "name" > attribute SHOULD have the value "openid_identifier" as to allow User > Agents to automatically prefill the End User's Identifier when > visiting > a Relying Party." > > I'm all for this feature, as well as even identifying the form itself, > though don't see how it should be a MUST over a SHOULD for a Relying > Party. > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jonathan Daugherty > Sent: Wednesday, October 18, 2006 2:33 PM > To: Dick Hardt > Cc: specs@openid.net > Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) > > # Proposal > # > # Modify 8.1 to: > # ... > # > # The form field's "name" attribute MUST have the value # > "openid_identifier" as to allow User Agents to automatically prefill # > the End User's Identifier when visiting a Relying Party. > > This should be a SHOULD, not a MUST. > > -- > Jonathan Daugherty > JanRain, 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
RE: PROPOSAL: OpenID Form Clarification (A.4)
Agreed, just like the spec already says "The form field's "name" attribute SHOULD have the value "openid_identifier" as to allow User Agents to automatically prefill the End User's Identifier when visiting a Relying Party." I'm all for this feature, as well as even identifying the form itself, though don't see how it should be a MUST over a SHOULD for a Relying Party. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Daugherty Sent: Wednesday, October 18, 2006 2:33 PM To: Dick Hardt Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) # Proposal # # Modify 8.1 to: # ... # # The form field's "name" attribute MUST have the value # "openid_identifier" as to allow User Agents to automatically prefill # the End User's Identifier when visiting a Relying Party. This should be a SHOULD, not a MUST. -- Jonathan Daugherty JanRain, 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
RE: PROPOSAL: OpenID Form Clarification (A.4)
Agreed, it is currently worded "The form field's "name" attribute SHOULD have the value "openid_identifier" as to allow User Agents to automatically prefill the End User's Identifier when visiting a Relying Party.". A RP not doing this does not break the protocol itself. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Daugherty Sent: Wednesday, October 18, 2006 2:33 PM To: Dick Hardt Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) # Proposal # # Modify 8.1 to: # ... # # The form field's "name" attribute MUST have the value # "openid_identifier" as to allow User Agents to automatically prefill # the End User's Identifier when visiting a Relying Party. This should be a SHOULD, not a MUST. -- Jonathan Daugherty JanRain, 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
Re: PROPOSAL: OpenID Form Clarification (A.4)
# Proposal # # Modify 8.1 to: # ... # # The form field's "name" attribute MUST have the value # "openid_identifier" as to allow User Agents to automatically prefill # the End User's Identifier when visiting a Relying Party. This should be a SHOULD, not a MUST. -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
PROPOSAL: OpenID Form Clarification (A.4)
Motivating Use Case: Rich User Agents (RUA) can enhance the OpenID user experience. RUAs are either browser that have been extended, or that have an extension that supports OpenID. In order for the RUA to detect that a site supports OpenID, it sees a form with a single input with a "name" of openid_identiifier. The RUA can then look at the action and post the data directly to the RP. Proposal Modify 8.1 to: ... The form field's "name" attribute MUST have the value "openid_identifier" as to allow User Agents to automatically prefill the End User's Identifier when visiting a Relying Party. This also allows Rich User Agents to detect the site supports OpenID and to invoke a rich interface. Relying Party's that are implementing check_immediate MUST include an "action" in the form so that user agents that do not support JavaScript will still be able to work, and Rich User Agents will be able to directly submit data to the Relying Party. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
