W3C home > Mailing lists > Public > www-tag@w3.org > June 2008

RE: XRI vote aftermath

From: Drummond Reed <drummond.reed@cordance.net>
Date: Mon, 9 Jun 2008 09:07:20 -0700
To: "'Mark Baker'" <distobj@acm.org>
Cc: "'Ray Denenberg, Library of Congress'" <rden@loc.gov>, "'Schleiff, Marty'" <marty.schleiff@boeing.com>, "'Henry S. Thompson'" <ht@inf.ed.ac.uk>, <www-tag@w3.org>
Message-ID: <03f701c8ca4a$e629f840$0800a8c0@ELROND>

> > On Fri, Jun 6, 2008 at 1:17 PM, Drummond Reed wrote:
> >
> > This is one of the most frequently asking questions about XRI. The short
> > answer is #1.4 on the XRI 2.0 FAQ
> > (http://www.oasis-open.org/committees/xri/faq.php):
> >
> > ****** QUOTE ******
> >
> > What is the relationship of XRI to URI and IRI?
> >
> > URI (RFC 3986) is the IETF/W3C standard for addressing on the Web. IRI
> > (Internationalized Resource Identifier, RFC 3987) builds on top of the
> > specification by extending the syntax to include Unicode characters. It
> also
> > defines a transformation from an IRI into a valid URI for applications
> that
> > can only accept URIs.
> >
> > XRI follows this same model. It builds on the IRI specification by
> extending
> > the syntax to include features needed by abstract, structured
> identifiers
> > intended to identify resources independent of any specific network
> location,
> > domain, application, or protocol.
> On Saturday, June 07, 2008 11:55 AM, Mark Baker wrote:
> That seems to suggest that you believe that URIs - including http URIs
> - cannot be used as location/domain/application/protocol-independent
> identifiers.  Why is that?
> From my POV, all that's required for identification is an identifier -
> a string - and all URIs, including http URIs, are strings.  In other
> words, any URI can identify any resource.


Of course you are right, any URI is an identifier, and can be used to
identify a resource regardless of protocol or interaction method. However
URIs whose schemes are protocols or interaction methods (e.g., http:,
https:, ftp:, mailto:) tend to create confusion if either: a) the resource
is completely abstract and thus not available over that protocol, or b) the
resource is accessed over other protocols.

Of particular concern is how you establish synonymity of identifiers across
multiple protocols (i.e., prove the identifiers identify the same target
resource) if the identifier indicates a specific protocol. Here's a
practical example: as explained in [1], the editors of OpenID Authentication
2.0 [2] found that, as much as they wanted to, they could not specify that
http: and https: URIs that were equivalent in all respects except the scheme
identified the same resource. So the OpenID Authentication 2.0 spec requires
OpenID relying parties to default partially-typed OpenID URLs (e.g.,
user.openidprovider.com or opidprovider.com/user) to http: URIs. This means
OpenID users who want the higher security of using an https: URI (as
recommended by the spec) must type the entire string beginning with
"https:", which is widely acknowledged as a usability issue.

By contrast, XRIs (whether in XRI-normal form or transformed to the
IRI-normal form or URI-normal form that uses the xri: scheme) always serve
as abstract structured identifiers that are never tied to a specific
protocol. Thus there can be never be confusion that an XRI represents a
concrete location or interaction protocol for the identified resource. 

Because of this characteristic, in a protocol like OpenID Authentication
2.0, which can use either http or https for interaction, an XRI
automatically defaults to https for higher security, without the OpenID user
having to know anything or type anything different. In addition, a
reassignable XRI i-name that is easy for an OpenID user to remember and type
is automatically mapped to a persistent canonical XRI i-number in the
resulting XRDS document, thereby protecting the user from OpenID recycling
(another serious security issue also explained in more detail in [1]).

Hope this helps,


[2] http://openid.net/specs/openid-authentication-2_0.html
Received on Monday, 9 June 2008 16:08:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:57 UTC