OpenID 1.2 Extensions Proposal

[Jonathan Daugherty]

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.