The Wiki, iNames and OpenID accounts

Tue Oct 31 04:12:10 UTC 2006

Good point, Les. It's a tradeoff between:

* Enabling forwarding XRIs to be used as OpenID login identifiers but having
RP client libraries need to make a different resolution call depending on
whether the XRI contains a path or not, and...

* Ignoring local paths on XRIs used as OpenID login identifiers (which means
not supporting forwarding XRIs) but having one standard XRI resolution call.

Do folks on the list have any strong leanings?

=Drummond 

-----Original Message-----
From: Chasen, Les [mailto:les.chasen at neustar.biz] 
Sent: Monday, October 30, 2006 6:08 PM
To: Drummond Reed; Kevin Turner; general at openid.net
Cc: Tan, William
Subject: RE: The Wiki, iNames and OpenID accounts

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