Re: Adding user@ to HTTP[S] URIs

Rick van Rein <rick@openfortress.nl> Mon, 27 January 2020 15:06 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 5A8F4120820 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 27 Jan 2020 07:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.752
X-Spam-Level:
X-Spam-Status: No, score=-2.752 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.249, MAILING_LIST_MULTI=-1, SPF_PASS=-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 T0Qz5OwD8wGl for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 27 Jan 2020 07:06:32 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (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 83FF1120251 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 27 Jan 2020 07:06:32 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iw5vi-0004i2-1U for ietf-http-wg-dist@listhub.w3.org; Mon, 27 Jan 2020 15:03:58 +0000
Resent-Date: Mon, 27 Jan 2020 15:03:58 +0000
Resent-Message-Id: <E1iw5vi-0004i2-1U@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <rick@openfortress.nl>) id 1iw5vg-0004gX-8X for ietf-http-wg@listhub.w3.org; Mon, 27 Jan 2020 15:03:56 +0000
Received: from lb2-smtp-cloud9.xs4all.net ([194.109.24.26]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <rick@openfortress.nl>) id 1iw5vP-0007G1-4D for ietf-http-wg@w3.org; Mon, 27 Jan 2020 15:03:55 +0000
Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud9.xs4all.net with ESMTP id w5v5iLxglT6sRw5v6i8TtI; Mon, 27 Jan 2020 16:03:20 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1580137390; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=uyoloXrrpj68r2rMg53w7twpQ2MZe2uwgEBq3O7hreY=; b=GpjbPde2Rfv8CgakzMvWQiaomzMolMdPYKicmx1h9TqCmGnBxNZvjq5X 0HmfZv4WV1p0AO68UbOFipnJBse39luYWlxrhl4X6l9hQe4DQmrOBTUimu ZyXe6NftNgx5f+8esOStvBcRZf5k+WDcOwOo1ZBHyQjOZr+4OQ9mVIWzM=
Received: by fame.vanrein.org (Postfix, from userid 1006) id F28A8256C7; Mon, 27 Jan 2020 15:02:41 +0000 (UTC)
Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id B9EC425164; Mon, 27 Jan 2020 15:02:40 +0000 (UTC)
Message-ID: <5E2EFB8F.5090602@openfortress.nl>
Date: Mon, 27 Jan 2020 16:02:39 +0100
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Daniel Stenberg <daniel@haxx.se>
CC: James Fuller <jim@webcomposite.com>, Austin Wright <aaa@bzfx.net>, "HTTPbis WG (IETF)" <ietf-http-wg@w3.org>
References: <5E2B76EC.5000300@openfortress.nl> <BB50C7B7-3861-4054-AFB7-6F1C287AFEE6@gmail.com> <5E2C2039.7080303@openfortress.nl> <0bb7f153-57ea-7cb4-59e2-26ee2e41d928@treenet.co.nz> <5E2C4738.8010609@openfortress.nl> <alpine.DEB.2.20.2001251614520.15685@tvnag.unkk.fr> <5E2C65D7.7030408@openfortress.nl> <4859592D-1B93-49E0-9661-5E24FDAC276F@bzfx.net> <5E2D630A.604@openfortress.nl> <CAEaz5mtYyvei8wxb4_1H36N2PkrU+-47uqn2KtitqMtd9LRwsQ@mail.gmail.com> <5E2ED158.1030909@openfortress.nl> <alpine.DEB.2.20.2001271319120.18042@tvnag.unkk.fr> <5E2EEB7C.9030100@openfortress.nl> <alpine.DEB.2.20.2001271515570.18042@tvnag.unkk.fr>
In-Reply-To: <alpine.DEB.2.20.2001271515570.18042@tvnag.unkk.fr>
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: MS4wfPAyvpv5tbBpUV1rRJSf6F3BYhZmMkrbhGFOfAazUbEiUcEqifNa/f3sIvPWCzb0+d8c8QRpQCryNXDUVlzqEz+Qza5PQbSek76uJ9CN0TTZLmwE0glh r/Putj3R9TRy0Ky6Fa4ZIeKFvD6B/sCjaNQplhSBCzPAE+v4AGd9oMXWQbLzYMkVyvRYAxzRvJ/0gQ==
Received-SPF: pass client-ip=194.109.24.26; envelope-from=rick@openfortress.nl; helo=lb2-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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1iw5vP-0007G1-4D 02b071ed14519d21d72cf7c0d6943330
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Adding user@ to HTTP[S] URIs
Archived-At: <https://www.w3.org/mid/5E2EFB8F.5090602@openfortress.nl>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37304
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>

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