PROPOSAL: OpenID Form Clarification (A.4)

Chris Drake christopher at pobox.com
Thu Oct 19 16:45:50 UTC 2006


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:dick at sxip.com] 
RD> Sent: Thursday, October 19, 2006 1:04 AM
RD> To: Recordon, David
RD> Cc: Jonathan Daugherty; specs at 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:dick at sxip.com]
>> Sent: Thursday, October 19, 2006 12:44 AM
>> To: Recordon, David
>> Cc: Jonathan Daugherty; specs at 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:dick at sxip.com]
>>> Sent: Thursday, October 19, 2006 12:08 AM
>>> To: Recordon, David
>>> Cc: Jonathan Daugherty; specs at 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:dick at sxip.com]
>>>> Sent: Wednesday, October 18, 2006 11:35 PM
>>>> To: Recordon, David
>>>> Cc: Jonathan Daugherty; specs at 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: specs-bounces at openid.net
>>>>> [mailto:specs-bounces at openid.net] On

>>>>> Behalf Of Jonathan Daugherty
>>>>> Sent: Wednesday, October 18, 2006 2:33 PM
>>>>> To: Dick Hardt
>>>>> Cc: specs at 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 at openid.net
>>>>> http://openid.net/mailman/listinfo/specs
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>


RD> _______________________________________________
RD> specs mailing list
RD> specs at openid.net
RD> http://openid.net/mailman/listinfo/specs






More information about the specs mailing list