Re: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?
Drummond, Thanks for the detailed response. BTW: Below, you'll see what is happening when I use the Yadis diagnostic on the HXRI. I believe that users will, in fact, expect XRI's, i-names, and HXRI's to be interchangeable. I'm using 2idi.com, so I guess I have to wait for them to put in the fix? Also, I find it a bit odd that the Yadis diagnostic reports a pass for OpenID... Apparently, the metric for passing is pretty forgiving. bob wyman http://www.openidenabled.com/resources/yadis-test/yadis-detect?url=http%3A%2F%2Fxri.net%2F%3Dbobwymannegotiation=on Results for *http://xri.net/=bobwyman*: - I fetched http://xri.net/=bobwyman, asking for content type application/xrds+xml - The document's content type is application/xrds+xml;trust=none. That is the XRDS content type. - There was no YADIS HTTP header. - I got a document. It is 916 bytes long and begins '?xml version= 1.0 encoding=UTF-8?\nXRDS ref=xri://=bobwyman x' - I parsed an XRDS document. - I found a service, but it's not a type I recognize. It's a service at http://2idi.com/contact/ - I found a service, but it's not a type I recognize. It's a xri://+i-service*(+contact)*($v*1.0) service at http://2idi.com/contact/ - I found a service: OpenID at https://2idi.com/openid/ with delegate None - I found a service: OpenID at http://2idi.com/openid/ with delegate None - *XRDS:* *Passed* Your YADIS URL leads to an XRDS document. Your YADIS URL is http://xri.net/=bobwyman - *OpenID:* *Passed* Your YADIS URL leads to at least one OpenID service. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?
Bob, From the report you show, the Yadis diagnostic is doing the correct resolution call to the xri.net HXRI proxy resolver. So it's sites that have the pre-Yadis RP libraries that won't yet work with HXRIs (or with any other Yadis-enable URL for that matter). Those libraries are only looking for the HTML link elements (I think). And I completely agree that an XRI in any format - raw i-name, with an xri:// scheme prefix, or with an HXRIs proxy resolver prefix like http://xri.net http://xri.net/ - all need to be interchangeable. You're right that this will require a slight fix at the i-brokers. =Drummond _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Wyman Sent: Wednesday, January 03, 2007 11:38 PM To: Drummond Reed Cc: Recordon, David; openid-general; specs@openid.net Subject: Re: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID? Drummond, Thanks for the detailed response. BTW: Below, you'll see what is happening when I use the Yadis diagnostic on the HXRI. I believe that users will, in fact, expect XRI's, i-names, and HXRI's to be interchangeable. I'm using 2idi.com, so I guess I have to wait for them to put in the fix? Also, I find it a bit odd that the Yadis diagnostic reports a pass for OpenID... Apparently, the metric for passing is pretty forgiving. bob wyman http://www.openidenabled.com/resources/yadis-test/yadis-detect?url=http%3A%2 F%2Fxri.net%2F%3Dbobwyman http://www.openidenabled.com/resources/yadis-test/yadis-detect?url=http%3A% 2F%2Fxri.net%2F%3Dbobwymannegotiation=on negotiation=on Results for http://xri.net/=bobwyman: * I fetched http://xri.net/=bobwyman, asking for content type application/xrds+xml * The document's content type is application/xrds+xml;trust=none. That is the XRDS content type. * There was no YADIS HTTP header. * I got a document. It is 916 bytes long and begins '?xml version=1.0 encoding=UTF-8?\nXRDS ref=xri://=bobwyman x' * I parsed an XRDS document. * I found a service, but it's not a type I recognize. It's a service at http://2idi.com/contact/ * I found a service, but it's not a type I recognize. It's a xri://+i-service*(+contact)*($v*1.0) service at http://2idi.com/contact/ * I found a service: OpenID at https://2idi.com/openid/ with delegate None * I found a service: OpenID at http://2idi.com/openid/ with delegate None * XRDS: Passed Your YADIS URL leads to an XRDS document. Your YADIS URL is http://xri.net/=bobwyman * OpenID: Passed Your YADIS URL leads to at least one OpenID service. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?
You're right, David -- the only real effect in the spec should be that an HXRI is recognized as being an XRI (and not a URL) from the standpoint of what the RP should do once it gets back the XRDS document, i.e., the RP MUST use the CanonicalID i-number and not the original HXRI. That would solve the issue Johnny brought up, and also properly support the use of multiple i-name (or HXRI) synonyms for the same i-number. =Drummond -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 03, 2007 11:34 PM To: Drummond Reed; Bob Wyman; openid-general; specs@openid.net Subject: RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID? 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. I'd agree from a usability standpoint that would be the best recommendation. The only thing that would be a bit hard to explain is that the library could still use http://xri.net as a proxy resolver. So the potentially confusing steps would be: 1) User enters http://xri.net/=bobwyman 2) RP sees prefix http://xri.net/=; and then extracts =bobwyman 3) RP constructs Yadis fetch on http://xri.net/=bobwyman for proxy resolution of the i-name =bobwyman --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 03, 2007 11:26 PM To: Recordon, David; 'Bob Wyman'; 'openid-general'; specs@openid.net Subject: RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID? 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... http://xri.net/=bobwyman =bobwyman ...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? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Wednesday, January 03, 2007 8:55 PM To: Bob Wyman; openid-general; specs@openid.net Subject: Re: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwymananOpenID? My guess is that when
RE: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwyman an OpenID?
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... http://xri.net/=bobwyman =bobwyman ...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? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Wednesday, January 03, 2007 8:55 PM To: Bob Wyman; openid-general; specs@openid.net Subject: Re: [OpenID] Dumb Question: Why isn't http://xri.net/=bobwymananOpenID? 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. --David From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 anOpenID? 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