OpenID Discovery Proxy Service
From I-names Development Wiki
Contents |
[edit] Background
As OpenID spreads, i-name users want to be able to use their i-name as their OpenID identifier. A new Web SSO page at inames.net site explains the benefits of doing this.
However i-names do not work as OpenID identifiers at some OpenID-enabled sites that are not yet using XRI-enabled OpenID libraries. Following is what we currently know about OpenID i-name support:
- JanRain’s OpenID 1.1 and 2.0-pre-release (since 2.0 is not final yet) libraries support i-names with limited Canonical ID verification (click through to see the XRI TC wiki page with a full explanation of the current status of this proposed XRI Resolution 2.0 feature).
- Sxip’s OpenID4Java library supports i-names but not with Canonical ID verification yet.
- Drupal’s new OpenID module supports i-names (thanks to hard work by Fen Labalme and others).
However some other OpenID sites, such as LiveJournal, do not yet support XRI/i-names. Also, OpenID 1.0-enabled sites don’t even support XRDS service discovery Yadis, which was added to OpenID 1.1.
This is further complicated because the first spec that officially incorporates XRI/i-names support, OpenID Authentication 2.0, is still not final. It’s been at Draft 11 for 6+ months, but there is still at least one remaining open issue to be closed, Identifier Recycling. (This is another area, besides XRDS documents, where XRI architecture may have something to contribute to OpenID – its Canonical ID verification feature.)
In any case, the result is that until XRI/i-names support is ubiquitous across OpenID libraries and relying parties, it can be very frustrating for i-names users when they try their i-name at an OpenID-enabled site and find it won't work.
[edit] The Specific Challenge
One way to help allieviate the pain over this transition period is to provide a mechanism to allow i-names users to use their i-name as an "ordinary" URL (formally called an HTTP(S) URI). There is already a standard way to express an i-name – or any XRI – as an URL. This format, called an HXRI (HTTP XRI), looks like:
http://xri.net/=example.name
However, HXRI format by itself does not solve the problem because an HXRI server does not automatically return the XRDS document or XRDS document location metadata required for OpenID discovery. The process for doing this, originally specified by Yadis 1.0, is now being added to XRI Resolution 2.0 Working Draft 11 – see this XRI TC wiki page for the complete text.
Instead, by design, an HXRI server returns the default i-service in the XRDS document for an i-name registrant, which typically (but not always) is their contact page.
Some i-brokers have worked around this by adding the necessary XRDS discovery metadata directly to the registrant's contact page.
However this solution only works if:
- A user's contact page is the default resource returned by the HXRI server.
- The i-broker has the ability to add XRDS location metadata to the contact page.
Ideally, there would be a solution that would work for all i-name users across all i-brokers and across all OpenID 1.1-and-higher sites that do not yet support i-names but do support XRDS discovery.
[edit] Proposed Solution: OpenID Discovery Proxy Service
A proposed solution would be for the XRI/i-names community to put up a specialize HXRI proxy server – an OpenID discovery proxy server -- that has been configured to automatically return the necessary XRDS discovery metadata.
[edit] OpenID Discovery Proxy Service Address
The proposed address of this server is:
openid.xri.net
To use this service, any i-name user (from any i-broker) would simply type their i-name into an OpenID login box in the following format:
openid.xri.net/=example.name
[edit] OpenID Discovery Proxy Service Response
The only job of the OpenID discovery proxy server is to return the XRDS document for the XRI passed to the OpenID discovery proxy service by performing the following steps:
- Transform the OpenID discovery proxy HXRI into the standard HXRI necessary to receive an XRDS document back from the xri.net HXRI proxy server (see below).
- Send the request to the xri.net HXRI proxy server.
- Receive the XRDS document response and pass it back through to the original requestor.
[edit] OpenID Discovery Proxy HXRI to Standard HXRI Transformation
All this transformation requires is dropping the "openid." domain name prefix and adding the "?xrd_r=application/xrds+xml" query parameter.
Example:
http://openid.xri.net/=example.name
...becomes...
http://xri.net/=example.name?_xrd_r=application/xrds+xml
[edit] Key Implications
[edit] Effective URL
As specified above, the client library at an OpenID RP will not be able to distinguish an openid.xri.net URL from any other Yadis-enabled URL. One important consideration, though, is that the user's stored OpenID identifier at this RP will be:
http://openid.xri.net/=example.name
...where =example.name is the actual XRI. This means when the RP eventually upgrades to full XRI support, the stored OpenID identifier will change. However, when the RP does that upgrade, the user's new OpenID identifier will in fact be their i-number, so it should be relatively easy for the RP to add a routine that automatically upgrades the user's previously stored openid.xri.net URL to the user's i-number.
[edit] I-Broker OpenID Provider (OP) Code
For an openid.xri.net discovery proxy to work, each i-broker needs to modify their OpenID Provider (OP) code to accept the http://openid.xri.net/ proxy prefix. Note: when doing this, they should ALSO accept the http://xri.net/ prefix as an end-user MAY use a default service endpoint in their XRDS document that redirects to a Yadis-enabled HTML page.
[edit] Community I-Names
Another potential issue is that if an RP is running a very simple OpenID client library, and the user's i-name is a community i-name such as...
http://openid.xri.net/=example.name*subname
...this will produce an XRDS document containing two XRD elements, both of them potentially containing OpenID authentication service endpoints. A very simple OpenID client library, expecting only XRDS documents containing one XRD element, might get confused and return the OpenID service endpoint from the first XRD instead of the final XRD.
One solution to this would be for the openid.xri.net proxy to strip out all XRDs except the final one when passing through an XRDS document.
[edit] Comments?
[edit] More Detailed Query?
(EqualsWil) Couldn't openid.xri.net 't make an even more detailed query of xri.net, i.e.:
http://xri.net/=example.name?_xrd_r=application/xrds%2Bxml;sep=true;refs=true;trust=https&_xrd_t=http://openid.net/signon/1.0
(DrummondReed) Yes, that could work. One problem is that even some OpenID 2.x libraries may not implement XRI support (or do it correctly), so limiting the service type to OpenID 1.0 (which is also used by OpenID 1.1) might not be good. Tt would be ideal if using openid.xri.net always returned the full XRDS document as would be expected if the RP made a request directly to the URL for that document (given that all XRDS documents for XRIs have an actual URL). That way the openid.xri.net proxy would be transparent to the OpenID client library, i.e., the RP would not be able to distinguish an openid.xri.net URL from any other Yadis-enabled URL.
[edit] Proof-of-Concept Available
(KermitSnelson) I'm currently running a proof-of-concept implementation of this idea on my Web site. To construct an OpenID from any i-name, just append the i-name to http://subjectivity.com/, e.g.:
http://subjectivity.com/=drummond http://subjectivity.com/=kermit*business
I've tried it successfully with my own i-name on Jyte, Pibb, ma.gnolia, this wiki, and my Drupal 6 development environment. As suggested above, it supports community i-names by stripping out all but the final XRD from the returned XRDS. It already works with i-brokers because it uses OpenID delegation, making it unnecessary first to modify the i-brokers to accept the proxy prefix.
I hope this helps to conceptualize and refine the idea. Feel free to contact me at http://xri.net/=kermit with any questions or problems.
(=les 7/15/07) =kermit, thanks for adding this poc. I attempted to login to livejournal with http://subjectivity.com/=les with no success. They complained about an illegal character. I am not quote sure what that was.
(=kermit 7/16/07) Thanks, Les, for trying it out! Unfortunately, I haven't been able to reproduce the problem you reported. Logging in as http://subjectivity.com/=kermit, which is also a 2idi OpenID, at http://www.livejournal.com/openid/ works fine for me.
I noticed that your 2idi OpenID service is configured a bit differently in your XRD from mine. In particular, the "append" attribute on your URI element is set to "qxri", whereas mine is set to "none". But when I tried logging on using your XRDS (by putting a copy of it at http://subjectivity.com/=kermit*leschasen and delegating it to xri://=kermit because I don't know the password for xri://=les), it worked fine. So it can't be the "append" attribute that's doing it.
On one attempt I did get a transient error from LiveJournal: "unexpected_url_redirect". But when I tried it again, it worked. So perhaps what you saw was a transient too? Otherwise, I'm stumped.
