RE: [xri] FW: XRI openid endpoint selection

["Chasen, Les" <les.chasen@neustar.biz>]

Not sure ...  Amsoft is using qxri for their i-services.


 

> -----Original Message-----
> From: Gabe Wachob [mailto:gabe.wachob@amsoft.net]
> Sent: Tuesday, August 15, 2006 5:17 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] FW: XRI openid endpoint selection
> 
> Since we are incorporating YADIS, is this an issue?
> 
>     -Gabe
> 
> -----Original Message-----
> From: Kevin Turner [mailto:kevin@janrain.com]
> Sent: Tuesday, August 15, 2006 11:46 AM
> To: heraldry-dev@incubator.apache.org
> Subject: XRI openid endpoint selection
> 
> [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
>