[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] HXRI as OpenID
Markus, Thanks for more good info – it’s
clear that acheving backwards XRI/OpenID interoperability is going to be more
challenging than we thought. I agree with you that the User-Agent
header technique, while a good suggestion, doesn’t look viable. I also agree that one of the real issues
in XRI/OpenID interoperability is synonyms, especially treating an HXRI and the
XRI it contains as synonyms. It’s ironic that the very OpenID RPs that
need HXRIs for backwards-compatability (because they are not XRI-aware) are
also the ones that won’t recognize that an HXRI contains a synonymous
XRI. However, it also true that once those RPs upgrade
to OpenID libraries that do support XRI, they *should* recognize the HXRIs they already have in their user database
– or any other special HTTP-compatible XRI we have to create for
backwards-compatability. So here’s a new proposal: rather
than try to build a special HXRI proxy server that artificially manipulates an
HXRI to produce a Yadis-compliant request, let’s say we build a special dedicated
OpenID XRI proxy server. For example, XDI.org could operate such a server at: openid.xri.net The only job of this OpenID XRI proxy
server would be to resolve any XRI sent to it in the path (just like an HXRI),
but with the correct OpenID-compatable parameters added. For example, if I
typed in the following OpenID… openid.xri.net/=drummond ...the OpenID XRI proxy server would send
the following request to the xri.net proxy server… https://xri.net/=drummond?_xrd_r=application%2Fxrds+xml;sep=true&_xrd_t=http%3A%2F%2Fopenid.net %2Fsignon%2F1.0 …and then pass the XRDS document
back to the requesting client. This of course means that the URL that
would end up in the RP’s database for me would be http://openid.xri.net/=drummond. However,
we could publish the fact that this was a special variant of an HXRI, and thus
when the RP upgrades to a version of the OpenID libraries that supports XRI,
they would recognize this special variant and replace it (not just with
=drummond, but actually with my i-number the next time I log in). What do folks think of this solution? =Drummond From: Markus Sabadello
[mailto:markus.sabadello@gmail.com] I think I confused OP and RP in my mail.. I meant RP all the time,
sorry about that. Markus On 4/27/07, Markus
Sabadello <markus.sabadello@xdi.org>
wrote: To be honest, I don't like any of these approaches. From my point of
view, the whole HXRI mechanism by itself is already a "hack", and if
we start adding even more special behaviour for Authentication, I think only
very few people will actually use it, and there are so many factors that can
break it. The obviously "correct" way to solve the problem would be
to get all OpenID implementations to support XRIs. However, IF we want to provide a way for using HXRIs as an OpenID, I
now tend to prefer the special-proxy-name solution, since recognizing an OP by
using at the HTTP Headers (User-Agent and others) seems to be too unreliable. And there may be another question that needs to be answered: What will
actually be the OpenID identifier? The HXRI or the XRI? This question
applies in both cases, the User-Agent-hack-solution and the
special-proxy-name solution. In the tests I wrote about in my last mail,
the HXRI was the OpenID identifier, which has the disadvantages, that 1) the
Authentication i-service needs to be able to recognize a HXRI, and 2) that if
you use different proxies, the OP thinks of different identities ( i.e. xri.freexri.net/=Drummond
is different from xri.net/=Drummond,
which is again different from openid.xri.net/=Drummond). It may also be possible to use the XRI as the OpenID identifier, even
if the user enters a HXRI. To achieve this, the proxy can output something like
this (I tried it): <html><head> This way, the Authentication i-services need not be changed, and the OP
would always "see" the same identity, no matter which proxy is used. But: OpenID OPs that cannot resolve XRIs by themselves also seem to not
accept them as identifiers. You get error messages like "Cannot construct
URL". I am not sure what to do. Tell OpenID library implementors to
accept i-names! And tell OpenID users that =yourname looks way cooler than http://authn.youropenidprovider.com/yourname
Markus On 4/27/07, Drummond
Reed <drummond.reed@cordance.net
> wrote: Markus, This is very good data for making a decision. So does this mean you are leaning towards a
special-proxy-name solution (e.g., openid.freexri.com, openid.xri.net, etc.)? I think of it as a special proxy for
non-Yadis-HXRI-to-Yadis-compatible-HXRI conversion. It does mean user education, and it's not a valid HXRI. The other option is to set up a special HXRI-compliant proxy
server such as xri.openid.net,
which automatically does the non-Yadis-HXRI-to-Yadis-compatible-HXRI
conversion. This still requires user education, but at least it's a complant
HXRI. Thoughts? =Drummond From: markus.sabadello@gmail.com
[mailto:markus.sabadello@gmail.com]
On Behalf Of Markus Sabadello
Okay, I just played with this a bit and now I think
the whole idea is stupid. On
4/25/07, Drummond Reed <
drummond.reed@cordance.net> wrote: I agree with Markus here that the most intuitive use for the
Accept header is for the media type that a non-XRI-aware client is looking for,
so the best mapping is to the Service Media Type, not the Resolution Media
Type. That was the decision we made last week and which I recorded in the
minutes (and the Resolution issues wiki page) as closure on issue #41. But I think just as relevant is the fact that, following
Wil's logic, even if the Accept header WAS interpreted as the Resolution Media
Type parameter, then a resolver would interpret the following Accept header
(and no other explicit XRI resolution query parameters): Accept: application/xrds+xml as _xrd_r=application/xrds+xml;sep=true;ref=true The problem is, that query doesn't solve the OpenID problem,
because from a service endpoint selection standpoint, it will select for a
triple-null service endpoint ( i.e., no Service Type, no Path (if it was just
an i-name), and no Service Media Type). That may or may not produce the XRDS
that's desired. So what we really need is a way for the proxy resolver to
sense that it is NOT being asked to do service endpoint selection, and that it
SHOULD just return the XRDS document. How do folks feel about Markus' suggestion that the absence
of the User-Agent header be used to "override" whether a redirect is
returned (after service endpoint selection is done) and instead return an XRDS
document with no service endpoint selection performed? =Drummond From: markus.sabadello@gmail.com
[mailto:
markus.sabadello@gmail.com] On Behalf Of Markus
Sabadello I think
our argument for using the Service Media Type in the Accept header was that
this most closely resembles the original idea of this header. I.e ., the client
puts whatever MIME Type it is looking for into the Accept, and the proxy does
its best to find something of that type. Even
though this might not be used often in real world applications, I think it's
the cleanest and right thing to do. In
addition, I think we discussed that clients, which want a result of type
application/xrds+xml, should be smart enough to use the _xrd_r parameter
anyway. Markus On
4/25/07, Tan, William < William.Tan@neustar.biz>
wrote: This is related to issue #41 on the wiki which we just
closed:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]