incubator-heraldry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Drummond Reed" <>
Subject RE: XRI openid endpoint selection
Date Thu, 17 Aug 2006 01:37:40 GMT
[Victor: note that I am cc'ing you for a specific reason -- see Kevin's
points about 2idi's OpenID service endpoints towards the end of this

Kevin et al, see ### inline.

-----Original Message-----
From: Kevin Turner [] 
Sent: Tuesday, August 15, 2006 11:46 AM
Subject: XRI openid endpoint selection

[If there is a list dedicated to i-services, this message likely belongs

### There is such a list, and you can subscribe to it at It's the mailing list
that goes with the I-Services Specifications (ISS) wiki at However, the focus of this list is really on feedback on
the i-services specifications produced at (Contact service,
Forwarding service, SAML authentication service, etc.), whereas your
questions are really about integration of XRI resolution functions (defined
by the XRI TC at OASIS) into OpenID and Heraldry, so I think this is as good
a forum as any. ###

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

### Understood. ###

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.  

### For the OpenID authentication use cases, I don't think either MediaType
or Path need to be involved. ###

And the append attribute has me a bit worried:

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

This goes against the recommendation in (but hey, that's
just a wiki).

### Well, it is a wiki, but it's the current authoritative source for
service endpoint metadata (it's intended to simply aggregate the info from
the different ISS specs as they are posted). And you are right, it is
recommended not to use the append="qxri" attribute for an OpenID service
endpoint. ###

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?

### I believe the former, i.e., 2idi should to comply with
IserviceEndpointDefinitions and set the URI append= attribute to "none". I
suspect the reason it's working is that your RP code just uses the URI (and
ignores the append="qxri" parameter), and 2idi's implementation of OpenID
gets the OpenID identifier from the authentication request call, which is as
it should be. ###

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?

### Right now, from an OpenID context, zero. ###

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.  

### Again, since the answer is currently "zero", I think the path of using
XRI proxy resolution in the short term is fine. ###

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

### I know Wil Tan from NeuStar, who currently is the primary maintainer of
that code and one of the Heraldry committers, has already written you
independently about this, and we're going to try to set up a telecon to
discuss OpenXRI and OpenID integration early next week. Anyone on this list
who would like to join that call, email me directly. ###

### We're also moving into full swing this week on XRI Resolution 2.0
Working Draft 11, which we want to make sure is nicely sync'd with OpenID
2.0 Draft 9. The faster we come to a full meeting-of-the-minds between the
XRI resolution folks and the OpenID folks, the faster we'll really solidify
the all-important XRDS discovery layer of the OpenID 'stack'. ###


View raw message