Re: [Txauth] TLS Dependency

Wayne Chang <wyc@fastmail.fm> Wed, 08 July 2020 17:39 UTC

Return-Path: <wyc@fastmail.fm>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAAC3A0858 for <txauth@ietfa.amsl.com>; Wed, 8 Jul 2020 10:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=JN1ZVbqw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WNEuEmEx
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 RE33DljJhGOb for <txauth@ietfa.amsl.com>; Wed, 8 Jul 2020 10:39:30 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B423D3A07ED for <txauth@ietf.org>; Wed, 8 Jul 2020 10:39:23 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id EB0C45C00F9; Wed, 8 Jul 2020 13:39:22 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 08 Jul 2020 13:39:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=ygRKacH3QnRyUuxUuA5yKYcFpUrmynS AJfXIKaGm3Qk=; b=JN1ZVbqwQ4nl1MDbsO9ZreeC4c4kvVkDWOzlLX7GJ4wRp9Y pYulTf8DMaIdyFkxxFaD/kWQ/G02QqelTN865eSwlMj3DO727sARXs/vXsGpdvyF YWZYDgH4ox0ZBBX7MyHlaoNafPx60MQhQueGJJeD55bfm1EQk9go+e9rAnOZcFwS S9AM6xH/t3WZPaRyWkUyiJTOcthw67VYlv3NbqywmvvYoxQr1jv3FLyBNsa7VTY8 uF++eHGcecuIsTzSVL7zdSD7UVnRCKlQZwHq9jyiiPk8MK57ynq4zjfE1CtD4Vgl xaCDFinLgnNZDvXNrsxzuQzHl10CxVJkgHGL16w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ygRKac H3QnRyUuxUuA5yKYcFpUrmynSAJfXIKaGm3Qk=; b=WNEuEmExOfrw63BW/l+ki0 U0ByAy+3mS+TEvVYD7tGTIkNpKF+Juf4zW7X1gcf4zORpr6JqeEVLZti4wu2jL6S 5/fZ7onUWoG7Ex7YpSSfEG3jKifllclmMnAOLjD4McKZgbFG4Bmk6eeqAOk0e6ii noXpZzUFrRqgmQPtRUuPVFpX/S5bB+PllajdmXoOiZjs+nPZvSaQF+h7zPSbJBTU VqqDxcIwYXG5o8VjSyUrS39wlLuxCdsx2bNt3m3lyhARGmYWKSKuWxygx5Icr051 L4BkuAp7PqGZw9PvjFXF6mkXtPONmeABqbe7sYakKWZi56XB4dqLbEe01xriHHKQ ==
X-ME-Sender: <xms:ygQGX9iP3zK_gNRRMBXuIDgZnewFtAZuEhcqbfxOJsAbA9LPG3Y5oQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdghrgih nhgvucevhhgrnhhgfdcuoeifhigtsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtth gvrhhnpedtheeviedvveeltefhtefhgfetudfghfeggeekgffhkeduveeluddtgedtfefg teenucffohhmrghinhepihgvvggvrdhorhhgpdhgihhthhhusgdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeifhigtsehfrghsthhm rghilhdrfhhm
X-ME-Proxy: <xmx:ygQGXyBrgrc40F1SL3tXwaD7pJad-vEn_M0lqwGbe0l5Ci-7cXGYGQ> <xmx:ygQGX9G0pscgZOfjiyln9MtNpYo3-FxAPu7Q8KkvO9Cvgp09E8_8Rg> <xmx:ygQGXyQv_vsBEpkLQvFV6ZDug9zE11Tz1YxNHiNXU5CvNF_ojZKPEw> <xmx:ygQGX58dsedvYxmAoiWp5i6PsFQy3dW8x3PwGZ5Vsxrb9MnIV3nBcA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id BE0E1E00B3; Wed, 8 Jul 2020 13:39:22 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-601-g4bf46fa-fm-20200708.001-g4bf46fa8
Mime-Version: 1.0
Message-Id: <fb04e19a-b52a-44c6-b841-8c8c45b756e4@www.fastmail.com>
In-Reply-To: <CAK2Cwb6j0owdCS9Z57R1C-7Ug9iAyvXwS44hqQFHAtakzxGVzA@mail.gmail.com>
References: <CAD9ie-vnA98pobbboS00SAHneEG52_8eMxh_sE3r3jg6gyooGg@mail.gmail.com> <E9EC90C9-7A9A-4909-8627-A161B33E941F@mit.edu> <CAD9ie-vyB8+5jS=K_qUHfvxsF2wPV5APRo+7WUDfJxNzJONJpg@mail.gmail.com> <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu> <CAD9ie-u9z7Mc-wNjztoOTy4N_Z9jFDc2Sb6quLspasMGAMKdSw@mail.gmail.com> <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu> <CAD9ie-tpuisauOFGiUj65-RcYPtcvW_gZP1CAadqq5cE6P36HQ@mail.gmail.com> <CAK2Cwb6j0owdCS9Z57R1C-7Ug9iAyvXwS44hqQFHAtakzxGVzA@mail.gmail.com>
Date: Wed, 08 Jul 2020 13:39:12 -0400
From: "Wayne Chang" <wyc@fastmail.fm>
To: "Tom Jones" <thomasclinganjones@gmail.com>
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary=87840f5812524e53894bd601bd8aae88
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/jpmb_-sX9htGKSgYM9rOEQm2Gr8>
Subject: Re: [Txauth] TLS Dependency
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2020 17:39:39 -0000

Shifting to a new thread based on the interesting point Tom made about removing TLS requirements. Justin, I did see that you were careful to specify "TLS or equivalent" in your drafts, and Dick commented "[Editor: too aggressive to mandate HTTP/2 and TLS 1.3?]" in his. Maybe this is a good opportunity to explore the "or equivalent" part.

Some IoT environments do not and will not support HTTP + SSL/TLS, but could benefit from this grant framework. Instead, they may use application protocols like MQTT and more recently in conjunction with single-packet authorization (SPA). https://ieeexplore.ieee.org/document/8930455

>From the DID ecosystem, I can imagine some future interoperability between DIDComm and GNAP. It is not clear that TLS will be used for all DID-to-DID communications, which aim to be transport agnostic. See discussion here: https://github.com/decentralized-identity/didcomm-messaging/issues/38

What other potential non-TLS use cases are worth mentioning?

On Wed, Jul 8, 2020, at 1:10 PM, Tom Jones wrote:
> a somewhat milder response might be.
> It seems that justin's proposal is not, in fact, a grant negotiation, but a generalized token format.
> So - what could that mean here?
> I have a problem with the whack-a-mole approach of OAuth, with RAR JAR ad infinitum.
> That is a never-ending stream of hacks.
> if Justin's proposal is to be considered seriously, it must be at some higher level that GNAP..
> I suggest that the current approach of xauth txauth authxyz is not really headed to a convergence.
> Perhaps we need to start with an abstract set of goals and data flows. One that includes the user/RO.
> I do have one for healthcare - but i am short of time right now to generalize it.
> One item I would like to see resolved early is to remove the dependency on transport layer security. One that includes the handling of key roll-over.
> In Kantara we focused first on the legal responsibilities of the token maker. That problem seems to have consumed FAPI, altho they have multiple names for it.
> In the real world we have legal entities (natural and unnatural) and legal names (brands) as well as pseudonyms. OAuth just had endpoints with SSL keys and certs. How about we start there?
> Peace ..tom