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


Markus,

 

This is very good data for making a decision.

 

So does this mean you are leaning towards a special-proxy-name solution (e.g., openid.freexri.com, openid.xri.net, etc.)? I think of it as a special proxy for non-Yadis-HXRI-to-Yadis-compatible-HXRI conversion.

 

It does mean user education, and it’s not a valid HXRI.

 

The other option is to set up a special HXRI-compliant proxy server such as xri.openid.net, which automatically does the non-Yadis-HXRI-to-Yadis-compatible-HXRI conversion. This still requires user education, but at least it’s a complant HXRI.

 

Thoughts?

 

=Drummond

 


From: markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Thursday, April 26, 2007 5:09 AM
To: Drummond Reed
Cc: Tan, William; Gabe Wachob; xri@lists.oasis-open.org; andy.dale@ootao.com; Victor Grey
Subject: Re: [xri] HXRI as OpenID

 

Okay, I just played with this a bit and now I think the whole idea is stupid.

PREPARATION:

I modified my xri.freexri.com proxy to look at the User-Agent header. If it is not there, the following is sent, which I think should be understood by pretty much any OP out there.

<html><head>
<link rel="openid.server" href=""[first" URI from the Authentication SEP]">
</head><body></body></html>

I also modified my authn.freexri.com Authentication i-service, so it can handle requests for HXRIs.

TESTS:

I tested the proxy with two i-names:
@free*earth*moon, using my own modified Authentication i-service; password is "lunar"
=Drummond, using the 2idi Authentication i-service;

I tested it with 4 OPs:
1. http://jyte.com/auth/login
2. http://www.livejournal.com/openid/
3. http://openid.schtuff.com/?action=login
4. https://www.hampr.com/login

At each of these sites, I entered the two i-names as HXRIs:
a. http://xri.freexri.com/@free*earth*moon
b. http://xri.freexri.com/=Drummond

RESULTS:

1.a. jyte with http://xri.freexri.com/@free*earth*moon
This actually seems to work.
Jyte says "Signed in as xri.freexri.com/@free*earth*moon"
But Jyte supports i-names anyway, so no gain here.

1.b. jyte with http://xri.freexri.com/=Drummond
Correctly takes you to the 2idi Authentication i-service, but it doesn't know what to do with a HXRI.

2.a. livejournal with http://xri.freexri.com/@free*earth*moon
Correctly takes you to the @freeXRI Authentication i-service, everything seems to be fine, but in the end Livejournal says "empty_url: Empty URL".
I have no idea why.

2.b. livejournal with http://xri.freexri.com/=Drummond
Correctly takes you to the 2idi Authentication i-service, but it doesn't know what to do with a HXRI.

3.a+b. schtuff
Doesn't work because there is a User-Agent header !!!!
User-Agent: PycURL/7.15.5

4.a. hampr with http://xri.freexri.com/@free*earth*moon
Correctly takes you to the @freeXRI Authentication i-service, everything seems to be fine, but in the end Hampr just shows a blank white screen.
I have no idea why.

4.b. hampr with http://xri.freexri.com/=Drummond
Correctly takes you to the 2idi Authentication i-service, but it doesn't know what to do with a HXRI.

OTHER

I also tried "overriding" the claimed identifier during the Authentication process, i.e. replacing "http://xri.freexri.com/@free*earth*moon " with "@free*earth*moon". The openid4java documentation says this is possible, but it didn't work a single time for me. I got all kinds of strange error messages, e.g. "Server IDs don't match".

Somehow I am running into problems with OpenID all the time. I don't know if it's me, the sxip openid4java libraries or our OpenXRI.... But I am not really an expert on OpenID.

Summary: Too many problems... I don't think it's worth the effort.. But maybe I am just frustrated because it did not work and someone else has better ideas :)

-Markus

On 4/25/07, Drummond Reed <drummond.reed@cordance.net> wrote:

I agree with Markus here that the most intuitive use for the Accept header is for the media type that a non-XRI-aware client is looking for, so the best mapping is to the Service Media Type, not the Resolution Media Type. That was the decision we made last week and which I recorded in the minutes (and the Resolution issues wiki page) as closure on issue #41.

 

But I think just as relevant is the fact that, following Wil's logic, even if the Accept header WAS interpreted as the Resolution Media Type parameter, then a resolver would interpret the following Accept header (and no other explicit XRI resolution query parameters):

 

  Accept: application/xrds+xml

 

as

 

  _xrd_r=application/xrds+xml;sep=true;ref=true

 

The problem is, that query doesn't solve the OpenID problem, because from a service endpoint selection standpoint, it will select for a triple-null service endpoint (i.e., no Service Type, no Path (if it was just an i-name), and no Service Media Type). That may or may not produce the XRDS that's desired.

 

So what we really need is a way for the proxy resolver to sense that it is NOT being asked to do service endpoint selection, and that it SHOULD just return the XRDS document.

 

How do folks feel about Markus' suggestion that the absence of the User-Agent header be used to "override" whether a redirect is returned (after service endpoint selection is done) and instead return an XRDS document with no service endpoint selection performed?

 

=Drummond

 


From: markus.sabadello@gmail.com [mailto: markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Wednesday, April 25, 2007 9:52 PM
To: Tan, William
Cc: Gabe Wachob; Drummond Reed; xri@lists.oasis-open.org; andy.dale@ootao.com; Victor Grey
Subject: Re: [xri] HXRI as OpenID

 

I think our argument for using the Service Media Type in the Accept header was that this most closely resembles the original idea of this header. I.e., the client puts whatever MIME Type it is looking for into the Accept, and the proxy does its best to find something of that type.

 

Even though this might not be used often in real world applications, I think it's the cleanest and right thing to do.

 

In addition, I think we discussed that clients, which want a result of type application/xrds+xml, should be smart enough to use the _xrd_r parameter anyway.

 

Markus
 

On 4/25/07, Tan, William <William.Tan@neustar.biz> wrote:

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]