[OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?

Drummond Reed drummond.reed at cordance.net
Thu Jan 4 07:25:44 UTC 2007

Bob, it's a great question, and David's correct as far as he goes, and so is
Johnny. However I suspect that the behaviour you're experiencing is due to
older OpenID libraries being used by the RP site at which you're
experiencing this behaviour.

Here's why: if you entered your i-name =bobwyman in URL format (we call this
an HXRI -- HTTP XRI) as http://xri.net/=bobwyman, then Johnny is correct
that by both the 1.1 and (pending) 2.0 specs, this would be considered a
URL, and Yadis resolution should proceed on the URL.

However Yadis resolution means the RP library should first do an HTTP GET on
the URL with a content type of application/xrds+xml. Such a request to an
XRI proxy resolution server (which is what http://xri.net is functioning as)
should return you the XRDS document for the XRI =bobwyman, exactly as Yadis
would for any other URL that has its own XRDS document.

In which case everything should work fine (except the issue of
http://xri.net/=bobwyman now being the Claimed Identifier, see below).
Because that's not happening, the RP library at the site you're testing must
not be doing Yadis resolution, or at least not requesting an XRDS document
type first. Instead it's just doing a plain http GET with no content type,
in which case the HXRI proxy resolver is returning a redirect to the default
service endpoint in the XRDS document per the XRI Resolution spec.

Since for most i-names, the default service endpoint is the registrant's
contact page, at least one i-broker, 1id.com, has cleverly got around this
non-Yadis-compliant behaviour by adding the necessary OpenID <link> elements
to the HTML of the contact page. (Victor Grey at 2idi told me today that he
plans to implement the same workaround.)

While this is a smart workaround, it shouldn't be necessary if the library
just does Yadis resolution in the correct order on the HXRI.

However all of this still leaves the open issue that Johnny raised, namely
that the current draft OpenID Authentication 2.0 spec treats =bobwyman and
http://xri.net/=bobwyman as separate identifiers. Ironically, in XRI Syntax
2.1 the XRI TC is formalizing HXRI syntax (it was originally part of XRI
Resolution 2.0 Working Draft 10, but we need to make it a formal part of XRI
Syntax), and we are making it very explicit that from the standpoint of
equivalence, the proxy resolver prefix of any HXRI is NOT part of the XRI.
In other words, the following two identifier...


...are equivalent XRIs because the former is really just the HXRI proxy
resolver prefix "http://xri.net" plus the absolute XRI "=bobwyman".

Therefore it seems to me the best thing to do would be to have OpenID
libraries recognize an HXRI (from the http://xri.* pattern) as a form of an
XRI, drop the HXRI proxy resolver prefix, and proceed with it as an XRI so
the user gets the i-name/i-number synonym benefits they expect.

Johnny, David, Josh: do you agree?


-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Recordon, David
Sent: Wednesday, January 03, 2007 8:55 PM
To: Bob Wyman; openid-general; specs at openid.net
Subject: Re: [OpenID] Dumb Question: Why isn't

My guess is that when a normal HTTP fetch is performed against
http://xri.net/=bobwyman, the proxy resolver expects you to be in a
browser and thus issues a 302 Redirect to your contact page.

One option is if the iBrokers (is it iBroker or i-broker?) included
Yadis on each contact page.  This would mean the OpenID Relying Party
would fetch http://xri.net/=bobwyman, be redirected to
http://2idi.com/contact/=bobwyman, and then have that URL to perform
discovery.  The problem this presents is that the Relying Party follows
redirects and canonicalizes the final URL as the Claimed Identifier.
This thus means you'd no longer be making a claim about
http://xri.net/=bobwyman, but rather that you own
http://2idi.com/contact/=bobwyman.  Thus if you change iBrokers, this
assertion would no longer remain valid.  It also removes the protection
the iNumber (and CanonicalID tag) adds to the XRI Resolution process
since i-names can be reassigned.

I'm unsure if there is some trickery that could be done in the Yadis
discovery document to resolve this, though really what I think would end
up is you would enter http://xri.net/=bobwyman to start the discovery
process, but then end up making an assertion about =bobwyman and not the
URL version of it.

Someone correct me here if my logic is wrong.



From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Bob Wyman
Sent: Wednesday, January 03, 2007 8:44 PM
To: openid-general
Subject: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman

My apologies if this is a really dumb question...
Why is it that I can do OpenID authentication with either of =bobwyman
or xri://=bobwyman but, according to the OpenIDEnabled checkup
_url=http%253A%252F%252Fxri.net%252F%253Dbobwyman>  page,
http://xri.net/=bobwyman is not a working OpenID?
bob wyman
general mailing list
general at openid.net

More information about the general mailing list