[OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?
dag at janrain.com
Fri Jan 5 18:29:08 UTC 2007
The relevant part of the Yadis spec is small so I am including it in its
The Yadis Protocol is initiated by the Relying Party Agent with an
initial HTTP request using the Yadis URL.
This request MUST be either a GET or a HEAD request.
A GET or HEAD request MAY include an HTTP Accept request-header (HTTP
14.1) specifying MIME media type, application/xrds+xml.
The response MUST be one of:
1. An HTML document with a <head> element that includes a <meta> element
2. HTTP response-headers that include an X-XRDS-Location
response-header, together with a
3. HTTP response-headers only, which MAY include an X-XRDS-Location
response-header, a content-
type response-header specifying MIME media type, application/xrds+xml,
4. A document of MIME media type, application/xrds+xml.
XRI.net is out of spec for http://xri.net/=bobwyman because it does not
respond with any of the 4 acceptable responses when the optional Accept
request-header is not included. It appears as though is is in spec for
http://xri.net/=bobwyman?_xrd_r=application/xrds%2bxml but that is not a
very nice user-facing interface.
Drummond Reed wrote:
> The Yadis 1.0 spec (http://yadis.org/papers/yadis-v1.0.pdf) section 6.2.5
> says that one of the four valid responses to a Yadis request is an XRDS
> document. That's what xri.net, the XDI.org HXRI proxy resolver, returns. It
> does not return the other three options because XRI resolution is its
> primary job.
> Also, the latest draft of the OpenID OpenID Authentication 2.0 spec I've
> seen says that the RP should first do a GET for an XRDS file, and if that
> fails, then do a GET for an HTML page link or header.
> So the problem is not with xri.net if the request asks for a content type of
> application/xrds+xml. Note that with any HXRI proxy resolver, you don't even
> have to explicitly set the requested content type in the GET request; you
> can also pass it it directly in the URL by adding a query parameter as
> follows (to use the =bobwyman example):
> (Note that the query parameter name is "_xri_r" and %2b is an escaped +
> However even once the openidenabled.com code requests/receives the XRDS
> file, there is still one other thing that needs fixing. XDI.org-accredited
> i-brokers that provide OpenID authentication need to expect an HXRI as well
> as a plain XRI in the OpenID authentication request (currently most of them
> just expect an XRI).
> Once those two things are fixed, using a full HXRI as an OpenID URL should
> work fine, however as discussed before, it ends out treating an HXRI as a
> URL and is not nearly as good as an RP supporting 2.0 and getting the full
> benefits of XRI synonym management.
> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of Dag Arneson
> Sent: Thursday, January 04, 2007 2:00 PM
> To: openid-general
> Subject: Re: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an
> As I mentioned before, xri.net is not spec compliant with OpenID since
> it does not use the header or the meta tag to indicate the location of
> the xrds. I was curious, so I poked around a little more.
> If I try to log in to my blog (which uses the Ruby OpenID lib) with
> http://xri.net/=rorek as my OpenID, I get to 2idi (=rorek's i-broker)
> with the error: I-Name not found: =http://xri.net/=rorek
> It appears that xri.net does support the Accept:application/xrds+xml
> header method of obtaining the xrds, but without the openid:delegate the
> 2idi openid server gets confused:
> $ curl -v -H Accept:application/xrds+xml http://xri.net/=rorek
> * About to connect() to xri.net port 80
> * Trying 18.104.22.168... connected
> * Connected to xri.net (22.214.171.124) port 80
> > GET /=rorek HTTP/1.1
> > User-Agent: curl/7.15.5 (i486-pc-linux-gnu) libcurl/7.15.5
> OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5
> > Host: xri.net
> > Accept:application/xrds+xml
> < HTTP/1.1 200 OK
> < Server: Apache-Coyote/1.1
> < Content-Type: application/xrds+xml;trust=none
> < Content-Length: 912
> < Date: Thu, 04 Jan 2007 21:22:16 GMT
> <?xml version="1.0" encoding="UTF-8"?>
> <XRDS ref="xri://=rorek" xmlns="xri://$xrds">
> <XRD xmlns="xri://$xrd*($v*2.0)">
> <Status code="100"/>
> <LocalID priority="10">!7A49.7EDD.2592.F77B</LocalID>
> <CanonicalID priority="10">=!7A49.7EDD.2592.F77B</CanonicalID>
> <Service priority="10">
> <Type select="true">http://openid.net/signon/1.0</Type>
> <URI append="qxri" priority="2">http://2idi.com/openid/</URI>
> <URI append="qxri" priority="1">https://2idi.com/openid/</URI>
> <Service priority="10">
> <Type select="true">xri://+i-service*(+contact)*($v*1.0)</Type>
> <Type match="default"/>
> <Path select="true">(+contact)</Path>
> <Path match="null"/>
> <URI append="qxri" priority="1">http://2idi.com/contact/</URI>
> * Connection #0 to host xri.net left intact
> * Closing connection #0
> So there are 2 problems here: xri.net has partially broken discovery,
> and 2idi.com's openid server doesn't support the xri.net urls.
> To diagnose the 2idi problem I fired up the LiveHTTPHeaders firefox
> extension (highly recommended for diagnosing openid problems).
> Here's the url I'm redirected to on 2idi, slightly reformatted:
> Which looks fine. After that the stuff is thrown in the session
> apparently and what happens after that to change http://xri.net/=rorek
> into =http://xri.net/=rorek is not clear.
> Dag Arneson
> general mailing list
> general at openid.net
More information about the general