[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] HXRI as OpenID
My bad, the default is sep=true, so under the current proposal the proxy would interpret Accept: application/xrds+xml as _xrd_r=application/xrds+xml;sep=true;ref=true =wil Steven Churchill wrote: > Wil wrote: > >> ... >> interpret that as _xrd_r=application/xrds+xml;sep=false;ref=true >> >> It will then perform resolution and then does >> service selection and returns the XRDS document >> (which may contain a non-success... >> > > Nit: No service selection because sep=false. > > ~ Steve > > -----Original Message----- > From: Tan, William [mailto:William.Tan@neustar.biz] > Sent: Wednesday, April 25, 2007 12:48 PM > To: Gabe Wachob > Cc: 'Drummond Reed'; 'Markus Sabadello'; xri@lists.oasis-open.org; > andy.dale@ootao.com; 'Victor Grey' > Subject: Re: [xri] HXRI as OpenID > > This is related to issue #41 on the wiki which we just closed: > > <http://wiki.oasis-open.org/xri/Xri2Cd02/ResWorkingDraft11#head-b343e4adf430 > b88a15d8e1cceb581fa65c573719> > > I had originally proposed to make the Accept header play the singular > role of being the Resolution Media Type (_xrd_r), but was somehow > convinced that it should be Service Media Type. Now I'm back but can't > quite remember what was the argument for it. Drummond, Les, Markus? > > My arguments for *not* using it as a Service Media Type is that I > personally think Service Media Type is a lesser-used feature of service > selection. XRI-aware clients can still use _xrd_m for it, while non > XRI-aware clients will probably send fairly generic media types anyway. > > > IF the Accept header was actually the resolution media type (_xrd_r) or > even the way it is defined today, Yadis client will generally send > "Accept: application/xrds+xml" to the HXRI proxy, which will then > interpret that as _xrd_r=application/xrds+xml;sep=false;ref=true > > It will then perform resolution and then does service selection and > returns the XRDS document (which may contain a non-success status code > but I don't think Yadis client looks at it.) This way, it should work, no? > > =wil > > Gabe Wachob wrote: > >> Let me ask you this: are both approaches XRI Resolution compliant? I >> really don't like #2 because it forces users to do something new (ie >> add "openid." At the beginning) **and**, technically speaking, the >> identifier is no longer an HXRI. >> >> I'd especially prefer Markus' solution if it were still compliant with >> XRI Resolution. >> >> -Gabe >> >> ------------------------------------------------------------------------ >> >> *From:* Drummond Reed [mailto:drummond.reed@cordance.net] >> *Sent:* Tuesday, April 24, 2007 11:43 PM >> *To:* 'Gabe Wachob'; 'Markus Sabadello'; xri@lists.oasis-open.org >> *Cc:* andy.dale@ootao.com; 'Victor Grey' >> *Subject:* RE: [xri] HXRI as OpenID >> >> Markus, Gabe: >> >> Both suggestions have serious merit. Neither is perfect, but given >> that we are working the Yadis requirements into XRI Resolution 2.0 >> Working Draft 11 as we went over last week, we need to provide a clear >> answer as to how XRIs in HXRI format can work with any version of OpenID. >> >> The openid.xri.net special-proxy-address option was the one I >> discussed at breakfast last week - I don't think its very "hacky" >> since all it involves is using a known "special proxy" to modify the >> HXRI to produce an OpenID-compliant proxy request to xri.net. However >> Markus's suggestion bears serious scrutiny as it doesn't require >> i-name users to learn anything new other than what they already know >> about how to use their i-name as a URL (i.e., put "xri.net/" in front >> of it). >> >> Others on the TC: which you prefer of these two solutions to the issue >> of how i-names can be made compatible with any OpenID Relying Party, >> even if they don't have direct XRI support? Let us know by replying to >> this message whether you prefer: >> >> 1) Modifying HXRI proxy servers to provide OpenID/Yadis-compliant >> responses if no User-Agent header is present in the request. (In this >> case the proxy would return both an X-XRDS-Location header and an XRDS >> document.) >> >> 2) Using a special OpenID-enabled proxy server address such as >> openid.xri.net. (In this case the special proxy would simply add the >> query parameters to the HXRI to return an XRDS to the request, then >> redirect the request to the normal proxy server.) >> >> =Drummond >> >> ------------------------------------------------------------------------ >> >> *From:* Gabe Wachob [mailto:gabe.wachob@amsoft.net] >> *Sent:* Tuesday, April 24, 2007 1:00 AM >> *To:* 'Markus Sabadello'; xri@lists.oasis-open.org >> *Subject:* RE: [xri] HXRI as OpenID >> >> An even hackier solution might be to give your xri as >> openid.xri.net/<yourxri> (which is NOT an HXRI - it would resolve in a >> special way for ignorant OpenID 1.X RPs'). This requires user >> intervention, so it's not a really good solution. >> >> -Gabe >> >> ------------------------------------------------------------------------ >> >> *From:* markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] >> *On Behalf Of *Markus Sabadello >> *Sent:* Tuesday, April 24, 2007 12:30 AM >> *To:* xri@lists.oasis-open.org >> *Subject:* [xri] HXRI as OpenID >> >> One more thing today.. I had an idea about the problem Drummond >> mentionned during breakfast on Friday. But I am warning you, it is >> very hacky... >> >> The problem: >> Many OpenID RPs do not (yet?) support i-names. If you try to enter >> your i-name in the form of an HXRI ( e.g. http://xri.net/=Drummond), >> this does not work either, since the proxy selects the default SEP >> from the XRD, not the Authentication SEP. >> >> Maybe a solution: >> Modify the proxy to look at the User-Agent header. If it is not there, >> the request probably comes from an OpenID RP trying to do discovery. >> Both the janrain and sxip libraries do not send this header. >> >> There are many difficulties to be expected here. The proxy would have >> to display or redirect to some page that has an appropriate <link >> rel="openid.server" href="..."> element, and the Authentication >> i-service would somehow have to make sure that =Drummond and >> http://xri.net/=Drummond are actually treated as the same identity, >> not separate ones. Maybe this can be done with OpenID delegation. >> >> I am not sure if this really works, it's just an idea. >> >> Markus >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]