Hey Chris, I like your proposal. I would tweak the name:
<link rel="openid.entry" href="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:- > <link rel="openid.httpauth" href="http://my.rp.com/openid/blah.cgi"> > either on the page with the login <FORM>, 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 >>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> > > > RD> _______________________________________________ > RD> specs mailing list > RD> specs@openid.net > RD> http://openid.net/mailman/listinfo/specs > > > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs