Re: [OAUTH-WG] MTLS vs. DPOP

Justin Richer <jricher@mit.edu> Wed, 15 May 2019 21:07 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 7D1A8120857 for <oauth@ietfa.amsl.com>; Wed, 15 May 2019 14:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 quHiICTA2Iz9 for <oauth@ietfa.amsl.com>; Wed, 15 May 2019 14:07: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 9A3C91207FF for <oauth@ietf.org>; Wed, 15 May 2019 14:07:12 -0700 (PDT)
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x4FL8PSc026404; Wed, 15 May 2019 17:08:25 -0400
Received: from w92expo18.exchange.mit.edu (18.7.74.72) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 15 May 2019 17:06:28 -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.1365.1; Wed, 15 May 2019 17:07:08 -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.1365.000; Wed, 15 May 2019 17:07:08 -0400
From: Justin Richer <jricher@mit.edu>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
CC: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] MTLS vs. DPOP
Thread-Index: AdUErRQrEyJTkDUdQjmHcwr6XcEhZQG1poeA
Date: Wed, 15 May 2019 21:07:07 +0000
Message-ID: <9FDD4D1A-7548-4415-9276-F22AE8ACB2A3@mit.edu>
References: <DBBPR08MB4539BA4621AC8029AEF4F8C8FA310@DBBPR08MB4539.eurprd08.prod.outlook.com>
In-Reply-To: <DBBPR08MB4539BA4621AC8029AEF4F8C8FA310@DBBPR08MB4539.eurprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [71.174.62.56]
Content-Type: multipart/alternative; boundary="_000_9FDD4D1A754844159276F22AE8ACB2A3mitedu_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/VlAQAQOiy5srOnSMLuAmOhGdoOY>
Subject: Re: [OAUTH-WG] MTLS vs. DPOP
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: Wed, 15 May 2019 21:07:20 -0000

For what it’s worth, if we think of things a little bit differently, we can support both types of key presentation and possession proofs in parallel. My thinking was that in both the MTLS and DPoP cases, the client proves that it has access to a key and then uses that key with the RS in the same way it uses it with the AS. The format of the key and its presentation mechanism differ, but otherwise there really are a lot of parallels. This is how I’ve been thinking of it in the XYZ project:

https://oauth.xyz/keys/

It’s still very-drafty at the moment, but it follows as an abstraction to this thinking. In XYZ this is a bit simplified because the client always starts at the backchannel endpoint (equivalent to the token endpoint). In OAuth2, this would happen during the call to the token endpoint, as in the DPoP and MTLS drafts.

— Justin

On May 7, 2019, at 4:25 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com<mailto:Hannes.Tschofenig@arm.com>> wrote:

Hi all,

In the OAuth conference call today Vittorio mentioned that some folks are wondering whether DPOP is essentially a superset of MTLS and whether it makes sense to only proceed with one solution rather potentially two.

I was wondering whether others in the group have a few about this aspect?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth