OpenID Provider MultiAuth Extension - Draft 2

Abstract

This document specifies an extension to OpenID Authentication 2.0 Discovery.

This extension allows a Claimed Identifier to specify that an RP should receive valid OpenID Authentication assertions from at least two different OP's before the RP may grant access to protected resources.

OpenID Authentication 2.0 currently only specifies a single authoritative OP for a given Claimed Identifier. This restriction poses a modest security risk from the perspective that a rogue OP (or a rogue employee at an OP) might surreptitiously operate on behalf of a user without that user's knowledge or consent. By providing OpenID users with the ability to prevent this type of attack, users will be able to mitigate a common concern with the OpenID protocol as it stands today.

Table of Contents

1.  Definitions
    1.1.  Requirements Notation
    1.2.  Terminology
2.  Extension Overview
3.  Extensions to OpenID XRD-Based Discovery
    3.1.  MultiAuth Claimed Identifier Element
    3.2.  Precedence
4.  Extensions to OpenID HTML-Based Discovery
    4.1.  Unlimited HTML-Based Discovery Authentication Endpoints
    4.2.  Precedence
5.  Security Considerations
    5.1.  Preventing Attacks
        5.1.1.  Rogue OP Attack
        5.1.2.  Unintended SingleAuth
Appendix A.  Non-Normative Examples
Appendix A.1.  Two-Headed MultiAuth (XRDS)
Appendix A.2.  Two-Headed MultiAuth (HTML)
Appendix A.3.  Three-Headed MultiAuth (XRDS)
Appendix A.4.  Three-Headed MultiAuth (HTML)
Appendix A.5.  MultiAuth Precendence (XRDS)
Appendix A.6.  MultiAuth Precendence (HTML)
6.  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.  Terminology

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

Discovery

OpenID Provider (OP)

Relying Party (RP)

User-Agent

Identifier

Claimed Identifier

The following terms are defined by this extension:

SingleAuth Claimed Identifier:

A Claimed Identifier that has only a single authoritative OP.

MultiAuth Claimed Identifier:

A Claimed Identifier that has two or more authoritative OP's, whereby all OP's must provide a valid authentication assertion in order for an RP to grant access to protected resources on behalf of the Claimed Identifier.

2.  Extension Overview

1. Discovery is performed on an OpenID Claimed Identifier resulting in either an XRDS or HTTP document, either of which will specify information to indicate that the Claimed Identifier supports this extension (see section 3 and 4 below for specific details).
   
   
2. Discovery documents supporting this extension MUST indicate at least two OpenID Endpoint URL's, each of which has a correctly populated 'local_id' attribute representing the "OP-Local Identifier" for a given OP Endpoint.
   
   
3. Relying Parties utilizing this information and supporting this extension MUST perform OpenID Authentication on ALL specified OpenID endpoints (using the specified 'local_id') before granting access to RP-protected resources.
   
   
4. If OpenID Authentication is successful on ALL specified OP Endpoints (using the associated Claimed Identifier for each OP), then OpenID Authentication SHOULD proceed per usual.
   
   
5. If OpenID Authentication is not successful on ALL specified OP Endpoint's (using the associated Claimed Identifier for each OP), then OpenID Authentication SHOULD fail, unless alternate OpenID Authentication mechanisms are specified in the XRDS/HTTP Discovery documents.
   
   

3.  Extensions to OpenID XRD-Based Discovery

Section 7.3.2.1 of OpenID Authentication 2.0 specifies a several OpenID Service Elements that MAY be present in a discovered XRDS document. This section details an additional OpenID Service Element to support OP MultiAuth.

3.1.  MultiAuth Claimed Identifier Element

A MultiAuth Claimed Identifier Element is an <xrd:Service> element with the following information:

An <xrd:Type> tag whose text content is "http://specs.openid.net/auth/2.0/signon/opmae".

An <xrd:URI> tag whose text content is the Endpoint URL of the first OP, with a 'local_id' attribute (optional) whose value is the OP-Local Identifier.

An <xrd:URI> tag whose text content is the Endpoint URL of the second OP, with a 'local_id' attribute (optional) whose value is the OP-Local Identifier.

MultiAuth Claimed Identifier Elements MAY specify more than two <xrd:URI> elements in order to mandate that any number of OP's validly assert for a particular Claimed Identifier.

3.2.  Precedence

MultiAuth Claimed Identifier Elements MAY be used in tandem with, or in place of, the Claimed Identifier Element defined in OpenID Authentication section 7.3.2.1.2.

When both MultiAuth and SingleAuth Claimed Identifiers exist in the same XRDS document, the MultiAuth Claimed Identifiers MUST take precedence over the SingleAuth Claimed Identifiers. Otherwise, the precedence 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,” .) are to be applied.

4.  Extensions to OpenID HTML-Based Discovery

Section 7.3.3 of OpenID Authentication 2.0 specifies that, in order to support HTML-Based Discovery, several LINK elements MUST be present in the HEAD element of a the HTML document at the URL specified by the Claimed Identifier.

In order to specify HTML-Based MuliAuth discovery, the following must likewise be present within the HEAD element of the Claimed Identifier's HTML document:

A LINK element MUST be included with attributes "rel" set to "openid2.provider.multiauth.1" and "href" set to an OP Endpoint URL

A LINK element MUST be included with attributes "rel" set to "openid2.provider.multiauth.2" and "href" set to an OP Endpoint URL

A LINK element MAY be included with attributes "rel" set to "openid2.local_id.multiauth.1" and "href" set to the end user's OP-Local Identifier

A LINK element MAY be included with attributes "rel" set to "openid2.local_id.multiauth.2" and "href" set to the end user's OP-Local Identifier

The protocol version when HTML MultiAuth discovery is performed is: "http://specs.openid.net/auth/2.0/signon/opmae".

4.1.  Unlimited HTML-Based Discovery Authentication Endpoints

This specification allows a Claimed Identifier to specify that an RP receive valid authentication assertions from more than two MultiAuth OP Endpoints in order to grant an end-user access to a protected resource. This is accomplished by specifying a number greater than '2' in both the 'provider' and the 'local_id' LINK elements defined above.

For example, an HTML document with a HEAD element containing the above LINK elements could additionally specify a third LINK element containing a 'rel' value of 'openid2.multiauth.provider3', and an optional 'local_id' LINK element with a value of 'openid.local_id3'. This would indicate that an RP SHOULD receive positive authentication assertions from all three OP's before granting access to RP-protected resources.

4.2.  Precedence

MultiAuth LINK elements MAY be used in tandem with, or in place of, the SingleAuth LINK elements defined in OpenID Authentication section 7.3.3.

When both MultiAuth and SingleAuth LINK elements are defined in the same HTML document, the MultiAuth LINK elements MUST take precedence over the SingleAuth LINK elements.

5.  Security Considerations

5.1.  Preventing Attacks

5.1.1.  Rogue OP Attack

OpenID Authentication 2.0 currently only specifies a single authoritative OP for a given Claimed Identifier. This restriction poses a modest security risk from the perspective that a rogue OP (or a rogue employee at an OP) might surreptitiously operate on behalf of a user without that user's knowledge or consent. By providing OpenID users with the ability to prevent this type of attack, users will be able to mitigate this risk of the OpenID protocol as it stands today.

5.1.2.  Unintended SingleAuth

Because of the precedence rules outlined in this extension, end-users should be careful not to define SingleAuth discovery meta-data if MultiAuth is the ONLY allowed mechanism of OpenID Authentication for a particular Claimed Identifier.

Defining fall-back SingleAuth discovery meta-data could allow a rogue-OP attacker to trick an RP into granting access to a protected resource with only a single valid OpenID assertion, likely from the Rogue-OP.

Appendix A.  Non-Normative Examples

Appendix A.1.  Two-Headed MultiAuth (XRDS)

The following example uses XRDS-based Discovery mechanisms to indicate that an RP MUST receive a valid OpenID assertion from both OP1 and OP2 before granting the User-Agent access to any protected resources on behalf of the Claimed Identifier.

Example:

<xrd>
  <Service xmlns="xri://$xrd*($v*2.0)">
    <Type>http://specs.openid.net/auth/2.0/signon/opmae</Type>
    <URI local_id="http://user.example.com">https://op1.example.com/server</URI>
    <URI local_id="http://user.example.net">https://op2.example.net/server</URI>
  </Service>
</xrd>

Appendix A.2.  Two-Headed MultiAuth (HTML)

The following example uses HTML-based Discovery mechanisms to indicate that an RP MUST receive a valid OpenID assertion from both OP1 and OP2 before granting the User-Agent access to any protected resources on behalf of the Claimed Identifier.

Example:

<link rel="openid2.provider.multiauth.1 openid.server"
      href="https://op1.example.com/server"/>
<link rel="openid2.local_id.multiauth.2 openid.delegate"
      href="http://user.example.com"/>

<link rel="openid2.provider.multiauth.2 openid.server"
      href="https://op2.example.net/server"/>
<link rel="openid2.local_id.multiauth.2 openid.delegate"
      href="http://user.example.net"/>

Appendix A.3.  Three-Headed MultiAuth (XRDS)

The following example uses XRDS-based Discovery mechanisms to indicate that an RP MUST receive a valid OpenID assertion from OP1, OP2, and OP3 before granting the User-Agent access to any protected resources on behalf of the Claimed Identifier.

Example:

<xrd>
  <Service xmlns="xri://$xrd*($v*2.0)">
    <Type>http://specs.openid.net/auth/2.0/signon/opmae</Type>
    <URI local_id="http://user.example.com">https://op1.example.com/server</URI>
    <URI local_id="http://user.example.net">https://op2.example.net/server</URI>
    <URI local_id="http://user.example.org">https://op3.example.org/server</URI>
  </Service>
</xrd>

Appendix A.4.  Three-Headed MultiAuth (HTML)

The following example uses HTML-based Discovery mechanisms to indicate that an RP MUST receive a valid OpenID assertion from OP1, OP2, and OP3 before granting the User-Agent access to any protected resources on behalf of the Claimed Identifier.

Example:

<link rel="openid2.provider.multiauth.1 openid.server"
      href="https://op1.example.com/server"/>
<link rel="openid2.local_id.multiauth.1 openid.delegate"
      href="http://user.example.com"/>

<link rel="openid2.provider.multiauth.2 openid.server"
      href="https://op2.example.net/server"/>
<link rel="openid2.local_id.multiauth.2 openid.delegate"
      href="http://user.example.net"/>

<link rel="openid2.provider.multiauth.3 openid.server"
      href="https://op3.example.org/server"/>
<link rel="openid2.local_id.multiauth.3 openid.delegate"
      href="http://user.example.org"/>

Appendix A.5.  MultiAuth Precendence (XRDS)

The following example uses XRDS-based Discovery mechanisms to illustrate that MultiAuth should be used instead of the SingleAuth, despite the presence of both.

Example:

<xrd>
  <Service xmlns="xri://$xrd*($v*2.0)">
    <Type>http://specs.openid.net/auth/2.0/signon/opmae/</Type>
    <URI local_id="http://user.example.com">https://op1.example.com/server</URI>
    <URI local_id="http://user.example.net">https://op2.example.net/server</URI>
  </Service>

  <Service xmlns="xri://$xrd*($v*2.0)">
    <Type>http://specs.openid.net/auth/2.0/signon</Type>
    <URI>https://www.exampleprovider.com/endpoint/</URI>
    <LocalID>https://exampleuser.exampleprovider.com/</LocalID>
  </Service>

</xrd>

Appendix A.6.  MultiAuth Precendence (HTML)

The following example uses HTML-based Discovery mechanisms to illustrate that MultiAuth should be used instead of the SingleAuth, despite the presence of both.

Example:

<link rel="openid2.provider.multiauth.1 openid2.provider. openid.server"
      href="https://op1.example.com/server"/>
<link rel="openid2.local_id.multiauth.2 openid2.local_id openid.delegate"
      href="http://user.example.com"/>

<link rel="openid2.provider.multiauth.2 openid.server"
      href="https://op2.example.net/server"/>
<link rel="openid2.local_id.multiauth.2 openid.delegate"
      href="http://user.example.net"/>

6. Normative References

Author's Address