Services and Metadata Discovery Coordination Working Group (Discovery)

Charter Proposal

In accordance with the OpenID Foundation IPR policies and procedures this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the proposed charter is below (still liable to change during this feedback period). 

I. Name

Services and Metadata Discovery Coordination Working Group (Discovery) 

II. Statement of Purpose

Produce a document describing the OpenID discovery workflow, updating the current mechanism to describe how to use OASIS specifications for discovery, to be drafted by the OASIS XRI TC. The intention is that the document will be incorporated as part of some future version of the OpenID Authentication spec. 

III. Scope

Produce a document describing the use of OASIS discovery specifications as formulated by the OASIS XRI TC, for normative application by all other OpenID specifications. Produce a document describing the recommended migration of services discovery from the Yadis 1.0 specification to the discovery specifications currently being developed by the OASIS XRI TC. All types of identifiers addressed by OASIS XRI TC discovery (XRD 1.0) are within scope of this WG. Publish a list of service and resource types supported by the discovery mechanism. 

IV. Specifications

OpenID Discovery, including a sub-spec for Trusted OpenID Discovery, and a best-practices guidance document for migration. 

V. Anticipated audience

All those interested in the OpenID specifications. 

VI. Language of business

English. 

VII. Method of work

Mailing list discussion. Posting of intermediate drafts in the OpenID Wiki. Virtual conferencing on an ad-hoc basis. 

VIII. Basis for completion of the activity

The discovery document is final and all deliverables have been incorporated into the OpenID Authentication spec, perhaps by reference. 

Background Information 

I. Related Work

XRD 1.0 spec, being drafted by the OASIS XRI TC. 

II. Initial Membership

• John Bradley, =jbradley, jbradley@mac.com
• Brian Eaton, beaton@google.com, Google, Inc.
• Johannes Ernst, jernst@netmesh.us, NetMesh. (editor)
• Eran Hammer-Lahav, eran@hueniverse.com, Yahoo! Inc.
• Breno de Medeiros, breno@google.com, Google, Inc. (editor)
• David Recordon, david@sixapart.com, Six Apart Ltd.
• Drummond Reed, =drummond, drummond.reed@cordance.net, Cordance
• Nat Sakimura, n-sakimura@nri.co.jp, NRI
• David Fuelling, sappenin@gmail.com/david.fuelling@cordance.net 
• Larry Drebes, ltd@janrain.com, Janrain 

III.  Issues/Ideas for Discussion

1. Identifier Makeup (i.e., Allowed OpenID Identifiers)

   With the onset of XRD 1.0, it is anticipated that the flow of OpenID Discovery will be something along the lines of: 1.) Normalize the Identifier; 2.) Utilize XRD 1.0 to perform discovery on the Identifier; 3.) End-up with the Identifier's authoritative XRD document that descrbies meta-data about the Identifier (see here for more details about the anticpated format of an XRD document).  Because of this, it will no longer be necessary to restrict OpenID Identifiers to being URL's or XRI's (as the current OpenID Auth 2.0 spec defines).  In this new paradigm, any URI could be considered to be a valid OpenID Identifier, so long as an appropriate Discovery mechanism has been defined for OP's and RP's to perform Discovery on said Identifier.  

   For example, if an email address is to serve as an OpenID Identifier, then an associated specification must be defined to formalize how Discovery will be performed on this typs of identifier (recently, the webfinger protocol has been proposed to accomplish this). 

   Taking this one step further, it is feasible that an Identifier need not be a URI.  It is possible that the Identifier might be an IRI, or even generic string-text.  The only real requirement is that there exist a mechanism to perform OpenID Discovery on the Identifier (though one could make an argument for URI/IRI for some structure to the Identifier format).

   Related List Discussion: 

   1.) http://openid.net/pipermail/general/2009-June/009049.html

2. Identifier Abstraction 

   This issue is best summed-up From John Bradley (here): "The conflict between URLs and XRI has more to do with having multiple names that resolve to a single claimed_id where with URLs there is a one to one relationship.  I believe it was that impedance mismatch more than library complexity that prevented people from seeing any advantage to XRI.  The two identifier types also have different approaches to identifier recycling, and portability.  We need a single model and then fit the identifiers to it rather than trying to adapt the core to the identifiers in a piecemeal fashion."

   From David F.: "Could XRD solve this problem in a generic way, via the canonical-id/alias mechanism?  That is, an alias URL could resolve to an XRD with a different canonical URL at different points in time." 

3. Identifier Portabilty

   Once XRD is in-use, this WG should consider the notion of an XRD canonical-id that changes over time.  For example, in 2008 my XRD canonical-id might be "beth.google.com".  In 2009, doing XRD discovery on "beth.google.com" might result in an XRD document with an XRD Alias of "beth.google.com", but a canonical-id of "beth.facebook.com".  Since there's still a connection between my canonical-id and any alias, my "Identity" is still linked, even though I've switched providers.  It is unclear about how this might effect the "fragment" proposals in the Auth 2.0 spec (might this make them un-necessary?).

4. De-couple the DisplayId from the CanonicalId?

   Should the DisplayID (i.e., what's displayed at the OP and RP) be de-coupled from the CanonicalID?  

   From David F: "Consider specifying this as part of AX.  It's really not part of a core authentication protocol.  Instead, "displayName" is really an attribute that a user should control at the OP, and potentially even on a case-by-case basis." 

5. Identifier Control Framework?

   A question was proposed on the OpenID Mailing lists (see here) about whether or not OpenID Discovery was an "optional" thing, and in what cases it may or may not be optional.  Peter Williams voiced his opinion that Discovery should be considered optional, because otherwise we're making a Control Framework (control of Identifiers) out of something (Yadis, XRDS) that was meant to be merely providing meta-data in a "hint" capacity.

   This WG should clarify whether or not OpenID Discovery (and by proxy XRD) is intended to be a control framework, or if is merely intended to provide hints to an OP/RP.  Input from the XRD TC is reccommended.

6. Enabling two or more headed OP authentication

   The idea here is to allow an end-user to specify two (or more) OP's in the <Service> portion of their XRD so that an RP MUST receive auth assertions from both OP's before granting access to protected resources.  See a rough-draft idea proposal here: OP MultiAuth.  XRI Resolution 2.0 seems to currently prohibit this by default per section 4.3.3: "If two or more instances of the same element type have identical priority attribute values (including the null value), the consuming application SHOULD select one of the instances at random. This consuming application SHOULD NOT simply choose the first instance that appears in XML document order."  Thus, in order to indicate to the RP that both OP URI's should be used at the same time, an aditional <Type> element is used to signify that identical priority URI's should be used together for the purposes of OpenID Auth.  (Is this even a valid way to do this?) 

7. OP Delegation based upon various characteristics of an OpenID transaction

   The idea here is to allow an end-user to delegate authority over a particular OpenID Identifier to divergent OpenID Providers (OP's), depending on certain characteristics of a Relying Party and/or certain characteristics of an OpenID transaction.  For example, an Identifier might specify a different authoritative OP depending on the OpenID-related Service being employed (e.g., OpenID 2.0, OAuth, or others); the RP Domain (*.example.com); or a pre-defined service Class (e.g., one OP for single-factor auth, and another OP when two-factor Auth is required).   By providing OpenID Identifiers with the ability to specify multiple OP's based on particular characteristics of each OpenID transaction, end-users will be able to utilize the best OP for any particular OpenID transaction as they see fit (i.e., more control in the hands of the user).  See a rough-draft here: OP Delegation. 
8. Upgrade Path

   If the Discovery process for OpenID 2.1 is drastically different from the 2.0 version, then the WG needs to come to some kind of consensus about an upgrade path for the new spec.  For example, is 2.1 discovery going to be mandated?  Are 1.0, 1.1, 2.0 discovery mechanisms also going to be mandated, or will they just be "optional for legacy support", but not required by the core spec.   When the 2.0 spec was released, it took a long time for many OP's/RP's to start using the 2.0 version of OpenID because they were unable to justify the extra resource allocation of implementing the new spec.  The WG should provide guidance as to the justification for the new Discovery format, and what benefits could be derived from supporting the new format.

9. Discovery Extensions

   The OpenID Discovery specification should define ways for discovery to be extended by other services.  For example, the OAuth+OpenID specification may want to peform discovery in slighly different ways than regular OpenID Auth 2.1 does.  Likewise, ideas 1 and 2 above could be implemented as extensions to Discovery instead of being included in the main 2.1 Discovery specification. 

10. Voice Your Opinion

    Voice your opinion on the Jyte polling page (wiki version & Jyte Version)