Re: Adding user@ to HTTP[S] URIs

[Rick van Rein <[e-mail]>]

Hi Amos,

We mostly agree, except that I think we should not force-bind client
authentication to the userinfo indication in the URI authority, which I
read to be intended as a resource name space in RFC 3986:

3.2.  Authority

   Many URI schemes include a hierarchical element for a naming
   authority so that governance of the name space defined by the
   remainder of the URI is delegated to that authority (which may, in
   turn, delegate it further).  The generic syntax provides a common
   means for distinguishing an authority based on a registered name or
   server address, along with optional port and user information.

>>>> Most protocols support users under domain names, but HTTP does not.
> 
> This is incorrect. userinfo@ is part of the generic URI format, so it
> must still be supported by http:// URL parsers. The difference is that
> the client is expected to map the section into data sent in another way.

I agree, but was nonetheless correct: HTTP is the protocol and it does
not support users as an explicit concept.

> A client is forbidden from *sending* the userinfo@ on-wire.

Yes, that is what the spec of the "Host" header says.

>> Having a place to specify user name syntax and semantics is a good
>> example.
> 
> Those rules already exist for the initiel userinfo@ section. The core of
> all these issues is that they are not being obeyed by software in reality.

Software cannot obey it, in lieu of a place for userinfo in the HTTP
protocol!  Authentication headers are *not* the place for it, as those
propose a client identity, while the userinfo in the HTTP URI signifies
a resource name space.

> Also please be aware that the latest HTTP versions 2+ do not send their
> URL as a single text string.

Thanks.

>> These could be consistently represented as
>> 	https://[e-mail]
>> 	https://[e-mail]
>> 	https://[e-mail]
>> 	https://[e-mail]
>> 	http://[e-mail]/esr
>> 	http://[e-mail]
>>
> 
> These are valid URLs today - all have the same value:

I do not know how to send them -- other than through abuse of the Basic
authentication mechanism, which is intended to relay a client identity,
rather than refine the resource name space offered by the server.

>> I pioneered this idea with a crude hack based on Basic authentication,
>> which is highly inconsistent across browsers because Basic and Digegst
>> have always misinterpreted the URL userinfo as authentication names,
> 
> That is not a misinterpretation. The content is site-specific. If a site
> has URLs with userinfo@ *and* challenges for authentication credentials,
> then it is reasonable for the field to be interpreted as the answer to
> the challenge.

I disagree that this is reasonable to prescribe in the HTTP standard.

There are certainly use cases, namely when I want to address my own
records, and the ACL on the server can happily configured that way.

But doing this always, so force-binding client authentication to the
userinfo in the HTTP URI, I could not allow others into my part of the
site, which is a pretty dramatic reduction of HTTP expressiveness.  I
believe separating client identity and server users makes a lot of sense.

FWIW, I don't care about old-fashioned Basic and Digest authentication,
but about the separation of client identity and resource name spacing.


Thanks,
 -Rick