PROPOSAL: OpenID Form Clarification (A.4)

Dick Hardt dick at sxip.com
Thu Oct 19 04:44:03 UTC 2006


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