- 1. Requirements Notation and Conventions
- 2. 用語
- 3. プロトコル概要
- 4. Data Formats
- 5. Communication Types
- 6. Generating Signatures
- 7. Initiation and Discovery
- 8. Establishing Associations
- 9. Requesting Authentication
- 10. Responding to Authentication Requests
- 11. Verifying Assertions
- 12. Extensions
- 13. Discovering OpenID Relying Parties
- 14. OpenID Authentication 1.1 Compatibility
- 15. Security Considerations
- Appendix A. Examples
- Appendix B. Diffie-Hellman Key Exchange Default Value
- Appendix C. Acknowledgements
- 16. Normative References
- Author's Address
1. Requirements Notation and Conventions 
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].
Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.
2. 用語
- 識別子(Identifier)
- 識別子は"http" か "https" URI, (通常本文書では"URL" と呼ぶ), ないしはXRI [XRI_Syntax_2.0]のことである。本文書は、異なる状況のもとで使用される様々な種類の識別子を定義している。
- User-Agent
- The end user's Web browser which implements HTTP/1.1 [RFC2616].
- 認証依存サイト(Relying Party)
- RP.エンドユーザがその識別子を管理していることの証明を希望しているWebアプリケーション。
- OpenIDプロバイダー(OpenID Provider)
- OP. エンドユーザがその識別子を制御していることの証明(Assertion)を認証依存サイト(RP)が依存しているOpenID認証(Authentication)サーバ
- OP終点URL(OP Endpoint URL)
- The URL which accepts OpenID Authentication protocol messages, obtained by performing discovery on the User-Supplied Identifier. This value MUST be an absolute HTTP or HTTPS URL.
- OP識別子(OP Identifier)
- An Identifier for an OpenID Provider.
- ユーザ提供識別子(User-Supplied Identifier)
- An Identifier that was presented by the end user to the Relying Party, or selected by the user at the OpenID Provider. During the initiation phase of the protocol, an end user may enter either their own Identifier or an OP Identifier. If an OP Identifier is used, the OP may then assist the end user in selecting an Identifier to share with the Relying Party.
- 主張識別子(Claimed Identifier)
- An Identifier that the end user claims to own; the overall aim of the protocol is verifying this claim. The Claimed Identifier is either:The Identifier obtained by normalizing the User-Supplied Identifier, if it was an URL. The CanonicalID, if it was an XRI.
- OP局所識別子(OP-Local Identifier)
- An alternate Identifier for an end user that is local to a particular OP and thus not necessarily under the end user's control.
3. プロトコル概要
The end user initiates authentication by presenting a User-Supplied Identifier to the Relying Party via their User-Agent.
After normalizing the User-Supplied Identifier, the Relying Party performs discovery on it and establishes the OP Endpoint URL that the end user uses for authentication. It should be noted that the User-Supplied Identifier may be an OP Identifier, as discussed in Section 7.3.1, which allows selection of a Claimed Identifier at the OP or for the protocol to proceed without a Claimed Identifier if something else useful is being done via an extension.
(optional) The Relying Party and the OP establish an association -- a shared secret established using Diffie-Hellman Key Exchange [RFC2631]. The OP uses an association to sign subsequent messages and the Relying Party to verify those messages; this removes the need for subsequent direct requests to verify the signature after each authentication request/response.
The Relying Party redirects the end user's User-Agent to the OP with an OpenID Authentication request.
The OP establishes whether the end user is authorized to perform OpenID Authentication and wishes to do so. The manner in which the end user authenticates to their OP and any policies surrounding such authentication is out of scope for this document.
The OP redirects the end user's User-Agent back to the Relying Party with either an assertion that authentication is approved or a message that authentication failed.
The Relying Party verifies the information received from the OP including checking the Return URL, verifying the discovered information, checking the nonce, and verifying the signature by using either the shared key established during the association or by sending a direct request to the OP.
4. Data Formats
4.1. Protocol Messages
The OpenID Authentication protocol messages are mappings of plain-text keys to plain-text values. The keys and values permit the full Unicode character set (UCS). When the keys and values need to be converted to/from bytes, they MUST be encoded using UTF-8 [RFC3629].
Messages MUST NOT contain multiple parameters with the same name.
Throughout this document, all OpenID message parameters are REQUIRED, unless specifically marked as OPTIONAL.
4.1.1. Key-Value Form Encoding
A message in Key-Value form is a sequence of lines. Each line begins with a key, followed by a colon, and the value associated with the key. The line is terminated by a single newline (UCS codepoint 10, "\n"). A key or value MUST NOT contain a newline and a key also MUST NOT contain a colon.
Additional characters, including whitespace, MUST NOT be added before or after the colon or newline. The message MUST be encoded in UTF-8 to produce a byte string.
Key-Value Form encoding is used for signature calculation and for direct responses to Relying Parties.
4.1.2. HTTP Encoding
When a message is sent to an HTTP server, it MUST be encoded using a form encoding specified in Section 17.13.4 of [HTML401]. Likewise, if the "Content-Type" header is included in the request headers, its value MUST also be such an encoding.
All of the keys in the request message MUST be prefixed with "openid.". This prefix prevents interference with other parameters that are passed along with the OpenID Authentication message. When a message is sent as a POST, OpenID parameters MUST only be sent in, and extracted from, the POST body.
All messages that are sent as HTTP requests (GET or POST) MUST contain the following fields:
openid.ns Value: "http://specs.openid.net/auth/2.0"
This particular value MUST be present for the request to be a valid OpenID Authentication 2.0 request. Future versions of the specification may define different values in order to allow message recipients to properly interpret the request.
If this value is absent or set to one of "http://openid.net/signon/1.1" or "http://openid.net/signon/1.0", then this message SHOULD be interpreted using OpenID Authentication 1.1 Compatibility mode.
openid.mode Value: Specified individually for each message type.
The "openid.mode" parameter allows the recipient of the message to know what kind of message it is processing. If "openid.mode" is absent, the party processing the message SHOULD assume that the request is not an OpenID message.
This model applies to messages from the User-Agent to both the Relying Party and the OP, as well as messages from the Relying Party to the OP.
4.1.3. Example
Non-normative
The following examples encode the following information:
| Key | Value |
| mode | error |
| error | This is an example message |
Key-Value Form encoded:
mode:error error:This is an example message
x-www-urlencoded, as in a HTTP POST body or in a URL's query string ([RFC3986] section 3):
openid.mode=error&openid.error=This%20is%20an%20example%20message
4.2. Integer Representations
Arbitrary precision integers MUST be encoded as big-endian signed two's complement binary strings. Henceforth, "btwoc" is a function that takes an arbitrary precision integer and returns its shortest big-endian two's complement representation. All integers that are used with Diffie-Hellman Key Exchange are positive. This means that the left-most bit of the two's complement representation MUST be zero. If it is not, implementations MUST add a zero byte at the front of the string.
Non-normative example:
| Base 10 number | btwoc string representation |
|---|---|
| 0 | "\x00" |
| 127 | "\x7F" |
| 128 | "\x00\x80" |
| 255 | "\x00\xFF" |
| 32768 | "\x00\x80\x00" |
5. Communication Types
5.1. Direct Communication
Direct communication is initiated by a Relying Party to an OP endpoint URL. It is used for establishing associations and verifying authentication assertions.
5.1.1. Direct Request
The message MUST be encoded as a POST body, as specified by Section 4.1.2.
All direct requests are HTTP POSTs, and so contain the required fields listed in Section 4.1.2.
5.1.2. Direct Response
The body of a response to a Direct Request consists of an HTTP Response body in Key-Value Form. The content-type of the response SHOULD be "text/plain".
All Key-Value form message MUST contain the following field:
ns Value: "http://specs.openid.net/auth/2.0"
This particular value MUST be present for the response to be a valid OpenID 2.0 response. Future versions of the specification may define different values in order to allow message recipients to properly interpret the request.
If this value is absent or set to one of "http://openid.net/signon/1.1" or "http://openid.net/signon/1.0", then this message SHOULD be interpreted using OpenID Authentication 1.1 Compatibility mode.
5.1.2.1. Successful Responses
A server receiving a valid request MUST send a response with an HTTP status code of 200.
5.1.2.2. Error Responses
If a request is malformed or contains invalid arguments, the server MUST send a response with a status code of 400. The response body MUST be a Key-Value Form message with the following fields:
ns As specified in Section 5.1.2.
error Value: A human-readable message indicating the cause of the error.
contact Value: (optional) Contact address for the administrator of the sever. The contact address may take any form, as it is intended to be displayed to a person.
reference Value: (optional) A reference token, such as a support ticket number or a URL to a news blog, etc.
The OP MAY add additional fields to this response.
5.2. Indirect Communication
In indirect communication, messages are passed through the User-Agent. This can be initiated by either the Relying Party or the OP. Indirect communication is used for authentication requests and authentication responses.
There are two methods for indirect communication: HTTP redirects and HTML form submission. Both form submission and redirection require that the sender know a recipient URL and that the recipient URL expect indirect messages, as specified in Section 4.1.2. The initiator of the communication chooses which method of indirect communication is appropriate depending on capabilities, message size, or other external factors.
All indirect messages arrive as HTTP requests, and so contain the required fields listed in Section 4.1.2.
5.2.1. HTTP Redirect
Data can be transferred by issuing a 302, 303, or 307 HTTP Redirect to the end user's User-Agent. The redirect URL is the URL of the receiver with the OpenID Authentication message appended to the query string, as specified in Section 4.1.2.
5.2.2. HTML FORM Redirection
A mapping of keys to values can be transferred by returning an HTML page to the User-Agent that contains an HTML form element. Form submission MAY be automated, for example by using JavaScript.
The <form> element's "action" attribute value MUST be the URL of the receiver. Each Key-Value pair MUST be included in the form as an <input> element. The key MUST be encoded as the "name" attribute and the value as the "value" attribute, such that the User-Agent will generate a message as specified in Section 4.1.2 when the form is submitted. The form MUST include a submit button.
5.2.3. Indirect Error Responses
In the case of a malformed request, or one that contains invalid arguments, the OpenID Provider MUST redirect the User-Agent to the "openid.return_to" URL value if the value is present and it is a valid URL.
openid.ns As specified in Section 4.1.2.
openid.mode Value: "error"
openid.error Value: A human-readable message indicating the cause of the error.
openid.contact Value: (optional) Contact address for the administrator of the sever. The contact address may take any form, as it is intended to be displayed to a person.
openid.reference Value: (optional) A reference token, such as a support ticket number or a URL to a news blog, etc.
The server MAY add additional keys to this response.
If the malformed or invalid message is received by the Relying Party, or "openid.return_to" is not present or its value is not a valid URL, the server SHOULD return a response to the end user indicating the error and that it is unable to continue.
6. Generating Signatures
The most common usage of an association is as a Message Authentication Code (MAC) key used to sign OpenID Authentication messages.
When generating MAC keys, the recommendations in [RFC1750] SHOULD be followed.
6.1. Procedure
To generate a message signature:
Determine the list of keys to be signed, according to the message to be signed (See Section 10.1). The list of keys to be signed MUST be part of the message. The list is stored with the key "openid.signed". The value is a comma-separated list of keys, with the "openid." prefix stripped. This algorithm is only capable of signing keys that start with "openid."
Iterate through the list of keys to be signed in the order they appear in "openid.signed" list. For each key, find the value in the message whose key is equal to the signed list key prefixed with "openid."
Convert the list of key/value pairs to be signed to an octet string by encoding with Key-Value Form Encoding.
Determine the signature algorithm from the association type. Apply the signature algorithm to the octet string.
6.2. Signature Algorithms
OpenID Authentication supports two signature algorithms:
HMAC-SHA1 - 160 bit key length ([RFC2104] and [RFC3174])
HMAC-SHA256 - 256 bit key length ([RFC2104] and [FIPS180‑2]
If supported, the use of HMAC-SHA256 is RECOMMENDED.
7. Initiation and Discovery
7.1. Initiation
To initiate OpenID Authentication, the Relying Party SHOULD present the end user with a form that has a field for entering a User-Supplied Identifier.
The form field's "name" attribute SHOULD have the value "openid_identifier", so that User-Agents can automatically determine that this is an OpenID form. Browser extensions or other software that support OpenID Authentication may not detect a Relying Party's support if this attribute is not set appropriately.
7.2. Normalization
The end user's input MUST be normalized into an Identifier, as follows:
If the user's input starts with the "xri://" prefix, it MUST be stripped off, so that XRIs are used in the canonical form.
If the first character of the resulting string is an XRI Global Context Symbol ("=", "@", "+", "$", "!") or "(", as defined in Section 2.2.1 of [XRI_Syntax_2.0], then the input SHOULD be treated as an XRI.
Otherwise, the input SHOULD be treated as an http URL; if it does not include a "http" or "https" scheme, the Identifier MUST be prefixed with the string "http://". If the URL contains a fragment part, it MUST be stripped off together with the fragment delimiter character "#". See Section 11.5.2 for more information.
URL Identifiers MUST then be further normalized by both following redirects when retrieving their content and finally applying the rules in Section 6 of [RFC3986] to the final destination URL. This final URL MUST be noted by the Relying Party as the Claimed Identifier and be used when requesting authentication.
See normalization example.
7.3. Discovery
Discovery is the process where the Relying Party uses the Identifier to look up ("discover") the necessary information for initiating requests. OpenID Authentication has three paths through which to do discovery:
If the identifier is an XRI, [XRI_Resolution_2.0] will yield an XRDS document that contains the necessary information. It should also be noted that Relying Parties can take advantage of XRI Proxy Resolvers, such as the one provided by 
I.org at http://www.xri.net. This will remove the need for the RPs to perform XRI Resolution locally.
If it is a URL, the Yadis protocol [Yadis] SHALL be first attempted. If it succeeds, the result is again an XRDS document.
If the Yadis protocol fails and no valid XRDS document is retrieved, or no Service Elements are found in the XRDS document, the URL is retrieved and HTML-Based discovery SHALL be attempted.
7.3.1. Discovered Information
Upon successful completion of discovery, the Relying Party will have one or more sets of the following information (see the Terminology section for definitions). If more than one set of the following information has been discovered, the precedence rules defined in [XRI_Resolution_2.0] are to be applied.
OP Endpoint URL
Protocol Version
If the end user did not enter an OP Identifier, the following information will also be present:
Claimed Identifier
OP-Local Identifier
If the end user entered an OP Identifier, there is no Claimed Identifier. For the purposes of making OpenID Authentication requests, the value "http://specs.openid.net/auth/2.0/identifier_select" MUST be used as both the Claimed Identifier and the OP-Local Identifier when an OP Identifier is entered.
7.3.2. XRDS-Based Discovery
If XRI or Yadis discovery was used, the result will be an XRDS Document. This is an XML document with entries for services that are related to the Identifier. It is defined in Section 3 of [XRI_Resolution_2.0]. See Appendix A.3 for an example XRDS document.
7.3.2.1. OpenID Service Elements
7.3.2.1.1. OP Identifier Element
An OP 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/server". An <xrd:URI> tag whose text content is the OP Endpoint URL
7.3.2.1.2. Claimed Identifier Element
A 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". An <xrd:URI> tag whose text content is the OP Endpoint URL. An <xrd:LocalID> tag (optional) whose text content is the OP-Local Identifier.
7.3.2.2. Extracting Authentication Data
Once the Relying Party has obtained an XRDS document, it MUST first search the document (following the rules described in [XRI_Resolution_2.0]) for an OP Identifier Element. If none is found, the RP will search for a Claimed Identifier Element.
7.3.2.3. XRI and the CanonicalID Element
When the Identifier is an XRI, the <xrd:XRD> element that contains the OpenID Authentication <xrd:Service> element MUST also contain a <CanonicalID> element. The content of this element MUST be used as the Claimed Identifier (see Section 11.5). This is a vital security consideration because a primary purpose of the <CanonicalID> element is to assert a persistent identifier that will never be reassigned, thus preventing the possibility of an XRI being ("taken over") by a new registrant.
The Relying Party MUST confirm that the provider of the XRD that contains the <CanonicalID> element is authoritative for that Canonical ID and that this XRDS document is authoritative for the OpenID Service Element. Relying Parties should either do this manually or ensure that their resolver does this.
When using XRI resolution, the Canonical ID MUST be used as the Claimed Identifier. For an XRI to be a valid Identifier, both the <ProviderID> and <CanonicalID> MUST be present in the discovered XRDS document.
When using URL Identifiers, the CanonicalID element MUST be ignored if present.
7.3.2.4. Additional Information
The "openid" namespace is no longer used as of OpenID Authentication 2.0. The "xrd" namespace is "xri://$xrd*($v*2.0)".
For compatibility with deployed code, it is RECOMMENDED that Relying Parties also accept "http://openid.net/signon/1.0" or "http://openid.net/signon/1.1" for the value of <xrd:Type>, as described in the OpenID Authentication 1.1 Compatibility mode section. It is RECOMMENDED that Relying Parties supporting OpenID Authentication 2.0 choose to use, if available, endpoints with the type "http://specs.openid.net/auth/2.0/server" and "http://specs.openid.net/auth/2.0/signon", in this order, as specified in Section 7.3.2.2
If an OP supports extensions (Section 12), the extensions SHOULD be listed as additional <xrd:Type> child elements of the <xrd:Service> element.
7.3.3. HTML-Based Discovery
HTML-Based discovery MUST be supported by Relying Parties. HTML-Based discovery is only usable for discovery of Claimed Identifiers. OP Identifiers must be XRIs or URLs that support XRDS discovery.
To use HTML-Based discovery, an HTML document MUST be available at the URL of the Claimed Identifier. Within the HEAD element of the document:
A LINK element MUST be included with attributes "rel" set to "openid2.provider" and "href" set to an OP Endpoint URL
A LINK element MAY be included with attributes "rel" set to "openid2.local_id" and "href" set to the end user's OP-Local Identifier
The protocol version when HTML discovery is performed is "http://specs.openid.net/auth/2.0/signon".
The host of the HTML document MAY be different from the end user's OP's host.
The "openid2.provider" and "openid2.local_id" URLs MUST NOT include entities other than "&", "<", ">", and """. Other characters that would not be valid in the HTML document or that cannot be represented in the document's character encoding MUST be escaped using the percent-encoding (%xx) mechanism described in [RFC3986].
As discussed in the OpenID Authentication 1.1 Compatibility mode section, these discovery tags are not the same as in previous versions of the protocol. While the same data is conveyed, the names have changed which allows a Relying Party to determine the protocol version being used. A Relying Party MAY encounter a Claimed Identifier which uses HTML-Based Discovery to advertise both version 1.1 and 2.0 Providers.
8. Establishing Associations
An association between the Relying Party and the OpenID Provider establishes a shared secret between them, which is used to verify subsequent protocol messages and reduce round trips.
It is RECOMMENDED that a Relying Party form associations if it is possible for it to do so. If a Relying Party is incapable of creating or storing associations, Section 11.4.2 provides an alternate verification mechanism referred to as Stateless Mode.
8.1. Association Session Request
An association session is initiated by a direct request from a Relying Party to an OP Endpoint URL with the "openid.mode" key having the value of "associate".
8.1.1. Common Request Parameters
These parameters are common to all association requests:
openid.ns As specified in Section 4.1.2.
openid.mode Value: "associate"
openid.assoc_type The preferred association type. The association type defines the algorithm to be used to sign subsequent messages.
Value: A valid association type from Section 8.3
openid.session_type The preferred association session type. This defines the method used to encrypt the association's MAC key in transit.
Value: A valid association session type from Section 8.4.
Note: Unless using transport layer encryption, "no-encryption" MUST NOT be used.
8.1.2. Diffie-Hellman Request Parameters
The following parameters are common to requests whose requested association session type is "DH-SHA1" or "DH-SHA256":
openid.dh_modulus Value: base64(btwoc(p))
Default: See Appendix B
openid.dh_gen Value: base64(btwoc(g))
Default: g = 2
openid.dh_consumer_public Value: base64(btwoc(g ^ xa mod p))
See Section 8.4.2 for more information on these parameters.
NOTE: The 'btwoc' function is defined in Section 4.2.
8.2. Association Session Response
An association session response is a direct response from the OP to the Relying Party in Key-Value Form.
8.2.1. Common Response Parameters
ns As specified in Section 5.1.2.
assoc_handle The association handle is used as a key to refer to this association in subsequent messages.
Value: A string 255 characters or less in length. It MUST consist only of ASCII characters in the range 33-126 inclusive (printable non-whitespace characters).
session_type The value of the "openid.session_type" parameter from the request. If the OP is unwilling or unable to support this association type, it MUST return an unsuccessful response.
assoc_type The value of the "openid.assoc_type" parameter from the request. If the OP is unwilling or unable to support this association type, it MUST return an unsuccessful response.
expires_in The lifetime, in seconds, of this association. The Relying Party MUST NOT use the association after this time has passed.
Value: An integer, represented in base 10 ASCII.