[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] FW: XRI openid endpoint selection
We need compliance for interoperability. I-name users who set up their authorities strategically (with respect to Refs and Service Selection) are correct to expect that applications using i-names exhibit consistent resolution behavior. (What is a standard for otherwise?) We should push for compliance. ~ Steve > -----Original Message----- > From: Gabe Wachob [mailto:gabe.wachob@amsoft.net] > Sent: Tuesday, August 15, 2006 3:43 PM > To: xri@lists.oasis-open.org > 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]