incubator-heraldry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Turner <ke...@janrain.com>
Subject XRI openid endpoint selection
Date Tue, 15 Aug 2006 18:45:52 GMT
[If there is a list dedicated to i-services, this message likely belongs
there.]

Currently, while Yadis-enabled consumers do select an endpoint from an
XRD document, they use a very simplified form of XRI resolution endpoint
selection.  They only match on the Type element, ignoring MediaType and
Path, do not honor "select" or "match" attributes, nor the URI/append
attribute.

Now under development are XRI-enabled consumers, and they're inheriting
from that Yadis code.  I'm wondering how much of the above they need to
implement.  Some of those, e.g. MediaType, I am not much worried about.
I believe it is in no case required when querying for an OpenID server.
Others, like Path, I am less sure.  And the append attribute has me a
bit worried:

I-names served by 2idi.com today have append="qxri" set.

This goes against the recommendation in
http://iss.xdi.org/moin.cgi/IserviceEndpointDefinitions (but hey, that's
just a wiki).

As far as I know, no existing RPs *do* honor that attribute and append
the qxri to the URI, but it seems to work anyway.  But who is right
here?  Is 2idi non-compliant for publishing entries that do not conform
to IserviceEndpointDefinitions, or are our RPs non-compliant for not
appending to the URI?

Even if we can specify that all OpenID service entries have URI
append="none", how many of those other attributes do I have to implement
code for?

If the answer is not "zero", the hope of "you needn't write XRI
resolution code, you can use the proxy resolver" is looking less and
less bright.  But perhaps there is code from openxri that can be ported?
(The mailing list is silent, as is the web site, but there actually is
some activity in their CVS repository at sf.net.)

Thanks,

 - Kevin



Mime
View raw message