Re: Adding user@ to HTTP[S] URIs

Rick van Rein <rick@openfortress.nl> Tue, 04 February 2020 08:08 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7080112012A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 4 Feb 2020 00:08:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level:
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHVU8kMOtjt6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 4 Feb 2020 00:08:51 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A418120074 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 4 Feb 2020 00:08:35 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iytDK-0001X1-R2 for ietf-http-wg-dist@listhub.w3.org; Tue, 04 Feb 2020 08:05:42 +0000
Resent-Date: Tue, 04 Feb 2020 08:05:42 +0000
Resent-Message-Id: <E1iytDK-0001X1-R2@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <rick@openfortress.nl>) id 1iytDH-0001WG-5s for ietf-http-wg@listhub.w3.org; Tue, 04 Feb 2020 08:05:39 +0000
Received: from lb1-smtp-cloud9.xs4all.net ([194.109.24.22]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <rick@openfortress.nl>) id 1iytDE-0001be-TZ for ietf-http-wg@w3.org; Tue, 04 Feb 2020 08:05:39 +0000
Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud9.xs4all.net with ESMTP id ytD7irvAJ2Mf2ytD8ia38T; Tue, 04 Feb 2020 09:05:31 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1580803520; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=YYQURhh/0OlNFts90W3/K2lNsHaCat+cace1GUZUanY=; b=ws8fILd8DCTE3kMph4pOXuNUV6/hDRFvmE7RkDrdBJeuYi9oixdBC/od 5s9sdml7huqTjB/LSbhuaKstGU6WxtAWR9N74cj4yFsYC3yI96jVLN8T36 XUAHh/+Cc8d456Wu2t0iUvvIRgIFA6f0zXKlCqzlFWHWoh4alPyRypaQ8=
Received: by fame.vanrein.org (Postfix, from userid 1006) id D34622178B; Tue, 4 Feb 2020 08:04:59 +0000 (UTC)
Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id B14F821784; Tue, 4 Feb 2020 08:04:50 +0000 (UTC)
Message-ID: <5E3925A1.6050908@openfortress.nl>
Date: Tue, 04 Feb 2020 09:04:49 +0100
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
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>
References: <5E2B76EC.5000300@openfortress.nl>
In-Reply-To: <5E2B76EC.5000300@openfortress.nl>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4
X-CMAE-Envelope: MS4wfKqzBQbu9Hck4LRcrYI2sxKgyq1hUpFWVg54yZQ+4raQav0VT1GEfOrc/+7qaCybFDGxV9sOzZzisQbaSLpHz4FKSBJReNR29O47FbrVw29ToK/xsgGh Z6iU0RML6bkpxFBKpAgM3Ok6f98E18X+Ep5hjeVCeOf8wNhSXWKqP/YrvrksREL+hHqebqwyeWdpaQ==
Received-SPF: pass client-ip=194.109.24.22; envelope-from=rick@openfortress.nl; helo=lb1-smtp-cloud9.xs4all.net
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1iytDE-0001be-TZ 54e6f2e0798a175e8ee04a61ffeb8c6a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Adding user@ to HTTP[S] URIs
Archived-At: <https://www.w3.org/mid/5E3925A1.6050908@openfortress.nl>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37337
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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.