[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] FW: XRI openid endpoint selection
I guess the question is more for Draft 11 - which Drummond is (I think) working on as we speak. I knew this sort of issue would come up - the OpenID folks I don't think have really spent much time with the service-selection stuff and I think had assumed that their default behavior would be compliant. I have not paid much attention to the details of service selection so I didn't say anything - but I think its now time to do so since YADIS is becoming part of XRI resolution. Drummond - do the OpenID people know about the YADIS -> XRI Res transition? -Gabe -----Original Message----- From: Chasen, Les [mailto:les.chasen@neustar.biz] Sent: Tuesday, August 15, 2006 2:31 PM To: Gabe Wachob; xri@lists.oasis-open.org Subject: RE: [xri] FW: XRI openid endpoint selection 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]