OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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-b343e4adf430b88a15d8e1cceb581fa65c573719>

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]