OpenID 1.2 Extensions Proposal

[David Recordon]

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.