OpenID Provider Delegation Extenstion - Draft 1

Abstract

This document specifies an extension to OpenID Authentication 2.0 Discovery. This extension allows 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.

This extension specifies three categories under which Identifier authority can be delegated: Service, Class, and Domain. For example, an Identifier might specify a different authoritative OP depending on the Service (e.g., OpenID 2.0, OAuth, and 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, users will be able to utilize the best OP for any particular OpenID transaction.

Editorial Note

To provide feedback on this draft, join the OpenID specs mailing list at http://openid.net/mailman/listinfo/specs . For more general information about this protocol, please consult the openid wiki at http://wiki.openid.net/OP-Delegation .

Table of Contents

1.  Definitions
    1.1.  Requirements Notation
    1.2.  Conventions
    1.3.  Terminology
2.  Extension Overview
3.  OP Delineation Methods
    3.1.  Delineation by "Service"
    3.2.  Delineation by "Class"
    3.3.  Delineation by "RP Domain"
4.  Rules for Determining an Authoritative OP
5.  Non-Normative Examples
6.  Relax-NG Schema for OPD Elements
7.  Normative References
§  Author's Address

1.  Definitions

1.1.  Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” 1997.) .

1.2.  Conventions

This extension specifies the following URI to identify XRD <Service> elements that utilize this extension:

http://specs.openid.net/extensions/pde/1.0

1.3.  Terminology

The following terms are defined in [OpenID Authentication 2.0] (specs@openid.net, “OpenID Authentication 2.0,” 2007.) :

• Identifier
• OpenID Provider (OP)
• Relying Party (RP)
• User-Agent

tbd

more here.

2.  Extension Overview

1. As part of OpenID Auth 2.0 Discovery, the process of locating an OP Identifier always results in an XRDS document.
2. This resulting XRDS document yields an OP Identifier that is an xrd:Service element with an xrd:Type tag whose text content is "http://specs.openid.net/auth/2.0/server" and an xrd:URI tag whose text content is the OP Endpoint URL.
3. This extension specifies several new xrd:Type elements that allow an RP to determine the correct OP based on certain characteristics of the OpenID transaction.
4. Based on various factors such as the domain of the Relying Party, the OpenID Service Type being requested, and/or the ClassF of service being requested, the RP can intelligently determine which OP Endpoint to utilize out of a list of one or more OP's specified in the XRDS document for a particular Identifier.

3.  OP Delineation Methods

The following sections detail the methods by which an RP can determine the authoritative OP for a particular OpenID Identifier, given an XRDS document that defines multiple authoritative OP's.

3.1.  Delineation by "Service"

A Relying Party can perform OpenID Authentication as part of a myriad of XRD <Service> types. For example, an OpenID transaction might be part of an OAuth transaction, or it might be a part of a transaction defined by some other specification or application. "Service" delineation types are defined by a Service Type URI, which is service implementation defined.

For example, the following XRD indicates that RP's wishing to utilize OpenID Authentication in the context of the proposed OpenID+OAuth extension must receive an authentication assertion from OP2, while traditional OpenID assertions MUST be received from OP1. Notice that for the Service type "http://specs.openid.net/extensions/oauth/1.0", this configuration requires that an assertion from OP1 MUST not be used in order to prove that an end user controls the Identifier -- only assertions from OP2 can be used for that particular Service type.

Example:

<xrd>
  <Service>
    <Type>http://specs.openid.net/auth/2.0/signon</Type>
    <URI>https://op1.example.com/server</URI>
  </Service>
  <Service>
    <Type>http://specs.openid.net/extensions/oauth/1.0</Type>
    <URI>https://op2.example.com/server</URI>
  </Service>
</xrd>

It is important to note that this delineation section merely clarifies how current OpenID Auth 2.0 Discovery SHOULD work today--it does not define any new capabilities.

3.2.  Delineation by "Class"

As part of the [PAPE 1.0] (specs@openid.net, “Provider Authentication Policy Extension 1.0,” 2007.) ,a Relying Party can request that an OP authenticate the User via myriad security schemes--for example, in a phishing-resistant way. This is considered to be one "class" of OpenID authentication. Another class of authentication could be related to the type of service that the authenticating RP provides, such as a banking or healthcare-related service.

Class-level OP delegation allows OpenID users to control which OP will service various classes of OpenID enabled transactions, depending on the capabilities of various OPs in the identity marketplace. Additionally, class advertisements will provide RP's with a hint during OpenID Discovery concerning the most appropriate OP to meet the requirements of an OpenID transaction. These requirements might be related to security policies, up-time requirements, or a myriad of other requirements that the community defines. "Class" delineation types are defined by a Type URI, which is outside the scope of this specification.

As an example, the following XRD instructs RP's using OpenID for a 'banking' transaction to authenticate with OP2, while RP's using OpenID for every other class of transaction should use OP1.

Example:

<xrd>
  <Service>
    <Type>http://specs.openid.net/auth/2.0/signon</Type>
    <URI>https://op1.example.com/server</URI>
    <opd:Class priority="1">
      <Type>http://banking.org/openid/policy/financial</Type>
      <URI>https://op2.example.net/server</URI>
    </opd:Class>
  </Service>
</xrd>

3.3.  Delineation by "RP Domain"

End-users may wish to utilize a particular OP for certain Relying Parties, while using a different OP for other Relying Parties. For example, a user may wish to provide a "white list" of high value web-sites that the user desires to protect more fully. In this case, RP's on this user-defined whitelist MUST only allow access to the user if the RP receives valid OpenID assertions from the appropriate OP--i.e., an OP that the user trusts more than another OP that the user only mildly trusts.

OPD <DomainMatch> delineation element values are regular expressions, and can be as simple as '*.com', which indicates that all RP's in the '.com' gTLD should utilize a particular OP when performing OpenID authentication.

As an example, the following XRD indicates that RP's in the 'mybank.com' domain should utilize OP2 to verify the OpenID identifier, whereas all other RP's should use OP1.

Example:

<xrd>
  <Service>
    <Type>http://specs.openid.net/auth/2.0/signon</Type>
    <URI>https://op1.example.com/server</URI>
  </Service
  <Service priority="1">
    <Type>http://specs.openid.net/extensions/pde/1.0</Type>
    <opd:MatchRules>
      <opd:DomainMatch>*.mybank.com</opd:DomainMatch>
    </opd:MatchRules>
    <URI>https://op2.example.net/server</URI>
  </Service>
</xrd>

4.  Rules for Determining an Authoritative OP

1. If an RP supports this extension, then any elements in the "opd" namespace, or contained within an element with the "opd" namespace, MUST take precedence over elements defined by OpenID Authentication 2.0 Discovery.
2. Identical XRD elements within the "opd" namespace should be treated according to priority rules defined in [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) , unless an OpenID Discovery extension <Type> is present, specifying an alternate set of precedence rules.
3. When more than one <opd:DomainMatch> element is encountered, then any of these elements SHALL trigger a match, indicating that an RP MUST consider the associated URI to be authoritative for a particular identifier.
4. When more than one <opd:ClassMatch> element is encountered, then all of these elements taken together SHALL trigger a match, indicating that an RP MUST consider the associated URI to be authoritative for a particular identifier.

5.  Non-Normative Examples

Example 1: The following example illustrates the use of combinatory delgation mechanisms by indicating that RP's in the 'mybank.com' domain that are using OpenID+OAuth and require OP authentication with a PAPE policy of "multi-factor-physical" MUST utilize OP2. All other RP requests not meeting these three criteria MUST utilize OP1 as the authoritative OP.

<xrd>
  <Service priority="1">
    <Type>http://specs.openid.net/auth/2.0/signon</Type>
    <URI>https://op1.example.com/server</URI>
  </Service>
  <Service priority="1">
    <Type>http://specs.openid.net/extensions/pde/1.0</Type>
    <opd:MatchRules>
      <opd:ServiceMatch>http://specs.openid.net/extensions/oauth/1.0</opd:ServiceMatch>
      <opd:ClassMatch>http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical</opd:ClassMatch>
      <opd:DomainMatch>*.mybank.com</opd:DomainMatch>
    </opd:MatchRules>
    <URI>https://op2.example.net/server</URI>
  </Service>
</xrd>

Example 2: The following example illustrates the use of combinatory delgation mechanisms by indicating that RP's in the 'gmail.com' or 'google.com' domain MUST utilize OP3, while all other RP requests MUST utilize OP1.

<xrd>
  <Service priority="1">
    <Type>http://specs.openid.net/auth/2.0/signon</Type>
    <URI>https://op1.example.com/server</URI>
  </Service>
  <Service priority="1">
    <Type>http://specs.openid.net/extensions/pde/1.0</Type>
    <opd:MatchRules>
      <opd:DomainMatch>*.gmail.com</opd:DomainMatch>
      <opd:DomainMatch>*.google.com</opd:DomainMatch>
    </opd:MatchRules>
    <URI>https://op3.example.net/server</URI>
  </Service>
</xrd>

6.  Relax-NG Schema for OPD Elements

7. Normative References

Author's Address