[GNAP] Signature Methods

Justin Richer <jricher@mit.edu> Tue, 15 June 2021 17:49 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BA11F3A3802 for <txauth@ietfa.amsl.com>; Tue, 15 Jun 2021 10:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HWfesH6HiCdF for <txauth@ietfa.amsl.com>; Tue, 15 Jun 2021 10:49:16 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) (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 36FA23A36DE for <txauth@ietf.org>; Tue, 15 Jun 2021 10:49:15 -0700 (PDT)
Received: from [] (static-71-174-62-56.bstnma.fios.verizon.net []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15FHnEkK011453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <txauth@ietf.org>; Tue, 15 Jun 2021 13:49:14 -0400
From: Justin Richer <jricher@mit.edu>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Message-Id: <EFDB08A5-51F5-4261-A6E8-A718D07937E5@mit.edu>
Date: Tue, 15 Jun 2021 13:49:13 -0400
To: GNAP Mailing List <txauth@ietf.org>
X-Mailer: Apple Mail (2.3608.
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/dfBEjh5ob_J57QAgCkclXM_JQS0>
Subject: [GNAP] Signature Methods
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <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: Tue, 15 Jun 2021 17:49:30 -0000

In GNAP, most requests are signed in some way, or at least bound to a key being presented or referenced with the request. This is true for connections from the client instance to the AS and to the RS, as well as introspection requests from the RS to the AS. GNAP has always sought to be flexible with regard to cryptographic binding mechanisms, but there’s a question as to what should remain defined in the core document. Right now, core has six methods defined. The editors are proposing that we keep at least two and drop two, and the others could either both be kept, both be dropped, or one kept. The rationale for each proposal is discussed below:

Proposed to keep:

- HTTP Method Signatures: general purpose mechanism, being defined in HTTP WG. Can be bound to symmetric and asymmetric keys. Usable for native, web, and SPA clients. Suggested MTI for the AS (but not mandatory to use) for interoperability. Side note, possible use for AS to sign responses (but not explored here yet — that’s another topic).

- Mutual TLS: based on OAuth MTLS, ties the keys at the TLS layer to the application protocol (GNAP). 

Proposed to drop:

- OAuth PoP: expired draft, due to be replaced with new draft based on HTTP Message Signatures.

- OAuth DPoP: only works for asymmetric keys, requires key be presented in the header (duplicating information from GNAP messages). It was never meant to be a general purpose signing mechanism, though the FAPI group in OIDF is considering it as an option in current proposed work. 

This leaves the two JWS based methods, detached and attached. Since attached JWS depends on the detached JWS method to handle body-less requests like GET, DELETE, OPTIONS, etc., if we remove the detached method then we have to remove both. The methods could be pulled to an extension, left in core, or removed entirely. 

The editors would appreciate feedback on this proposal, including specific feedback on the JWS methods from implementors who are targeting them.

 — Justin