PROPOSAL: OpenID Form Clarification (A.4)

Recordon, David drecordon at verisign.com
Thu Oct 19 05:33:31 UTC 2006


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:dick at sxip.com] 
Sent: Thursday, October 19, 2006 1:04 AM
To: Recordon, David
Cc: Jonathan Daugherty; specs at 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: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
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>





More information about the specs mailing list