PROPOSAL: OpenID Form Clarification (A.4)

Dick Hardt dick at sxip.com
Thu Oct 19 16:54:35 UTC 2006


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: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