IETF Logo Mail Archive

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

Justin Richer <jricher@mit.edu> Sat, 23 October 2021 23:55 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68DB3A0AA9 for <oauth@ietfa.amsl.com>; Sat, 23 Oct 2021 16:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 M7UEbUeWALFq for <oauth@ietfa.amsl.com>; Sat, 23 Oct 2021 16:55:17 -0700 (PDT)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 1FA8E3A0A9A for <oauth@ietf.org>; Sat, 23 Oct 2021 16:55:16 -0700 (PDT)
Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 19NNtBql017202; Sat, 23 Oct 2021 19:55:13 -0400
Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1497.24; Sat, 23 Oct 2021 19:55:17 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Sat, 23 Oct 2021 19:55:11 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1497.023; Sat, 23 Oct 2021 19:55:11 -0400
From: Justin Richer <jricher@mit.edu>
To: Dick Hardt <dick.hardt@gmail.com>, "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
CC: David Waite <david=40alkaline-solutions.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature
Thread-Index: AQHXwGHzUlbgLeypIkO3Usi3RumNb6vRi6MAgAAwnACADii/gIABbMhL
Date: Sat, 23 Oct 2021 23:55:11 +0000
Message-ID: <359ca6f14b40409abebdf0d9554c195c@oc11expo18.exchange.mit.edu>
References: <CADNypP9QXCEjJmkhBvTHn68kDcJ2Mfg-tSQx1-hvfPoOTXCKzA@mail.gmail.com> <CAGBSGjqasD=eYnsMm7gZB2g+=C4abZoVi7FH4e7EFfgwKdjS8w@mail.gmail.com> <CAD9ie-uH9xGL9orTFxEd=tfhO6Q-S3sDHrQDtU7h0_dr6YeLOg@mail.gmail.com> <EE56CE99-5592-40AF-9BA5-7F3886ED315A@mit.edu> <CAD9ie-t9i1sVLhVhJp-mWSchV_x0b3no7i4qNXvcaQS+8OqCVA@mail.gmail.com> <CAGBSGjrgVbGWwFq6LDX_2Vhv7yQkwtEEjy36GpLj-bN+MtcX-w@mail.gmail.com> <CAD9ie-vJiwBSV71z4_2TJJO7A52mV763XvXmEPsEFgOMFVOwyQ@mail.gmail.com> <D445073E-D495-4250-9773-9AEEB09C01E0@amazon.com> <CAD9ie-t5EBZLtHmmbDQu9iq-d87gf07X5Fes_ZqFts5hDCOOuw@mail.gmail.com> <A312C403-3341-4B29-AEB3-B547E9A802E7@amazon.com> <CAD9ie-sW537PEzavzv1v6JSOFSfLa7iRVPAXD-miuEY8GMmDeQ@mail.gmail.com> <CAJot-L1fio+-1sSn6Z88ianq04RoHJ3M5yxe0Bzu2Cs-CWCPkg@mail.gmail.com> <54A59064-B40B-4F6C-9E7C-A5618C2C4D3E@alkaline-solutions.com> <3CAB48B9-B517-4693-8CBB-3377122A6077@amazon.com> <CAJot-L3CiPf0XbTRHPgs71cxfhr2626+vt4XELDSf5nhkj8wdg@mail.gmail.com> <EB86A178-052C-48CD-9F99-63B9173DF7B0@amazon.com> <7618AC29-8221-4FC0-BCF3-199C6BA96FE5@alkaline-solutions.com> <CAJot-L2ztfruwe3L=uQuCYoZ++NTbejv_r3GOL4546q0nOTQPA@mail.gmail.com> <E8AB2162-98DE-452E-A64B-0BCCDC36CECD@amazon.com>, <CAD9ie-vrYO+n36Eig28NqfVw0kK6STKYs9MUKY66YGZFR-QKeQ@mail.gmail.com>
In-Reply-To: <CAD9ie-vrYO+n36Eig28NqfVw0kK6STKYs9MUKY66YGZFR-QKeQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [73.143.178.250]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/0Rx0BqLFxkgiCxYh4_2i92Y3ZfU>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature
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: Sat, 23 Oct 2021 23:55:23 -0000

Dick, you would probably be interested in the Oblivious HTTP effort that has recently been chartered to solve similar encapsulation problems in HTTP. 

- Justin
________________________________________
From: OAuth [oauth-bounces@ietf.org] on behalf of Dick Hardt [dick.hardt@gmail.com]
Sent: Friday, October 22, 2021 6:08 PM
To: Richard Backman, Annabelle
Cc: David Waite; oauth
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

I have a use case for a self contained request that can be independently verified by multiple parties. IE, not just have PoP at HTTP endpoint, but by components doing processing further down the line. It also provides non-repudiation.

For example, a JWT that is sent as an HTTP payload includes the request and the access token.

mTLS, DPoP, and HTTP signing don't provide this functionality

It is not clear if others have similar requirements, or if there is value in standardization effort, but I wanted to call out a use case not solved by the current efforts.

/Dick

On Wed, Oct 13, 2021 at 2:55 PM Richard Backman, Annabelle <richanna=40amazon.com@dmarc.ietf.org<mailto:40amazon.com@dmarc.ietf.org>> wrote:
If keeping DPoP simple means we have to have come up with 10 different variants to handle all the different cases that it doesn't support, then it isn't keeping it simple, it is just pushing the problem forward to the implementers to figure out which set of RFCs to implement.

I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone has use cases that aren't covered by one or more of those, they should bring those up so we can discuss them and decide what changes are warranted. (Either here, or in HTTPbis if changes should be made to Message Signatures) My preference would've been to stop at 2, but the consensus has not been in favor of expanding the scope of use cases served by DPoP.

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=593dd17a-bb93-449b-8126-3b72052d76b2]ᐧ

v2.23.0 | Report a Bug | By Email