OpenID 1.2 Extensions Proposal

[Johannes Ernst]

What's unclear to me is why OpenID needs its own extensibility  
mechanism in the XRDS file -- isn't that what the XRDS file is  
supposed to be all about?

Why not simply declare it as another Yadis service, like this:

   <Service priority="20">
     <Type>http://openid.net/signon/1.2</Type>
     <URI>http://www.myopenid.com/server</URI>
   </Service>
   <Service priority="20">
     <Type>http://openid.net/extensions/sreg/1.0</Type>
     <URI>http://www.myopenid.com/server</URI>
   </Service>

or maybe even better, like this:

   <Service priority="20">
     <Type>http://openid.net/signon/1.2</Type>
     <Type>http://openid.net/extensions/sreg/1.0</Type>
     <URI>http://www.myopenid.com/server</URI>
   </Service>

Sounds simpler to me (no Yadis parser extensions needed!), and more  
consistent with the architecture.

On Apr 4, 2006, at 20:19, David Recordon wrote:

> So overall I think this looks good.  I think it is important in the  
> OpenID spec to define how we deal with extensions and YADIS for the  
> sake of being clear.  As Simple Registration showed, it is already  
> possible to create extensions to OpenID with the current 1.1 spec.
>
> So, from my understanding, 1.2 should do three things:
> 1) Formalize additional openid.* fields in a consumer's request and  
> server's response (should be easy to base off of SREG)
> 2) Explain what an OpenID service block looks like in a YADIS  
> discovery file
> 3) Replace OpenID discovery and delegation with YADIS, though  
> preserve the recommendation of backwards compatibility
>
> This sound right?  Seems like you guys have hit 1 and 2 so we just  
> need to deal with 3.  Want to make sure people agree this is the  
> correct scope for a 1.2 spec first though.
>
> Thanks for working on this,
> --David
>
> On Apr 4, 2006, at 1:14 PM, Jonathan Daugherty wrote:
>> We (of JanRain, Inc.) would like to propose the addition of OpenID
>> Extensions to the OpenID 1.2 specification.  The following is a
>> summary of the applicable parts of the simple registration extension
>> specification.  Qualifiers like "must" are intentional (RFC 2119).
>>
>> An extension is a specified set of query arguments prefixed with
>> "openid." and a specified namespace[1].  The consumer includes the
>> appropriate extension fields in a checkid_* request (according to the
>> extension's specification) and gets response fields from the  
>> server in
>> the id_res response.  Whether the response fields are included will
>> depend on the behavior of a given extension.  How the relying party
>> should handle extra or nonexistent fields should be specified by the
>> extension.
>>
>> Extension fields returned by the server must be signed using the
>> OpenID signing machinery.  In particular,
>>
>>  - The openid.signed field list must include extension field names
>> along with OpenID field names[2].
>>
>>  - The openid.sig signature will cover the extension fields returned
>> by the server in addition to the usual OpenID data.
>>
>>  - Since the extension fields are signed, they must be returned to  
>> the
>> server for verification during a check_authentication request.
>>
>> When using OpenID with Yadis, zero or more <openid:Extension>  
>> elements
>> should be included in the XRDS resource Service elements to indicate
>> the extensions supported by the service.  An <openid:Extension>
>> element should contain a URI which uniquely identifies the extension,
>> and the extension in question should specify this and other such  
>> URIs.
>> For example:
>>
>>   <Service priority="20">
>>     <Type>http://openid.net/signon/1.2</Type>
>>     <URI>http://www.myopenid.com/server</URI>
>>     <openid:Extension>
>>       http://openid.net/extensions/sreg/1.0
>>     </openid:Extension>
>>   </Service>
>>
>> Lastly, when using Yadis and OpenID, the Yadis relying party SHOULD
>> respect the Service elements' priority values regardless of which
>> extensions they provide.
>>
>> Please let us know what you think.  We'll be happy to work with David
>> et al. to come up with specification-strength language, if need be.
>>
>> [1] For example, if the extension namespace is "profile", the full
>>     extension prefix for any extension field must be
>>     "openid.profile.".
>>
>> [2] When an extension field appears in the openid.signed list, the
>>     field name must lack the "openid." prefix, as is already
>>     specified.
>>
>> -- 
>>   Jonathan Daugherty
>>   JanRain, Inc.

Johannes Ernst
NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20060404/6c51d2b4/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst