| Author: | Josh Hoyt |
|---|---|
| Company: | JanRain, Inc. |
| Date: | 11 Sept 2006 |
The OpenID 2.0 Authentication protocol is intended to be an incremental improvement that provides features to support use cases that are not covered by the OpenID 1.X protocol. It is intended to retain the simplicity and pragmatism that makes OpenID 1.X compelling. OpenID 2.0 is intended to be backwards-compatible in as many cases as possible to OpenID 1.X, as deployed.
Contents
- 1 Proposals in Draft 10
- 1.1 XRI Support
- 1.2 Yadis Support
- 1.3 IdP-driven Identifier Selection
- 1.4 Optional Identifier in Assertion
- 1.5 HTML Form-Based Redirection
- 1.6 HMAC-SHA256 Associations
- 1.7 Association Negotiation
- 1.8 Extensions
- 1.9 Nonce and Time stamp
- 1.10 RFC3986 URI Normalization
- 1.11 New Recommended Form Field Name in Initiation
- 1.12 Base Namespace
- 1.13 trust_root Renamed to realm
- 1.14 Send Claimed Identifier with checkid_* requests and id_res responses
- 2 Proposed for Draft 12
These proposed changes to the OpenID Authentication 1.X protocol have been included in draft 9 of the OpenID Authentication 2.0 specification.
XRI is a new Internet-wide identifier scheme that mixes well with URIs and is designed to be more user-friendly.
URLs are DNS-based. When URLs are used as persistent identifiers, the expiration of domain names allows someone who buys a domain name to assume any identities that are tied to that domain name. XRI has protection against this kind of failure.
The discovery phase of OpenID Authentication now includes XRI resolution as a mechanism for obtaining the IdP Endpoint URL and OpenID delegate identifier, instead of the HTML-based discovery from OpenID Authentication 1.X. Since XRI resolution libraries are not yet commonly deployed, a proxy XRI resolver is available to OpenID relying parties to ease deployment.
http://en.wikipedia.org/wiki/I-name
Yadis is a discovery mechanism that was designed for specifying services related to a HTTP or HTTPS URI.
Yadis allows for specifying multiple OpenID servers for a given URL, as well as for specifying capabilities of each server. Yadis discovery allows for specifying priorities for each server. It is easily extensible, making it easy for OpenID service discovery to coexist with other service discovery.
Yadis discovery also allows arbitrary content to be located at the OpenID Identifier URL (not just HTML).
Yadis discovery is performed, and when it fails, the Relying Party falls back to HTML-based discovery (as in OpenID 1.X). Yadis uses the same file format as XRI resolution, and will eventually become a section of the XRI resolution specification.
http://www.openidenabled.com/yadis/yadis-notes/
IdP-driven Identifier selection allows the IdP to choose what identifier to return to the Relying Party, rather than replying "yes" or "no" for a given identifier. This mechanism is based on ideas from the SXIP 1.0 and DIX protocols.
IdP-driven identifier selection allows for single-sign-on with "directed identity." When using directed identity, a user chooses from a set of identifiers that are not correlated with each other, so that they can retain as much anonymity as they desire while gaining the benefit of single-sign-on.
When initiating an OpenID authentication request, the user may enter either his own identifier or an identifier of an IdP. If he enters an IdP identifier, the authentication request is made to that IdP endpoint without asking for a particular identifier, and the IdP may make an assertion about any identifier for which it is authoritative. An IdP Endpoint is authoritative for any identifier that lists it as a service (through any of the available discovery mechanisms). The relying party must independently verify that the IdP endpoint is, in fact, authorized to make assertions about the returned identifier.
http://en.wikipedia.org/wiki/Laws_of_Identity (number 4)
In OpenID 1.X, the identifier was the only information that the assertion could contain. In OpenID 2.0, the assertion can contain additional information, so the identifier is not required to be in responses where it makes sense to leave it out.
When a Relying Party needs not identify a particular user but just wants some information about that user, such as demographic information, it promotes privacy to allow the response to be free of an identifier.
The assertion may not contain an identifier. It is up to the protocol user to determine whether this kind of assertion is useful.
OpenID 1.X communicates through the User-Agent via HTTP redirects. When both the Relying Party and the IdP are using the OpenID 2.0 protocol, they communicate through generating HTML forms that submit to the other party in the communication. This is the mechanism that SXIP and DIX uses for transmitting data through the User Agent.
Using redirects limits the size of the data that can be transferred to what can reasonably fit in a URL. Because the URLs must be able to be handled by unknown software (proxies, arbitrary user agents, etc.), long URLs can cause data loss or transaction failures. The size of data that can be transmitted via encoding into HTML forms is limited only by time and bandwidth requirements.
To send data via HTML form POST, a HTML page is sent to the user's browser with an action URL pointing to the recipient of the message. The sender of the message may also include a script in the HTML that automates the submission of the form as a convenience for the end user.
An association that use HMAC-SHA256 to generate message authentication codes (signatures) for protocol messages has been added.
HMAC-SHA256 was a recommendation of security review.
HMAC-SHA256 associations are identical to HMAC-SHA1 associations, except that they use a different keyed MAC algorithm to generate signatures. Because the key length is different, an additional association session type, DH-SHA256, is also necessary.
Association negotiation provides a way for an IdP and RP to agree on an association type and an association session type.
Association negotiation provides an explicit way to reply negatively to an association request without protocol failure. It also increases the chance that associations will work by allowing the IdP to suggest trying another association type or session type.
A reply type was added to the associate request that specifies that the requested association type or association session type is not supported by the IdP. In this response, the IdP may indicate supported association and session types, or omit them to refuse to create associations at all.
Extensions are additional data added to OpenID protocol messages that contain data about the user or the request. For example, the simple registration extension supports returning user data such as e-mail address to the relying party.
Extensions allow for innovation on top of the OpenID Authentication protocol without needing to revise the base specification. This keeps the specification simple without limiting its flexibility.
The primary motivation for extensions has been to add support for requesting user profile data using the OpenID Authentication protocol.
Extensions may also be used for supplying additional information with a request or response.
Extensions add data to OpenID protocol messages. The data for each extension is namespaced in way similar to XML namespaces, with each namespace being identified by a URI. An extension specification must define the meaning of the data that is passed with each OpenID message.
OpenID 2.0 adds a nonce to the request from the IdP and time stamp to successful authentication assertions.
Unless additional precautions are undertaken, OpenID 1.0 messages may be freely replayed. The addition of a nonce and time stamp makes messages unique, which means that relying parties can refuse to accept the same message more than once.
The IdP generates a unique nonce/time stamp pair for each successful authentication assertion. The relying party verifies that it has not seen an assertion with the given nonce and time stamp from the IdP.
OpenID 2.0 protocol initiation uses the rules from the URI syntax specification (RFC3986) to prevent some equivalent identifiers from appearing to be different.
OpenID 1.X specified a minimal form of normalization that does not cover as many cases as RFC 3986.
Certain cases of equivalent URLs appearing to be different, such as standard ports appearing in URLs, have occurred in the wild. Better normalization reduces the number of such cases.
Where OpenID 1.X specified its own normalization scheme, OpenID 2.0 specifies RFC3986 normalization. When fetching an identifier URL results in a redirect, the OpenID 2.0 specification retains the behavior of OpenID 1.0 and uses the resulting URL (after following all redirects) as the user's identifier.
The field in the form that is used for protocol initiation on the relying party has changed to reflect the fact that the identifier is not necessarily a URL.
XRI support means that calling the field "openid_url" is misleading.
Initiation forms should use the field name "openid_identifier" rather than "openid_url" as OpenID 1.0 recommended.
Allow explicit declaration of how to interpret an OpenID message
Currently, OpenID requests are backwards-compatible. If a change required incompatible changes to the message, declaring a namespace would allow the party interpreting the message to be able to determine the intended meaning of the parameters.
openid.ns will have the value of "http://openid.net/signon/2.0" for OpenID 2.0 messages.
Terminology fix to match common usage.
A "root" of "trust" has a specific meaning in Public Key cryptography. This meaning is different from the meaning of the trust_root parameter in OpenID 1, potentially causing confusion.
Use the name "realm" to refer to the domain over which an authentication decision is applicable.
An additional field that makes portable identifier use easier to understand and debug has been added.
IdP-driven identifier selection could only send assertions about identifiers that did not use delegation.
Send the field "claimed_id" along with the checkid_* request and the id_res response so that the IdP can present a better interface to the user and the relying party does not have to keep that state.
It is always necessary for the relying party to have performed discovery on the claimed identifier before honoring an assertion for that claimed identifier.
These changes are proposed for draft 12.
Make the specification allow fragments to be part of a valid OpenID URL identifier.
The fragments can be used by an OpenID provider to manage its namespace while retaining human-understandable identifiers.
The OpenID provider can send a URL with a fragment as the claimed identifier. The full URL (with the fragment) is the user's identifier, so relying parties store the URL with the fragment. The URL without the fragment should be used when the URL has to be displayed.
Add a mechanism for verifying that a return_to URL is intended to be an OpenID endpoint.
There exist several ways for an attacker to use a URL on a trusted site to send information to an untrusted site. When one of these attacks is made, the user sees a trusted realm, but their data will be forwarded to an untrusted site. These attacks are collectively referred to as "realm spoofing," and include (at least) open proxies, open redirectors, and cross-site-scripting attacks.
Yadis discovery on the realm, using any specified return_to URLs will show that the realm is tied to that particular return_to URL.