The Wiki, iNames and OpenID accounts

[Drummond Reed]

Kevin,

You nailed it. I was just discussing this with Les Chasen this morning and
we had narrowed it down to this exact area.

It boils down to this: if the XRI entered at the RP includes a non-empty
local component (i.e., a path, a query, or both), then the call for XRI
resolution to a proxy resolver needs to be slightly different than if the
XRI includes just an authority segment. In fact, the XRI Resolution editors
ran across this exact use case in preparing Working Draft 10
(http://www.oasis-open.org/committees/download.php/17293) and specified the
solution in section 7.6. Here's how it works:

* For an XRI consisting of just an authority segment, the normal XRI
resolution call for an OpenID RP would be to request a resolution media type
(_xrd_r parameter) value of "application/xrds+xml" with the service endpoint
selection parameter (sep) set to "false" (or omitted, same result). 

* However if the XRI includes a local component, the XRI resolution call
should set the _xrd_r parameter value to null (or just omit it - same
result), and instead set the service media type (_xrd_m parameter) value to
"application/xrds+xml". The lack of a specified resolution type means the
proxy resolver MUST: 

a) Do service endpoint selection (which, if other parameters are not
present, will just use the path component of the XRI), and

b) Issue a redirect to the selected service endpoint URI with the Accept
header set to the value of the xrd_m parameter, i.e.,
"application/xrds+xml".

That should produce exactly the result Avery intended.

I'm cc'ing Les and Wil Tan, lead of the OpenXRI work, to make sure they are
in sync with this.

Again, Kevin, thanks for pointing out exactly what's involved here. It is
indeed one of those edge cases.

=Drummond 

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Kevin Turner
Sent: Monday, October 30, 2006 12:06 PM
To: general at openid.net
Subject: Re: The Wiki, iNames and OpenID accounts

> AG> 1) As http://xri.net/=avery/(+myopenid) resolves to
> AG> aglasser.myopenid.com - shouldn't this work as a valid OpenID
> AG> Identity URL?

I think the answer would normally be yes, but you've stumbled on to a
weird intersection of Yadis and the xri.net resolver interface.

Here's what's going on:

You've entered an identifier starting with 'http://', so the RP is
treating this as a URI.  It goes to do Yadis discovery on it, and issues
a HTTP request with an XRDS content type, because Yadis uses XRDS files.

xri.net, on the other hand, is not exactly your average URL forwarding
service like, say, OCLC's PURL service is.  It's an XRI proxy resolver.
So when it gets this HTTP request, it does *not* just issue the redirect
to aglasser.myopenid.com that you expect, it checks its inputs and says
"oh, I shouldn't issue a redirect here, this is an XRI resolution client
that wants an XRDS document."  This is all according to plan as
specified in section 4.2 of the XRI Resolution specification (v2.0 WD
10).  Since service endpoint selection has *not* been requested and XRDS
output *has*, it returns the XRDS for =avery.

Now the OpenID RP receives this document, says "ah-hah, it is an XRDS,
and the XRDS has an OpenID endpoint defined in it, Yadis discovery was
successful!" and goes on to use that service endpoint with the URI you
entered as your identifier.

> AG> 2) If the answer to #1 is yes, shouldn't I be able to use
> AG> =avery(+myopenid) as a valid iname for authenticating to the wiki?

If you enter =avery/(+myopenid), the RP code treats your identifier as
an XRI and asks the proxy resolver to do service endpoint selection on
that XRI, specifying an OpenID service endpoint type.  I don't
understand how the XRI's path component influences service endpoint
selection well enough to say for certain what's supposed to happen in
this case, but what it currently does is returns the full XRDS for
=avery.

See also the August 15th thread on Heraldry-dev, "XRI openid endpoint
selection".  ( http://xrl.us/svnu ), and the following conference call
(no archives, need to pick brains).

Cheers,

 - Kevin


_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general