Subject: Adding user@ to HTTP[S] URIs

From: Rick van Rein <[email-masked]>
Date: Fri, 24 Jan 2020 23:59:56 +0100

Hello,

I wrote a draft to support http://[email-masked] in HTTP / HTTPS URIs.
The user is part of resource name space selection, and is not related to
client authentication.  It is given its own "User" header field.

I am aware that this URI form is banned in RFC 7321, Section 2.7.1, last
paragraph, but explain in issue #278 that this is unjustified:
http://github.com/httpwg/http-core/issues/278

Feedback welcomed.

Rick van Rein
InternetWide.org

-------- Original Message --------
Subject: New Version Notification for draft-vanrein-http-unauth-user-02.txt
Date: Fri, 24 Jan 2020 13:54:31 -0800
From: [email-masked]
To: Rick van Rein <[email-masked]>

A new version of I-D, draft-vanrein-http-unauth-user-02.txt
has been successfully submitted by Rick van Rein and posted to the
IETF repository.

Name:		draft-vanrein-http-unauth-user
Revision:	02
Title:		User Names for HTTP Resources
Document date:	2020-01-24
Group:		Individual Submission
Pages:		5
URL:
https://www.ietf.org/internet-drafts/draft-vanrein-http-unauth-user-02.txt
Status:
https://datatracker.ietf.org/doc/draft-vanrein-http-unauth-user/
Htmlized:
https://tools.ietf.org/html/draft-vanrein-http-unauth-user-02
Htmlized:
https://datatracker.ietf.org/doc/html/draft-vanrein-http-unauth-user
Diff:
https://www.ietf.org/rfcdiff?url2=draft-vanrein-http-unauth-user-02

Abstract:
   Most protocols support users under domain names, but HTTP does not.
   Usage patterns in the wild do suggest a desire to have this facility.
   This specification defines a header for user names, orthogonal to any
   authentication or authorisation concerns.

---

From: Michael Toomim <[email-masked]>
Date: Fri, 24 Jan 2020 15:58:50 -0800

Hi Rick!  I find this interesting, so thank you for the proposal.

> Most protocols support users under domain names, but HTTP does not.

Well, it *does* support users within the "path" part of the URL.  For instance, here's a page I just made for you, that's scoped to my user account:

    https://invisible.college/@toomim/hello-rick

> Usage patterns in the wild do suggest a desire to have this facility.

I didn't see any example usage patterns in the internet draft.  Can you provide some of them, so that we know what we are working with?

Thank you!

Michael

> On Jan 24, 2020, at 2:59 PM, Rick van Rein <[email-masked]> wrote:
> 
> Hello,
>

---

From: Rick van Rein <[email-masked]>
Date: Sat, 25 Jan 2020 12:02:17 +0100

Hi Michael,

Thanks for your positive response.

>     https://invisible.college/@toomim/hello-rick

These patterns are common, examples below, and that's why I believe that
we should support mapping users into the HTTP space.  It is useful if
the pattern can be consistent among servers, and in comparison with
other protocols, I think.  HTTP is missing that part of URL syntax.

Having a place to specify user name syntax and semantics is a good
example.  This can help to squash numerous attacks that may be tried
with the generic path-based format that you are showing.  We can then
restrict the grammar to that of a utf8-username in RFC 7542 and thus
exclude spaces, ":" and "@" and other junk and have it enforced (!) at
the HTTP level instead of in scripted applications of varying quality.

> I didn't see any example usage patterns in the internet draft.  Can you provide some of them, so that we know what we are working with?

There are many examples of the URL-mapped form like you proposed, and
they seem to be telling that people (or groups) want to represent their
online identity in an HTTP URL.  They cannot be interpreted as user
names, and code to access it ends up with in-situ coding.

Conventionally structured mapping,
	https://www.cabrillo.edu/~rnolthenius/

Site-specific structure,
	https://nlnet.nl/people/leenaars.html
	https://people.utwente.nl/m.vankeulen
	https://www.facebook.com/dssvtartaros/

Unstructured mappings,
	http://catb.org/esr/
	http://rick.vanrein.org

These could be consistently represented as
	https://[email-masked]
	https://[email-masked]
	https://[email-masked]
	https://[email-masked]
	http://[email-masked]/esr
	http://[email-masked]

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,
	http://[email-masked]
	http://[email-masked]
	http://[email-masked]

I can include some examples in the next draft, no problem.

Thanks,
 -Rick

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 26 Jan 2020 01:38:55 +1300

>>> 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.

A client is forbidden from *sending* the userinfo@ on-wire.
Implementation differences in remote parser is where problems start
occuring.

> the HTTP level instead of in scripted applications of varying quality.

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.

Also please be aware that the latest HTTP versions 2+ do not send their
URL as a single text string. It is broken down into a set of fields sent
in headers. So the parsing related issues are no longer such a bad
concern there. However that also means that any new URI part must be
sent as a header anyway - which is no different in HTTP than pulling
username from a (Proxy-)Authorization header.

> 	https://[email-masked]

These are valid URLs today - all have the same value:

1) the typically seen absolute URL:

   http://[email-masked]/

2) path delimiter is optional for empty paths

   http://[email-masked]

3) relative hostname is valid in some DNS domains

    http://exmaple.com@localhost

4) dotless cc-TLS is also valid hostname

    http://exmaple.com@local

5) on-wire URLs:

   http://local
   http://localhost
   http://localhost.local

> 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.

Amos

---

From: Rick van Rein <[email-masked]>
Date: Sat, 25 Jan 2020 14:48:40 +0100

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.

> 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.

>> example.

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.

> URL as a single text string.

Thanks.

> 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.

> then it is reasonable for the field to be interpreted as the answer to

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

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 25 Jan 2020 16:18:46 +0100 (CET)

On Sat, 25 Jan 2020, Rick van Rein wrote:

> 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.
>
> 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.

You can't fix this simply by saying that setting the name part of the userinfo 
in a HTTP URI is OK. HTTP has no established way to send a user name outside 
of authentication. I think I understand what you want, but I can't see how you 
can retrofit that into current HTTP. I'm believe you've missed that train. You 
can't just send the user name in a HTTP request.

User names are only used in HTTP for authentication.

-- 

  / daniel.haxx.se

---

From: Rick van Rein <[email-masked]>
Date: Sat, 25 Jan 2020 16:59:19 +0100

Hi Daniel,

> You can't fix this simply by saying that setting the name part of the
> userinfo in a HTTP URI is OK. HTTP has no established way to send a
> user name outside of authentication.

Exactly.  That's why I started this thread with an Internet Draft,
https://datatracker.ietf.org/doc/draft-vanrein-http-unauth-user/

For http://[email-masked]/index.html it sends

GET /index.html HTTP/1.1
Host: example.com
User: john

Cheers,
 -Rick

---

From: Paul Vixie <[email-masked]>
Date: Sat, 25 Jan 2020 02:14:47 +0000

noting, i have used https://family.redbarn.org/~vixie/ as a base URL for 
private document sharing for many years now. apache has always supported it, 
as well as nginx, and the original web server that apache was a patch set for. 
i think the industry would benefit from standardizing that rather than 
creating something new like https://[email-masked]/ -- is there a 
problem being solved here that's different from making this functionality 
reliable across vendors?

---

From: Rick van Rein <[email-masked]>
Date: Sun, 26 Jan 2020 10:59:38 +0100

Austin Wright wrote:

> I think what the http-wg list is saying is, while the feature could be defined and standardized, user-agents cannot be obligated to support it.

I know, but this kind of thinking is always hindering HTTP progress or,
more in general, the development of any client/server protocol in use.
This style of thought is not helpful during innovation, I think.

Note that what I am tackling here is based on misinterpretation of
RFC3986, so it is a bug that ought to be fixed.  Also note that nothing
is breaking by adding this facilty, only enforcing its use could.

Users who do have a compliant user agent can immediately experience the
benefits for their own use, against their own sites.  That might be
their own IDP, but the support might explode when large providers
support it, as in https://[email-masked] for access to webmail.

Thanks,
 -Rick

> Consider: If a user clicks on your link, some user agents will send:
> 
> GET /index.html HTTP/1.1
> Host: example.com
> User: john
> 
> And others will send (because they choose not to implement the feature):
> 
> GET /index.html HTTP/1.1
> Host: example.com
> 
> So what functionality is this offering, if servers can’t rely on user agents sending the header?
> 
> There’s an easy solution, just put it in the hier-part:
> 
> http://example.com/~john/index.html
> 
> Or maybe define a standard that allows the _server_ to specify: “URIs of this format <http://example.com/~{user}/> belong to the specified user”
> 
> Austin Wright.
> 
> 
>> On Jan 25, 2020, at 08:59, Rick van Rein <[email-masked]> wrote:
>>
>> Hi Daniel,
>>

---

From: Rick van Rein <[email-masked]>
Date: Sun, 26 Jan 2020 11:07:47 +0100

Hey,

The lively response to my proposal to interpret the user name in the
HTTP/S URI as intended in RFC3986 (namely for resource name scoping and
recognising its orthogonality to authentication/authorisation) may be
indications that I need to be clarify the idea.

I published version 03 of the draft, adding an example HTTP session.  It
demonstrates how a shared group account can be accessed by a member
under an ACL that is local to the server,

https://tools.ietf.org/html/draft-vanrein-http-unauth-user-03#section-4

I hope this helps!

Cheers,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Sun, 26 Jan 2020 11:19:55 +0100

Hi Paul,

> i think the industry would benefit from standardizing that

Yes, it is good to have something standardised.

> rather than 
> creating something new like https://[email-masked]/

But that is *not* new, it is what URIs are designed to do :)
and it is logical, other protocols use the [email-masked] format too.
Precisely why it is part of the URI specification, to draw one line.

-Rick

---

From: Julian Reschke <[email-masked]>
Date: Sun, 26 Jan 2020 12:01:33 +0100

On 26.01.2020 11:07, Rick van Rein wrote:
> ...

The example indeed helps.

I also understand that you like and prefer putting a username into the
authority part. What I don't get is how this enables things that weren't
possible before. It would be good to understand how this could be
deployed in practice in an environment where you don't control
implementations.

For instance, in your first step where Mary opens
"https://[email-masked]/docs" - what happens if the UA does not
implement it? Or in a subsequent step, what happens if the server
ignores the new header field?

Best regards, Julian

---

From: James Fuller <[email-masked]>
Date: Sun, 26 Jan 2020 12:18:02 +0100

> This style of thought is not helpful during innovation, I think.

If I understood correctly, what is being proposed is instead of (using
prev response examples):

  https://family.redbarn.org/~vixie/
or
  https://family.redbarn.org/@vixie/

one may perform an HTTP request with either of the following:

  https://[email-masked]
or
  GET /index.html HTTP/1.1
  Host: family.redbarn.org
  User: vixie

> is breaking by adding this facilty, only enforcing its use could.

what a URI can and cannot be (or should be) is a minefield with
respect to specifications vs what we have in the 'real world' eg. a
mixture of interpretation from several specs, what the major browser
vendors support with a dash of adhoc. A few years back Daniel Stenberg
overview still applies:

  https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/

I only mention this link because your spec seems to imply that URI (as
a technology) have a single, stable, canonical specification
describing behaviour from which we can incrementally define/refactor
new behavior from... that is not the case.

> support it, as in https://[email-masked] for access to webmail.

I think I completely understand the rationale for your proposal ...
just 'old man cranky' on the reality of adopting such a change.

Some observations:

The userinfo section is optional with scope and context related to the
denoted host ... as prev mentioned should not be transmitted.

   authority = [userinfo@]host[:port]

In HTTP we often conflate the 'User' of a software system/application
as equiv to a 'user' against a specific host in terms of an HTTP
conversation ...  though the semantics are important eg. links, logs,
search engines will hover up such information. That may create an
unpredicted new burden to redact (for privacy or security purposes) or
assist in replay (where Authorization headers are being stripped).
Then I wonder what should happen when User: Mary1 has an authorisation
with user="mary" ... having such drift may confuse things.

It is not obvious how this change might affect idempotency eg. what
happens when Mary gets a different document then John based on routing
with the new User: header. Existing servers, clients, cache (middle
box or otherwise) may have to cater for this change.

URI's are 'forever' and used in a lot (a lot) of different places ...
eg. what happens if a URI identifying a resource is then used
(unintentionally) in some other technology (semweb, rdf triple,
namespaces, etc etc etc) ...  it may not be in scope to define that
behaviour but might be worth thinking a bit beyond a 'browser hitting
a web server' type of use case.

(no doubt due to my own ignorance) I struggle to see the benefits over
using existing 'machinery' and there maybe 'dragons' ...

,Jim

---

From: Rick van Rein <[email-masked]>
Date: Sun, 26 Jan 2020 12:20:00 +0100

Hi Julian,

> The example indeed helps.

Thanks :)

> What I don't get is how this enables things that weren't
> possible before.

Compatibility with other protocols: You cannot copy/paste your gmail address to your browser to access it as webmail.  You and I may know this /~username habit, but for many out there it is going to be really helpful to use the consistency in patterns.

Consistency across servers: Even though Apache and Nginx all are capable of doing /~username and /@username and /people/username, there is a lot of variation, and that is not helpful with automation.  It would be really nice if I could take any email or XMPP address and try it as a web address without knowing a site's local habits.  Even when the [email-masked] notation gets translated.

Correct use of RFC3986 is another habit that I think deserves some warmth.

> It would be good to understand how this could be

When people see this work, they are going to ask for it, I'm pretty sure of that.

> ignores the new header field?

Initially this will be locally useful, as in this example.  I expect it to spread soon, as it is easy and convenient.  I have come across a few people who care for convenience in browser interaction ;-)

-Rick

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 27 Jan 2020 04:07:55 +1300

On 27/01/20 12:20 am, Rick van Rein wrote:
> Compatibility with other protocols: You cannot copy/paste your gmail address to your browser to access it as webmail.

Counterpoint: I (and many, many others) cannot do that even with your
spec change because the login to my gmail account is a name and domain
completely different to the email address URI. A government department
is the credentials authority - not Google or [email-masked]'.

AYJ

---

From: Matthew Kerwin <[email-masked]>
Date: Mon, 27 Jan 2020 10:21:45 +1000

Adding to Amos's point, have you looked at RFC 7033/WebFinger as a starting
point for standardised URL patterns, and account/identity discovery?

Matthew Kerwin

On Mon., 27 Jan. 2020, 01:22 Amos Jeffries, <[email-masked]> wrote:

> > Compatibility with other protocols: You cannot copy/paste your gmail
> address to your browser to access it as webmail.
>

---

From: Rick van Rein <[email-masked]>
Date: Mon, 27 Jan 2020 13:02:32 +0100

Hi James,

Thanks for your cautious response.

> If I understood correctly, what is being proposed is instead of (using

Not instead of, but in addition to.  I have no quarrel with existing
habits, I just want also be able to express things with more semantics,
with broader validity.

The treatment of user identities does not add something that cannot also
be done under other conventions.  However, these other conventions are
local, and tighten the relations between parties and reduce the
opportunity for automation, for being systematic, for solving things
over a broad range.

My angle on this is from architecting an identity model that spans more
protocols than just the web.  Every time I look at HTTP, it seems to
have invented its own wheels and not be willing to mingle with the other
protocols.  That is the kind of problem for which I would like to have
handle bars, instead of being forced into local conventions that are
meaningful to a server but leave the client unaware of meaning.

> respect to specifications vs what we have in the 'real world'

I suppose the question is if there is any concrete mine below the lines
I've written.  There are surely problems but I wonder if any apply here.

> just 'old man cranky' on the reality of adopting such a change.

I think a proposal that creates new corners for use of HTTP is helpful
on its own.  The risk, if we only look at overall domination, is that we
enslave ourselves to a few very large corporations and basically give up
our control over Internet technology.  Said the innovator, who also
happens to be old :)

> denoted host ... as prev mentioned should not be transmitted.

Should not be transmitted as part of the Host header, indeed.  I also
found that everyone is welcome to define a new header :)

> with user="mary" ... having such drift may confuse things.

In the example I gave, they are identities from different name spaces;
and they are linked by the server, presumably through some kind of ACL.
That ACL would say things like "Mary1" is the resource being addressed,
and it accepts/rejects users who authenticated as "mary".  ACLs tend to
be pretty accurate in linking resources and users ;-)

This decoupling is at the heart of my reasoning.  It makes sense in most
of the protocols, but HTTP has, probably due to Basic/Digest
authentication, gotten them mixed up.

> with the new User: header.

Idempotency means that doing the same thing again has no added effect.
What does that mean here?

> Existing servers, clients, cache (middle

Please let me know if the cache solution in the proposal is incomplete.
 Please let me know if the statement that a server may ignore the User:
header (and presumably present a fallback page) is insufficient.  Please
let me know whatever concrete issue you are seeing that I missed!

> URI's are 'forever' and used in a lot (a lot) of different places ...

I think this is your assumption that I would abolished existing
patterns.  Far be it from me to stop anyone from doing anything that
they have grown accustomed to, or fallen in love with.  I would however
like to have an alternative path that offers more semantics, and that
may very well be an alias to the existing practice.  (I actually coded
the User: header into Apache's mod_userdir as an alias.)

> using existing 'machinery' and there maybe 'dragons' ...

Please introduce me to any dragons you encounter; this caution alone
does not seem cause for action yet.

Thanks,
 -Rick

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 27 Jan 2020 13:22:16 +0100 (CET)

On Mon, 27 Jan 2020, Rick van Rein wrote:

> Please introduce me to any dragons you encounter; this caution alone does 
> not seem cause for action yet.

Maybe not a dragon, but...

$ curl foo@localhost -v
...
> GET / HTTP/1.1
> Host: localhost
> Authorization: Basic Zm9vOg==

... because userinfo in HTTP has only ever been there and used for 
authentication.

(Zm9vOg== is "foo:" base64 encoded)

-- 

  / daniel.haxx.se

---

From: Rick van Rein <[email-masked]>
Date: Mon, 27 Jan 2020 13:22:38 +0100

Hi,

> is the credentials authority - not Google or [email-masked]'.

You are actually _making_ my point :)

The [email-masked] represents a resource according to the URI
specs.  Some HTTP implementations have forcefully tied it to
Basic/Digest authentication.  My point is that the authentication
pathway needs a completely different pathway.

In the spec, I used an example with just a username, but this line of
thinking easily extends to allowing forms like [email-masked] as well.

The next step, and now I'm really warming up, is to allow the gmail
server to authenticate amos under the realm of jerffri.es.  That is
possible with these other drafts I've posted last week:

HTTP Authentication with SASL
https://datatracker.ietf.org/doc/draft-vanrein-httpauth-sasl/

Realm Crossover for SASL and GSS-API via Diameter
https://datatracker.ietf.org/doc/draft-vanrein-diameter-sasl/

This architecture allows you to authenticate to gmail.com with your
credential hosted at your example domain jeffr.es.

Point of order: This is a lot extra and we should not discuss it in this
thread; there are other threads and other WGs for the other specs.  I
only mention them here to answer the recurring "why" to the call for
more semantics and better separation of user names in resources and
authentication.  I hope it serves to show that this is not a frivolity.

Cheers,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Mon, 27 Jan 2020 13:29:36 +0100

Hi,

Thanks for a technical point, Daniel!

> (Zm9vOg== is "foo:" base64 encoded)

Browsers have no consistency in this usage pattern, so this is definately a niche.  As a result, nobody would publish such a URI for global purposes, and so there is room to define adaptations to the behaviour.

This Basic hack might be turned into an option, or my draft's form might be; a migration path can easily be started as well.  This is not unexpected when assumptions are made beyond the specs.  Assumptions which, by the way, are the result of wanting to express something for which there is no semantics in the form of a specification.

-Rick

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Jan 2020 13:32:51 +0100

> pathway needs a completely different pathway.

"[email-masked]" is not a URI; it lacks a scheme. It can be an URI
*reference* which would need a base URI to resolve against.

Best regards, Julian

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 27 Jan 2020 13:40:51 +0100 (CET)

On Mon, 27 Jan 2020, Rick van Rein wrote:

> Browsers have no consistency in this usage pattern, so this is definately a 
> niche.

Yes, but a niche with potentially a large amount of users.

And in fact, it sends the user name without a password in a HTTP header, which 
is... well, what you ask for. =)

> As a result, nobody would publish such a URI for global purposes,

Then again URIs aren't globally defined so they can in fact not be used "for 
global purposes" - period. I keep this incomplete list of interop issues for 
the fun of it: https://github.com/bagder/docs/blob/master/URL-interop.md

The best we can do right now is global purposes **with a certain subset of 
tools**.

The userinfo part of a URI/URL in particular has notoriously bad interop 
properties.

> and so there is room to define adaptations to the behaviour.

I appreciate your optimism!

-- 

  / daniel.haxx.se

---

From: Rick van Rein <[email-masked]>
Date: Mon, 27 Jan 2020 13:46:23 +0100

Hey Daniel,

> it sends the user name without a password in a HTTP
> header, which is... well, what you ask for. =)

Meh.  Just the minor, technical part.  It fails to separate the
authentication user from the resource user.

Actually, the current proposal was woven into HTTP SASL, as a "userview"
variable.  The whole reason I wrote this new spec is to get it out
there, because it provided clutter and obscured the clarity of the
authentication concept.

> I appreciate your optimism!

:)

-Rick

---

From: Rick van Rein <[email-masked]>
Date: Mon, 27 Jan 2020 13:58:03 +0100

Hey Matthew,

I know about WebFinger.  It is one indication that there is a real need for user name semantics in HTTP.  It is, however, very much a web-only solution which for our work in support of identity across the board is too limited and too limiting.

-Rick

---

From: Rick van Rein <[email-masked]>
Date: Mon, 27 Jan 2020 14:34:57 +0100

Hey,

I think compatibility with the Basic/Digest pattern is actually quite easy.

>
>>
>> Browsers have no consistency in this usage pattern, so this is
>> definately a niche.
>
>

Let's split those hairs; there is a clear distinction:

1. https://john:[email-masked]

2. https://[email-masked]

The 1. form is deprecated in RFC 3986 but, like so often, is popular for
quickfixes (that then to roll into production).  It is clearly
different from the 2. form because of the (RFC-abolished) colon.

The 2. form is less useful for password-based access with Curl, I'd say.
 It would start user interaction, which is pretty much what the 1. form
wants to avoid.  This is perfectly suitable for the User: header, which
never includes a colon.

If the 2. form is initially passed as User: header, the server either
recognises it and its ACL triggers the Basic/Digest interaction, or the
server does not recognise it, detects lacking authorisation and
explicitly triggers HTTP authentication, for instance Basic/Digest
interaction.  This is for servers that want authorisation; what the
User: header enables extra is to use the user name as a part of the
resource location.

You suggested it the other way around, which is certainly not workable
in general; I tried that.  Also, it mixes up authentication and resource
selection, which the modified form of the previous paragraph does not do.

If I didn't overlook things here, the two usage patterns can co-exist.
That means that the option to distinguish the forms may not even be
necessary, as long as the Basic/Digest submission may be part of a 2nd
round after being challenged.  It is up to the client whether it asks
for a password if that happens, and whether the user can still change
the uid from "sales" into "mary" (to reference the I-D example).

Cheers,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Mon, 27 Jan 2020 14:54:04 +0100

Also,

How shocking would it be to current usage of the Basic pattern to use an explicit, empty password?  Several other browsers use "foo:@localhost" for Basic if they want to avoid popups.

-Rick

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 27 Jan 2020 15:24:07 +0100 (CET)

On Mon, 27 Jan 2020, Rick van Rein wrote:

> How shocking would it be to current usage of the Basic pattern to use an 
> explicit, empty password?  Several other browsers use "foo:@localhost" for 
> Basic if they want to avoid popups.

I'm not suggesting that curl's way of treating this information is the golden 
standard or anything neither for URI parsing nor HTTP headers. I'm just 
providing datapoints showing this is a tough change. (curl has supported this 
URI style since 2003)

-- 

  / daniel.haxx.se

---

From: Rick van Rein <[email-masked]>
Date: Mon, 27 Jan 2020 16:02:39 +0100

Hey,

> I'm not suggesting that curl's way of treating this information is the
> golden standard or anything neither for URI parsing nor HTTP headers.

It is a bit specific to Curl, I suppose; as a cmdline tool it tries very hard to not need interaction, and so a choice has been made to silently add the colon after a user name and construct Basic authentication.

Still, I'm happy that the presense of a colon seems to make all the difference in what I expect to be the practical use-case -- supplying a password for resource access.

> I'm just providing datapoints showing this is a tough change. (curl
> has supported this URI style since 2003)

Yes, this is tough; I've been pounding at an identity architecture for 4-5 years, and surprisingly.  HTTP is the most difficult protocol to deal with, its semantics being relatively light (compared to LDAP, say) and having collected so much history of assumed extensions to those semantics.  In comparison, SASL, TLS and even Kerberos are much easier to work on!

I thank you for the data points, they are pleasantly concrete.  To be honest, due to the rare use of user names in HTTP I am not expecting any more tough points.  Still, open to hear about any concrete technical issues that this list brings up.

Thanks,
 -Rick

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 28 Jan 2020 04:09:19 +1300

On 28/01/20 1:02 am, Rick van Rein wrote:
> protocols.

How many of those other protocols are newer than HTTP though?

RFC 3986 specification also is itself much newer than HTTP/. Back when
HTTP/1.0 was documented the URL syntax was defined by RFC 1738 which said:
"
   In general, URLs are written as follows:

       <scheme>:<scheme-specific-part>
"
...
"
3.1. Common Internet Scheme Syntax

   While the syntax for the rest of the URL may vary depending on the
   particular scheme selected, URL schemes that involve the direct use
   of an IP-based protocol to a specified host on the Internet use a
   common syntax for the scheme-specific data:

        //<user>:<password>@<host>:<port>/<url-path>

"

And then because HTTP/0.9 practices predated even this spec ...
"
   An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>

...  No user name or password is allowed.
"

HTTP has a long tail of infrastructure to support. Which includes
infrastructure designed and assuming those definitions. Some following
the RFC1738 no user:password@ section requirement. Some following the
common-URI  user:password@ requirement. Some following the RFC3986
adjustments.

The RFC723* documents went back to that original RFC1738 definition to
resolve these problems and ensure best interoperability. It is unlikely
to have been long enough for that long tail of software to have churned
out of existence yet and make the field usable again. Meanwhile we have
pseudo-headers now for URL parts.

NP: I am supportive of the effort to get a standard for translating
between URL syntaxes. But worried the authors view is badly mistaken
about the situation from HTTP viewpoint.

> authentication, gotten them mixed up.

I think it is probably you that have the concepts mixed up.

As you should be able to see from the above text HTTP is *old*. From a
time when userinfo@ was outright forbidden through years when it means
exclusively Basic authentication credentials. Decades when there was not
much in the way of other authentication or authorization mechanisms
existing.

It is not *wrong*, so much as it is burdened by the large amount of
historic software relying on and assuming different definitions.
Software which is still hanging around. In the Squid Project we are only
just starting to see lack of push back against removing HTTP/0.9 support
sometime later this decade - gopher and FTP are still very much alive
and well.

> What does that mean here?

That "PUT http://[email-masked]/" stores the correct document on the
server, in the correct place. Even when the server does not understand
the new header.

The client MUST NOT assume that the header works everywhere all the time.

> let me know whatever concrete issue you are seeing that I missed!

I see only use of Vary header for caching.

It would be useful to add text clarifying non-GET requests cannot depend
on the header being obeyed. Such as the above a client using PUT.

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 27 Jan 2020 16:32:34 +0100

On Mon, Jan 27, 2020 at 01:40:51PM +0100, Daniel Stenberg wrote:
> And in fact, it sends the user name without a password in a HTTP header,
> which is... well, what you ask for. =)

Actually the only valid use case I've ever had for user[+pass] in URIs
were for FTP URIs that I was typing in browsers (or following links to
download stuff from various places). I'm not even sure browsers still
support FTP URIs nowadays ;-)

Willy

---

From: Rick van Rein <[email-masked]>
Date: Mon, 27 Jan 2020 17:14:04 +0100

Hi Amos,

>> Every time I look at HTTP, it seems to

I did not mean any disrespect; sorry if it came across like that.  I
know how slowly protocols change, as a result of user base.

> historic software relying on and assuming different definitions.

I know this effect, but am nonetheless surprised that 0.9 is still around.

> The client MUST NOT assume that the header works everywhere all the time.

Ah, that is a clear question, will need to think it over.

> on the header being obeyed. Such as the above a client using PUT.

Will look into that; of course I am open to text by others too.

FWIW, the next iteration will address compatibility with Basic.

-Rick

---

From: Rick van Rein <[email-masked]>
Date: Thu, 30 Jan 2020 00:07:33 +0100

Hello Daniel, James and Amos,

I think I resolved the challenges that you posed.  Thank you for making
me think harder and (I believe) improve on the proposal.

Changes:
I stopped fussing about colons in the userinfo and left that to RFC 3986
and perhaps HTTPbis; I changed the contents of the User header to the
beginning of the userinfo up to any colon; I allowed the header value to
be an empty string, and be supplied by compliant user agents
if-and-only-if there is a userinfo component in the target URI.

@Daniel
You indicated a conflict with Basic authentication.  However, it is
possible to send both the User header and Basic authentication.

In addition to the changes noted, I explained

Appendix B.  Compatibility with Basic Authentication

   This appendix is informative.

   Basic authentication is regularly used as a quick and easy HTTP
   authentication technique.  Several user agents continue to support it
   with the "user:password@" URI prefix to a hostname, despite its
   deprecation.  This specification imposes no new constraints on this
   practice; it merely prescribes to send the User header field,
   possibly in addition to an existing pattern of Basic authentication.

   The mapping from resource names to actual resources is the
   prerogative of the server.  A server supportive of resource selection
   through Basic authentication could ignore the User header field and
   still comply with this specification.  A server that does recognise
   the User header field would use it to locate a resource, before
   deciding about access control to that resource; this may raise
   authentication requirements, and select schemes that could be
   supported.  At this time, it may or may not welcome an added Basic
   authentication attempt.  All this is server configuration.

   This flexibility can support a transition from Basic authentication
   to User header fields on the server, and allows client software to
   follow suit by first adding the User header, and later dropping the
   deprated pattern with "user:password" in the userinfo component of a
   URI.  Server administrators have a free choice to gradually phase out
   clients or client configurations that adhere to older and possibly
   deprecated usage patterns.

   Sending both the User header and Basic authentication is only to be
   expected from user agents who conflate resource userinfo with
   authentication user.  Such user agents will be less flexible, and
   will not be able to support more advanced usage patterns that
   separate these concepts, such as shared/group resources addressed
   with the User: header field and, when desired, authentication through
   an independent set of headers.  Among the tools to drive such
   patterns could be the negotiation of more advanced mechanisms, even
   just Digest authentication.

@James, @Amos

You were concerned about finding the same resource on all accounts, for
instance one client's PUT should end up in the same resource as another
one's.  Having allowed empty values to the User header, I could write:

Appendix C.  Compatibility with RESTful Patterns

   This appendix is informative.

   Whether and how the User header is interpreted is the prerogative of
   the server.  The server will translate resources in the same manner
   when provided with the same User header, and may do so without regard
   for the method used.  The main concern is now if it will be addressed
   in the same manner in every case.  This depends on the user agents.

   Development environments make sending the User header field simple,
   and so application support is as easy as the applications are
   flexible.  Binary user agents and especially ones that may lag behind
   in updates therefore need some care for backward compatibility
   support.

   The compatibility can be guaranteed for host names that always
   require a User header; such resources may be described with a URI
   holding a present but empty userinfo field.  Failure to send a User
   header to such resources when the URI holds one can be assumed to
   have originated from a user agent that support it.  When an offer for
   Basic authentication is presented, it may be interpreted as the older
   approach to userinfo, and treated as a substitute for the User
   header.  If neither is offered, an error may be reported, or control
   redirected to another means of selecting a resource user.

   This indicates that the server is able to detect possible problems,
   and can avoid accidentally binding a request to an unintended
   resource as a result of a missing User header.

   Under the fallback, resources gain an alias under a local convention.
   The URI form with a userinfo field has more semantics, and offers
   better interpretation options to clients, so among aliases this is
   the form that should be treated as the canonical URI.

@Amos
You requested more text about caching.  Most of it is orthogonal to the
User header, but the following things may make sense to mention in any
case.  Please let me know if I am overlooking things.

Appendix D.  Compatibility with Caching

   This appendix is informative.

   Whether and how the User header is used to find resources is the
   prerogative of its server.  A conservative cache design might insert
   the User header value in its request URI, but lose the capability of
   seeing the equivalence of a resource as perceived by the server.  The
   inclusion of the name "User" in the Vary header of the response
   provides a more accurate cache instruction.

   Whether a result is "private" is independent of the User header, as
   that only signifies a refinement of the resource name space on the
   server.  The rules that signify authentication as default indicator
   of privacy is orthogonal to the User header.  This is one reason why
   it is good to separate resource user and authentication user; Basic
   authentication may work to select resources, but it reduces cache
   performance.

The complete proposal is moving towards one where the current handling
is the default handling and the distinction between resource userid and
authentication userid is an explicit advanced case.  Clients send both
and servers get to choose, but it is up to the client to select the
advanced case.  The realm already offers the proper key to store such
choices, specific to the User header value and server-proposed realm.

Thanks for helping to develop this idea!

Cheers,
 -Rick