XRI and OpenID
From I-names Development Wiki
Contents |
[edit] How did XRI become part of OpenID 2.0?
"OpenID 2.0" represents the convergence of four approaches to identifier-based digital identity (also commonly referred to as "URL-based identity"). These four approachs were:
- OpenID 1.0 (originated by Brad Fitzpatrick at SixApart)
- LID (Lightweight Identity, originated at Netmesh)
- XRI/i-names (Extensible Resource Identifier, originated by the XRI Technical Committee at OASIS, and the i-names registries, operated by XDI.org)
- SXIP/DIX (Simple Extensible Identity Protocol & Digital Identity Exchange, orginated at Sxip Identity)
By the fall of 2005, these four approaches were all going to market, and the similarity of their vision and intent led to multiple conversations about the opportunities for convergence. These conversations culminated at the first Internet Identity Workshop (IIW) in October 2005.
In this discussion there was consensus that users should only need to see one login box where they could enter the identifier of their choice and be authenticated via the protocol of the relying party's choice. This solution required a service discovery protocol. The OASIS XRI Technical Committee (TC) had developed such a protocol for XRI resolution that uses a simple, flexible XML document called an XRDS (Extensible Resource Descriptor Sequence). Following IIW, the XRI TC added new features to the XRDS format to meet the needs of the OpenID community. This revised XRDS format could work with any identifier capable of being resolved, so it was integrated into the Yadis discovery protocol as described in these blog entries from Phil Windley, Johannes Ernst, and Drummond Reed.
Convergence conversations continued at the second IIW in May 2006. By the Berkman Identity Workshop in June 2006 the stage was set for all four identifier-based user-centric identity protocols to converge into OpenID 2.0. As David Recordon put it in a message to the Yadis List
"We see OpenID as being an umbrella for the framework that encompasses the layers for identifiers, discovery, authentication, and a messaging services layer that sits atop and this entire thing has been dubbed 'OpenID 2.0'".
By Digital Identity World in September 2006, the work was well underway, and the first fully converged specification is expected to be released in January or February of 2007. The members of the converged OpenID 2.0 community agree that although it has been a long process and at times a real struggle, the outcome has the clear potential to become the foundation of a user-centric identity layer for the entire Web.
[edit] What does XRI add to OpenID?
XRI is a new language for digital identifiers designed expressly for the requirements of digital identity infrastructure such as OpenID. It is compatible with URIs (and thereby URLs), which is why XRI fits well within the OpenID framework. XRIs and XRDS documents can make the following contributions to the OpenID framework:
- The XRDS metadata discovery format and resolution protocol (which has already been adopted by Yadis.
- The XRI syntax and XRDS synonym capability for mapping a human-friendly, reassignable XRI (called an i-name) to a persistent, non-reassignable XRI (called an i-number) so that OpenID users are permanently protected from having their OpenID identity reassigned to another registrant. See "Security Vulnerability of Reassignable Identifiers" below.
- The XRI syntax capability to distinguish between i-names/i-numbers assigned in a personal context (=names/numbers) and an organizational/community context (@names/numbers).
- 100% https resolution of all i-names/i-numbers rooted on the XDI.org XRI registries (without the need to type https://).
- Strong personal privacy protection for global i-name/i-number registration (the XDI.org XRI registries have no Whois service, minimal contact data requirements, and double-blinded privacy of contact data).
[edit] What is the difference between using a URL and an XRI i-name as an OpenID identifier?
The primary differences are:
- Simplicity and consistency. An XRI i-name for an individual is just a UTF-8 string prefixed with an = sign, e.g.,
=exampleor=example.name(note that i-name can contain a dot for readability). For an organization it is a UTF-8 string prefixed with an @ sign (@example.company). No protocol prefix (e.g., "http://" or "https://") is required (OpenID consuming applications can always use https for secure resolution -- see below). This form is consistent across all applications, UIs, address bars, etc. See the Examples section below for more illustrations. - Persistent identifiers. All XRI i-names registered with the XDI.org XRI global registries have a synonymous global i-number that is persistent (never reassigned). The OpenID Authentication 2.0 specification requires RPs to use this i-number instead of the i-name as their primary key for the user so that the user is protected from ever losing their OpenID identity because their i-name was reassigned. (Note: XRI community registries follow this same practice, thus the protection of having a persistent identifier should extend to all XRIs rooted on the XDI.org global registries.) See "Security Vulnerability of Reassignable Identifiers" below.
- Automatic synonym management. With XRI infrastructure, a user may register as many i-name synonyms as they wish – including synonyms in different communities – and automatically have them resolve to the same i-number.
- Automatic https resolution. All XDI.org XRI registries and the xri.net proxy resolution network support https resolution for XRIs, so the OpenID Authentication 2.0 specification requires its use with XRIs for stronger security.
- Flexible syntax and native Unicode support. XRI syntax permits the use of both dots and dashes in i-names, plus XRIs are standard UTF-8-encoded Unicode strings for internationalization.
- Standard OpenID Provider security requirements. While an i-name user is not required to use an XDI.org-Accredited I-Broker as an OpenID Provider, all XDI.org-Accredited I-Brokers are required by XDI.org to support at least the minimum set of requirements published by XDI.org for OpenID authentication and security.
[edit] Does OpenID discovery work differently for a URL than an XRI?
A URL may resolve directly to an OpenID server, or it may have a HTML page with a link element pointing to the OpenID Provider, or it may have an XRDS document (also referred to as a Yadis document]).
All XRIs have a corresponding XRDS document for discovery of OpenID (and other) service endpoints. Most XDI.org-Accredited I-Brokers offer a simple Web interface for management of an i-name registrant's XRDS.
[edit] Examples
[edit] Identifier Appearance
Technically an OpenID URL is a fully qualified HTTP or HTTPS URL...
http://example.name https://example.name http://example.com/user
...although in practice you can usually leave out the http:// or https:// prefix and type just the domain name and path...
example.name example.name example.com/user
The simplest form of XRIs, called i-names, always start with just a single symbol character – = for personal XRIs and @ for organizational XRIs. I-names also don't require (but allow) dots, so they can be even simpler than URLs.
=name =first.last @organization
Just like domain names, i-names can also be delegated using a star * rather than a dot. These are called community i-names.
=name*delegated.name @company.name*division
[edit] XRDS Service Discovery
The XRI resolution protocol uses HTTP(S), so an XRDS document format can always be retrieved via an HTTP(S) URL. However XRIs are specifically designed to get the most of XRDS discovery and vice versa.
For example, the path component of an XRI can be used to specify a specific service endpoint within the XRDS document. An XRI resolver simply does a stem match of the path component of the XRI with the <Path> element of the XRDS document. For example, the following XRIs...
=example.name/+work =example.name/+home =example.name/+blog
...can be used to select three different OpenID services from the same XRDS below.
<XRDS> <XRD> <Query>=example.name</Query> <ProviderID>xri://=</ProviderID> <CanonicalID>=!f831.62b1.44fd.2855</CanonicalID> <Service priority="1"> <Type>http://openid.net/signon/1.0</Type> <Path>+work</Path> #1 <URI>http://example.com/openid-URL-for-work</Ref> </Service> <Service priority="2"> <Type>http://openid.net/signon/1.0</Type> <Path>+home</Path> #2 <URI>http://example.org/openid-URL-for-home</Ref> </Service> <Service priority="10"> <Type>http://openid.net/signon/1.0</Type> <Path>+blog</Path> #3 <URI>http://example.net/openid-URL-for-blog</Ref> </Service> </XRD> </XRDS>
You can also add query parameters to an XRI to request services of a specific <Type> or that support a specific <MediaType>.
[edit] The Security Vulnerability of Reassignable Identifiers
Since XRI syntax and resolution infrastructure was designed explicitly for Internet-scale digital identity, it includes a key security feature especially important to personal identity frameworks like OpenID: automatic mapping of human-friendly, reassignable identifiers to persistent identifiers that will never be reassigned.
Why is this so important? If you as an individual begin using a domain-name based URL as your OpenID at websites across the net, and at some point in the future you lose that domain name to someone else (it expires and is not renewed, you lose it in a domain name dispute, you pass away), whoever the new registrant is now completely controls your OpenID identity. Ironically that happens because it's exactly how OpenID is designed to operate: the credentials for proving ownership of an identifier are now tied to resolution of the identifier itself, and not to the sites at which it is used.
XRI infrastructure prevents this form of identity misappropriation by automatically mapping every i-name to a synonymous persistent i-number (a non-reassignable XRI in which each subsegment starts with a !). OpenID relying parties store this i-number, rather than an the i-name, as the identifier of the user.
Another key feature of XRIs is that the entire resolution infrastructure supports HTTPS, so all XRIs can automatically use HTTPS resolution without it needed to be explicitly specified. (For technical reasons, OpenID URLs must have https:// typed explicitly by the user in order to use HTTPS resolution from the start.)
