W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2020

Re: Adding user@ to HTTP[S] URIs

From: Rick van Rein <rick@openfortress.nl>
Date: Tue, 04 Feb 2020 09:04:49 +0100
Message-ID: <5E3925A1.6050908@openfortress.nl>
To: "HTTPbis WG (IETF)" <ietf-http-wg@w3.org>
CC: Daniel Stenberg <daniel@haxx.se>, Paul Vixie <paul@redbarn.org>, Amos Jeffries <squid3@treenet.co.nz>, James Fuller <jim@webcomposite.com>, Julian Reschke <julian.reschke@gmx.de>
Hello,

Thank you all for your suggestions!  Where they were actionable, I have
improved the specification, and AFAIK this solves these items.  I also
added more explaining text, to clarify how powerful this can be to HTTP.

The text now clearly speaks of two orthogonal user concepts:
 - "resource user" is the authority user from the URI
 - "client identity" is a 401/407-authenticated user
These are now treated as the same, but the former is a server-side
notion and the latter a client-side notion.  I believe a lot can be
gained if these _can_ be distinct, as long as they may be reunited
through software/configurations when they like to.


@Daniel @Paul
A small change was needed to allow full compatibility with Basic auth.
Clients and servers can send either or both.  Both being the flexible
form, and can be a leisurely transition path from Basic auth to User.

@Amos @James
To always address the same resource, I had to ensure that absense of
User support could be detected.  I documented how and in which cases
that is possible, and a few hints towards bypassing such situations.  I
allowed empty User header values to simplify polling.

@Amos
I studied caching but found nothing required besides Vary; I did however
add a few remarks about private and the cache performance improvement
when moving away from Basic auth.

@Julian
The new text provides more "why" and the work on Basic auth and REST
explain how parties can work when the remote does not recognise the User
header.  I added short explanations on what value User can add.


Any further remarks are of course welcome!


Thanks,
 -Rick



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

Abstract:
   Many protocols support users under domain names, but HTTP does not.
   This specification defines a header for user names, independent of
   authenticated identities, and a link to userinfo in HTTP URIs.  This
   intergrates naturally with HTTP, and results in a more refined
   resource authentication model, in support of advanced usage
   scenarios.
Received on Tuesday, 4 February 2020 08:05:39 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 4 February 2020 08:05:40 UTC