[OAUTH-WG] HTTP Message Signing and OAuth PoP

Justin Richer <jricher@mit.edu> Thu, 29 April 2021 15:34 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EF1383A4027 for <oauth@ietfa.amsl.com>; Thu, 29 Apr 2021 08:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mPG1KKfv8fsV for <oauth@ietfa.amsl.com>; Thu, 29 Apr 2021 08:33:55 -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 65EC73A4025 for <oauth@ietf.org>; Thu, 29 Apr 2021 08:33:55 -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 13TFXqSL003694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <oauth@ietf.org>; Thu, 29 Apr 2021 11:33:53 -0400
From: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6E4B784B-8D6B-46E4-93E9-581CE9E8CF9A"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Message-Id: <288F1E8C-7C56-4488-8825-791086D6EBCE@mit.edu>
Date: Thu, 29 Apr 2021 11:33:52 -0400
To: oauth <oauth@ietf.org>
X-Mailer: Apple Mail (2.3608.
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/U-P8OC-rwDJkDSfV0oQjF22yO94>
Subject: [OAUTH-WG] HTTP Message Signing and OAuth PoP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Apr 2021 15:34:01 -0000

Many of you will remember an old draft that I was the editor of that defined OAuth proof of possession methods using HTTP Message Signing. When writing that draft I invented my own scheme because there wasn’t an existing HTTP message signature standard that was robust enough for our use cases. I’m happy to say that the landscape has changed: Annabelle Backman and I have been working in the HTTP Working Group on HTTP Message Signatures, a general-purpose HTTP signing draft with a lot of power and a lot of flexibility. There’s even a relatively straightforward way to map JOSE-defined signature algorithms into this (even though, to be clear, it is not JOSE-based). The current draft is here:

https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html <https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html>

This draft has gone through a lot of change in the last few months, but we, the editors, believe that it’s at a fairly stable place in terms of the core functioning of the protocol now. It’s not finished yet, but we think that any changes that come from here will be smaller in scope, more of a cleanup and clarification than the deep invasive surgery that has happened up until now.

One of the things about this draft is that, on its own, it is not sufficient for a security protocol. By design it needs some additional details on where to get key materials, how to negotiate algorithms, what fields need to be covered by the signature, etc. I am proposing that we in the OAuth WG replace the long-since-expired OAuth PoP working group draft with a new document based on HTTP Message Signatures. I believe that this document can be relatively short and to the point, given that much of the mechanics would be defined in the HTTP draft. If this is something we would like to do in the WG, I am volunteering to write the updated draft.

I also want to be very clear that I still believe that this lives beside DPoP, and that DPoP should continue even as we pick this back up. In fact, I think that this work would take some pressure off of DPoP and allow it to be the streamlined point solution that it was originally intended to be.

If the chairs would like, I would also be happy to discuss this at an interim meeting.

 — Justin