[OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?
les.chasen at neustar.biz
Fri Jan 5 22:01:06 UTC 2007
It is important for every one to realize that xri.net is a proxy
resolver. It will return to the user, making a query, the answer to a
XRI resolution request. The default behavior, if no input parameters
are used, is to redirect to the selected service. The vast majority of
people have configured the contact page to be the default service and
therefore a request to xri.net for just an iname returns the contact
page. Other folks have chosen to not have the contact page be the
default service. I for one set up @neustar to point to www.neustar.biz.
So please realize that it is up to the XRDS owner to decide what pages
are returned and he may decide to point to a web page or other
application that is not yadis compliant. Also please realize that if
you ask the proxy resolver (xri.net) to return an XRDS document then you
will always get back an XRDS that is YADIS compliant.
Hope this helps.
> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed at cordance.net]
> Sent: Friday, January 05, 2007 3:34 PM
> To: 'Dag Arneson'
> Cc: 'openid-general'; Chasen, Les; Tan, William; 'Victor Grey'
> Subject: RE: [OpenID] Dumb Question: Why isn't
> Ahhh, Dag, thanks, I wasn't reading the spec that way, i.e., I didn't
> realize the server needed to return one of the four responses even if
> content type application/xrds+xml wasn't included.
> Since the xri.net HXRI proxy resolver is designed to serve both
> and XRI-unaware clients, when it receives a request with no XRI
> parameters and no application/xrds+xml media type, it tries to do the
> intelligent thing, which is to parse the XRDS file, select the
> service (the rules for selecting a default service are in XRI
> Working Draft 10), and then return a redirect to the highest priority
> for that service. That way users of XRI-unaware browsers get back a
> page or other resource they expect instead of a bunch of XML.
> Since both Yadis and OpenID permit intermediate servers to send a 3xx
> redirect, and this what xri.net and other HXRI proxy resolvers will
> it's not really xri.net that's not Yadis-compliant, it's the server to
> the redirect is sent IF it doesn't return one of the four responses.
> As I mentioned in an earlier message, some i-brokers are now Yadis-
> the contact pages they host for XRI registrants, since for most
> their contact page is typically their default service. In this case
> response from the server to which the xri.net (or any other HXRI proxy
> resolver) will redirect will be Yadis-compliant, and for customers of
> i-broker who use a contact page as their default service, the
> http://xri.net/=bobwyman problem will be solved. (I believe Bob's
> is 2idi.com, and Victor Grey is adding Yadis-compliance to his contact
> as we speak.)
> (Note: All of this continues to be a stopgap until OpenID
> 2.0-compliant libraries recognize HXRIs, i.e., the http://xri.* +
> path-that-begins-with-an-XRI-GCS-char pattern. Then they will simply
> the embedded XRI as a true XRI and all will be good.)
> -----Original Message-----
> From: Dag Arneson [mailto:dag at janrain.com]
> Sent: Friday, January 05, 2007 10:29 AM
> To: Drummond Reed
> Cc: 'openid-general'; 'Chasen, Les'; 'Tan, William'
> Subject: Re: [OpenID] Dumb Question: Why isn't
> The relevant part of the Yadis spec is small so I am including it in
> 6.2.4 Initiation
> 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.
> 6.2.5 Response
> The response MUST be one of:
> 1. An HTML document with a <head> element that includes a <meta>
> with http-equiv
> attribute, X-XRDS-Location,
> 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,
> or both.
> 4. A document of MIME media type, application/xrds+xml.
> XRI.net is out of spec for http://xri.net/=bobwyman because it does
> respond with any of the 4 acceptable responses when the optional
> request-header is not included. It appears as though is is in spec
> http://xri.net/=bobwyman?_xrd_r=application/xrds%2bxml but that is not
> very nice user-facing interface.
> Drummond Reed wrote:
> > Dag,
> > The Yadis 1.0 spec (http://yadis.org/papers/yadis-v1.0.pdf) section
> > says that one of the four valid responses to a Yadis request is an
> > document. That's what xri.net, the XDI.org HXRI proxy resolver,
> > does not return the other three options because XRI resolution is
> > primary job.
> > Also, the latest draft of the OpenID OpenID Authentication 2.0 spec
> > seen says that the RP should first do a GET for an XRDS file, and if
> > 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
> > application/xrds+xml. Note that with any HXRI proxy resolver, you
> > have to explicitly set the requested content type in the GET
> > can also pass it it directly in the URL by adding a query parameter
> > follows (to use the =bobwyman example):
> > http://xri.net/=bobwyman?_xrd_r=application/xrds%2bxml
> > (Note that the query parameter name is "_xri_r" and %2b is an
> > sign.)
> > However even once the openidenabled.com code requests/receives the
> > file, there is still one other thing that needs fixing. XDI.org-
> > i-brokers that provide OpenID authentication need to expect an HXRI
> > as a plain XRI in the OpenID authentication request (currently most
> > just expect an XRI).
> > Once those two things are fixed, using a full HXRI as an OpenID URL
> > work fine, however as discussed before, it ends out treating an HXRI
> > URL and is not nearly as good as an RP supporting 2.0 and getting
> > benefits of XRI synonym management.
> > =Drummond
> > -----Original Message-----
> > From: general-bounces at openid.net [mailto:general-bounces at openid.net]
> > Behalf Of Dag Arneson
> > Sent: Thursday, January 04, 2007 2:00 PM
> > To: openid-general
> > Subject: Re: [OpenID] Dumb Question: Why isn't
> > OpenID?
> > As I mentioned before, xri.net is not spec compliant with OpenID
> > it does not use the header or the meta tag to indicate the location
> > 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
> > 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
> > 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 188.8.131.52... connected
> > * Connected to xri.net (184.108.40.206) 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)">
> > <Query>*rorek</Query>
> > <Status code="100"/>
> > <Expires>2007-01-04T22:22:16.000Z</Expires>
> > <ProviderID>xri://=</ProviderID>
> > <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>
> > <ProviderID/>
> > <URI append="qxri" priority="2">http://2idi.com/openid/</URI>
> > <URI append="qxri" priority="1">https://2idi.com/openid/</URI>
> > </Service>
> > <Service priority="10">
> > <Type select="true">xri://+i-service*(+contact)*($v*1.0)</Type>
> > <Type match="default"/>
> > <ProviderID/>
> > <Path select="true">(+contact)</Path>
> > <Path match="null"/>
> > <URI append="qxri" priority="1">http://2idi.com/contact/</URI>
> > </Service>
> > </XRD>
> > </XRDS>
> > * Connection #0 to host xri.net left intact
> > * Closing connection #0
> > So there are 2 problems here: xri.net has partially broken
> > 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:
> > http://2idi.com/openid/?openid.mode=checkid_setup&
> > DXG7PHaJu&
> > openid.trust_root=http%3A%2F%2Frorek.org%2Fblog%2F&
> > openid.identity=http%3A%2F%2Fxri.net%2F%3Drorek&
> > openid.assoc_handle=%7BHMAC-SHA1%7D%7B459d757d%7D%7BO02jbg%3D%3D%7D
> > Which looks fine. After that the stuff is thrown in the session
> > apparently and what happens after that to change
> > into =http://xri.net/=rorek is not clear.
> > Dag Arneson
> > a.k.a.
> > rorek.org
> > =rorek
> > dag.myopenid.com
> > sanedragon
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
More information about the general