[OpenID] Directed Identity vs. "what the user typed"

[Martin Atkins]

John Panzer wrote:
> On Mon, Mar 23, 2009 at 10:10 PM, Andrew Arnott <andrewarnott at gmail.com> wrote:
>> The user part is never sent to the OP, regardless of the RP's
>> implementation.  Discovery is performed with an HTTP GET on either
>> user at domain.com or domain.com.
> 
> Not clear on whether OpenID normalization requires stripping the user@
> part, but notionally user at domain.com/ is a valid URI and could be used
> for discovery.
> 
> Discovery results in the OP endpoint URI and
>> an identifier_select claimed identifier.  The RP then redirects the user,
>> not to domain.com, but to the OP endpoint, which could be anywhere, and
>> certainly does NOT include the user@ portion because the redirect is
>> determined by the OP's advertised OP endpoint via their XRDS document.
> 
> The XRDS document could be generated dynamically based on the $USER
> variable, thus incorporating the data as an argument to the OP
> endpoint.  This would of course rule out a static XRDS file.
> 

Unfortunately this only worsens the problem that providers don't want to 
put weird OpenID craziness at the root of their main domain. They're 
already jumping through hoops to avoid serving an XRDS document there, 
and won't add LINK elements or headers because that would make the 
response bigger and thus add latency. I think it'd be a tough sell to 
get Yahoo! to support Basic auth on their home page!

By the way, the "user at password:" portion is not permitted in an http: 
URL per the specification. Some UAs support it, but the spec has the 
following production for the http: URL scheme:

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

It does not go on to define "host" to optionally include the username 
and password.

I would therefore be skeptical that this is implemented interoperably, 
as even if you do implement it it's not defined how you actually figure 
out what HTTP authentication scheme to use.