The Wiki, iNames and OpenID accounts

[Chasen, Les]

I think you got it but it seems rather confusing for a RP to do a
different query based on the format of the input XRI.   I am not sure I
followed what the original thread was trying to accomplish but I wonder
if an RP should only operate on the authority portion of an XRI.

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed at cordance.net]
> Sent: Monday, October 30, 2006 4:55 PM
> To: 'Kevin Turner'; general at openid.net
> Cc: Chasen, Les; Tan, William
> Subject: RE: The Wiki, iNames and OpenID accounts
> 
> 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