Re: XRI vote aftermath

Hi Drummond,

On Mon, Jun 9, 2008 at 12:07 PM, Drummond Reed
<drummond.reed@cordance.net> wrote:
> Mark,
>
> 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.

I agree that sometimes confusion results, but that's a brain problem.
I've yet to see it cause an interoperability problem 8-)

> 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.

The OpenID editors were right not to make assumptions about http and
https URI equivalence.  But couldn't the http/https synonym problem be
solved by a publisher establishing a redirect from an http URI to an
https URI?

> 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]).

Interesting.  I haven't looked at that, but will do so.

> Hope this helps,

Yes, thanks.

Mark.

Received on Monday, 9 June 2008 18:33:20 UTC