Why XRI

From I-names Development Wiki

Jump to: navigation, search

Contents

Status

Note: this page is in the process of being rewritten to add more material, however all the content it does contain is current.

Introduction

XRI (Extensible Resource Identifier) is a new open standard language for digital identifiers that can solve problems in cross-domain digital identification that are hard for URLs, other URIs, or OpenID to solve alone.

XRDS (Extensible Resource Descriptor Sequence) is a simple XML document format created by the XRI TC to provide a simple service discovery format for resources identified by XRIs. XRDS is already used as the discovery format for Yadis and OpenID, and in addition to XRIs, it can be used with HTTP(S) URLs or any other identifier that can be used to retreive an XML document.

If you are new to XRI, the following are good introductory resources:

This page provides a summary of the key problems XRI and XRDS were developed to solve and how XRI and XRDS infrastructure can solve them.

The Problems XRI Architecture was Developed to Solve

1) Cross-context identification: How can you refer to the same resource across different contexts (websites, domains, applications, databases) and yet still know you are referring to the same resource (semantic mapping of identifiers)?

2) Synonymous identification: How can you provide different identifiers (for different purposes) for the same resource and prove that they identify that resource? For example, how can you have both human-friendly, reassignable identifiers and machine-friendly, persistent identifiers for the same resource?

3) Granular addressability: How can you address resources and the data they contain to any level of granularity? (Note: this is a capability needed by XDI RDF addressing, XDI link contracts, and other data rights management mechanisms.)

4) Privacy-preservation: How can you assign privacy-friendly identifiers for resources while still being able to make them useful?

5) Separation of personal/organizational resources: How can you cleanly separate personal and organization data for privacy, legal compliance, and data rights management?

6) Self-describing identifiers: How can you create identifiers that both people and machines can understand and use to discover and evaluate resources and relationships?

7) Capabilities discovery: How can you can determine the cababilities of a resource from its identifier? For example, how could you discover what authentication service are available for an individual? How could determine what data exchange services are supported by an organization? How could you determine what metadata description services are available for an application? How could you discover the third parties that may be able to make assertions about a resource?

8) Representation discovery: How can you control the representation of a resource to which an identifier resolves? For example, how can you specify a desired type of authentication service for an individual? Or a desired media type for a file?

9) Extensibility: How can you have a extensible language that does for identifiers what XML does for data, i.e., that is able to accommodate new types and forms of identifiers while maintaining interoperability with the existing identifiers?


How XRI Architecture Solves These Problems

#1: Cross-Context Identification

Today, Web architects, site designers, developers, and users refer to everything on the web with URIs (mostly with a specific form of URI – an HTTP or HTTPS URL, often called a URL). Initially URIs were used primarily to refer primarily to web sites and web pages. As Web services evolved, they were used to refer to XML files, service definitions, and namespaces. Now, with the emergence of OpenID, URLs are being used to refer to users, as their portable digital identifier.

However users are an excellent example of a resource that has an identity in many different contexts: in the context of different companies, communities, sites, and applications.

URIs and URLs have no way of expressing the concept of "the same identity in a different contexts". Every URI/URL is the equivalent of a proper noun in English, and URI/URL syntax doesn't have a way of expressing that this same proper noun can exist inside another context, i.e., the same person in two different communities.

XRI syntax was explicitly designed for this capability. It uses a fundamental feature called cross-references to enable any URI- or XRI-addressable resource to be addressed in the context of another XRI-addressable resource.

For example, if the person =drummond (a personal i-name registered to Drummond Reed, co-chair of the XRI Technical Committee) wanted to express that he has an identity in a global context as well as in the context of both Cordance Corporation @cordance and XDI.org, @xdi.org (both organizational i-names registered to Cordance and XDI.org respectively), this could be done with the following three XRIs. (Note that these examples use the proposed XRI 3.0 direct concatenation syntax.) 

 =drummond
 @cordance=drummond
 @xdi.org=drummond

This shows how, in a format both humans and machines can understand, the personal identifier "=drummond" can be recognized as the same identity in three different contexts (in its own standalone global context, and within the organizational context of Cordance and XDI.org, respectively).

The same approach applies to tags. For example, if the XRI +blog is used to identify a blog, then =drummond can express a blog he maintains in each of the three different contexts above as: 

 =drummond+blog
 @cordance=drummond+blog
 @xdi.org=drummond+blog

And finally, this same approach can even be extended to specific forms of identifier metadata – specialized tags that both machines and people can understand. An example is a date tag, e.g., $date*2007-05-21. So all three of the above XRIs can be further tagged for the date of a specific blog entry. 

 =drummond+blog$date*2007-05-21
 @cordance=drummond+blog$date*2007-05-21
 @xdi.org=drummond+blog$date*2007-05-21

This illustrates how XRIs are composable identifiers, where each

#2: Synonymous Identification

XRI infrastructure is designed explicitly to assign, map, and verify multiple synonymous identifiers for the same resource, either in the same context, or across contexts. One particular application of synonyms is the ability to map reassignable identifiers for a resource, which may change over time (file names, domain names) to persistent identifiers that are intended never to be reassigned (URNs). XRI has a special context symbol for persistent identifiers: "!". This context symbol can be used inside any other context to indicate a persistent identifier. For example, the first three XRIs below are all reassignable identifiers that can be mapped to the fourth XRI, which is a persistent identifier for the same resource. 

=drummond
=(http://equalsdrummond.name)
=(mailto:drummond.reed@example.net)
=!F83.62B1.44F.2813

Note that this has special security applications for OpenID, as described at http://dev.inames.net/wiki/XRI_and_OpenID.

[TODO: Complete this section.]

  • Note: ability to map synonymous persistent and reassignable XRIs addresses the 4th vertex of the "Zookos pyramid" while allowing human-friendly identifiers.

#3: Granular Addressability

[TODO: Complete this section.]

  • Include XDI RDF capability to express RDF statements as XRIs

#4: Privacy Preservation

[TODO: Complete this section.]

#5: Separation of Personal & Organizational Resources

[TODO: Complete this section.]

#6: Self-Describing Identifiers

[TODO: Complete this section.]

#7: Capabilities Discovery

XRI infrastructure uses HTTP(S) and XML documents for resolution very much like DNS uses UDP and binary records for resolution. The XRI resolution format, called XRDS documents, is very simple and extensible, and has already been adopted by Yadis and OpenID. XRI syntax has special features to support XRI resolution, such as the ability to use the XRI path to select the desired XRDS service type, and a special set of defined query parameters for controlling resolution. 

 =drummond/+openid
 =drummond/+openid+personal
 =drummond/+openid@cordance
 =drummond/+contact
 =drummond/+forwarding
 =drummond*files?+home?_xrd_m=text/html

[TODO: Example XRDS documents]

#8: Representation Discovery

[TODO: Complete this section.]

#9: Extensibility

[TODO: Complete this section.]


Other Features of XRI Architecture

Simplicity

  • Unlike domain names XRI's may include . (dots) as part of an identifier without having to delegate to another zone or authority. This simple change makes i-names much more human readable. [see syntax spec]
  • XRI's are easily extensible in two ways. First users can easily add any number of *services* to their XRI by adding service blocks to their XRDS. Second in the rare circumstances where a defined XRDS tag does not meet the need you can easily add extensions with out hoving to go through an extensive standard's body review. [see resolution spec]
  • XRI's support the use of synonyms, aka nicknames. For instance my name is Lester Chasen but people call me Les. So I have registered =les (my nickname) and =les.chasen i-names that are both synonyms for my one persistent identifier, =!3697.D141.3C5E.742F. Please Note: The only way you know these are synonyms is because i just told you. There is no other way to find out.

Security

  • Through the use of authentication services a user may make use of any number of IDP's for authentication purposes. Why would a user need more than one IDP? The reason is that for many high value web sites (work, finance, e-commerce etc) there will be a need to trust that the IDP provides for the highest levels of security. Some may be fine with basic OpenId based authentication but others will require the higher levels of security that SAML provides. XRI works with both. As an example, if you look at the XRDS for =les you will see both an OpenId and SAML service.
  • http -vs- https - With OpenId it is much harder to control whether a secured channel (https) is used versus an unsecured channel (http). With XRI the secured channel (https) is always used with out the user having to think about it.
  • All names purchased in the XDI.org GRS are also protected from homographic attack through aggresive character mapping. We map all look alike characters such that a cyrillic a canonicalizes to an ascii a. This prevents things like the famous paypal phising attack where someone registers paypal.com but the a's are cyrillic instead of ascii.
  • CID validation protects against the spoofing of delegated XRIs. [See CID validation for details]
  • XRI further helps fight phising attacks because XRI's are read left to right instead of right to left in DNS. A very common attack these days are to use URl's that look like http://www.citibank.com.some_veeeeeeeeeeeeeeeeeeeeeeeeeeeeery_long_domain_name.com. Many users get confused into thinking this is actually citibank.com because that is what they see on the left unfortunately the controller of this url is the owner of some_veeeeeeeeeeeeeeeeeeeeeeeeeeeeery_long_domain_name.com. This is not possible in XRI's because the authoritative part starts on the left.


Applicability to Reputation Systems

A reputation system that is global in nature requires an identification system that has all of the above discussed features.

Older identifier technologies such as domain names, URIs and email addresses can be repurposes, but the morphing of these identifiers not only doesn't meet all aspects needed by a trustable identification system, it creates confusion. When you look at a domain name does it represent a person or a host? When you look at an http(s) URL is it a web page or a person? When you look at an email address is it a person or a group?

Retrieved from "http://dev.inames.net/wiki/Why_XRI"