Re: [OAUTH-WG] DPoP and MTLS - friends or foes?

Neil Madden <> Mon, 15 November 2021 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 054353A0F41 for <>; Mon, 15 Nov 2021 09:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IaNV2ToQ8w9t for <>; Mon, 15 Nov 2021 09:52:21 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFD0B3A0F39 for <>; Mon, 15 Nov 2021 09:52:20 -0800 (PST)
Received: by with SMTP id z200so14728067wmc.1 for <>; Mon, 15 Nov 2021 09:52:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=TIzNbQquy1USoeBUEyfcJrV0T49ho1yKRqPEaIhPAm8=; b=BjafIK7QNOaMJBg0jDDFsQjedkuJE5d6KEvqDOZxW6NkbkjXZhyzp9wJFBNOoDdvkE veZVNKxl9+XNbb295YbLI4+DMQwrf0alGcnA4VOvHs8pYOyIVPIrgVBNXhnR0A/2Qoz6 fHeayxUsJjiykNXPS2kLF0a+A+cdCKCSLxSiI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=TIzNbQquy1USoeBUEyfcJrV0T49ho1yKRqPEaIhPAm8=; b=iePVUAa9SzJv4Ziv8rwmiBz7khfAbXdX+4/5pO0XW6HFBdaS4QZhdfqu7wWu5zanJn GuL13clXtR9fgUCTtnxwuuAowVGi963eoOOaMTJ/GEsE2RZg7hJyrVcfDmeXfGTAP9KU URRhGff715mrBLfvM61NOEKBiEL4CbFvbElQsxE8CZH/hjmwXs9oGikIHWGH2LMfTz9p RarlBFRay9+57vM9RK+n3hkNqlO8a/P01Y6j6KV+IAzB33z1Mg5y1vhMY/3dDswvrel6 gSB1aPwf4j+HI44HCc/xhjr/ujIvWg5RnFNEyfaLg2S1ldR8K2panJSKsSaWp/oswVoI ma3g==
X-Gm-Message-State: AOAM533qHnRwl8FL3C9xrALRkoCyehzZFgwdrFzvnDxgUZF7nX0pYHcS jTXfmD0NXB576xlW+Kyjxkeky1Avol7eSw==
X-Google-Smtp-Source: ABdhPJwn6hxL01zbOok3fJMCDnM/7nf9UIqAsgL7WI8XvT5ChXMkwcv3OnoR4Q50v0yUm3uUlJ9WyQ==
X-Received: by 2002:a05:600c:4153:: with SMTP id h19mr367099wmm.142.1636998737904; Mon, 15 Nov 2021 09:52:17 -0800 (PST)
Received: from ( []) by with ESMTPSA id g13sm14425368wrd.57.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Nov 2021 09:52:17 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-D02CBC33-B27E-400D-965D-514B1CF49F51"
Content-Transfer-Encoding: 7bit
From: Neil Madden <>
Mime-Version: 1.0 (1.0)
Date: Mon, 15 Nov 2021 17:52:16 +0000
Message-Id: <>
References: <>
Cc: Dmitry Telegin <>, oauth <>
In-Reply-To: <>
To: Brian Campbell <>
X-Mailer: iPhone Mail (19B74)
Archived-At: <>
Subject: Re: [OAUTH-WG] DPoP and MTLS - friends or foes?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Nov 2021 17:52:25 -0000

I’m not smart enough to remember in what context I might have said this, but I’d hazard a guess it was somehow related to service mesh. 

Generally, we allow both to be specified largely because of our support for macaroon access tokens: a proxy could transparently add a mtls binding (for ex) to an AT as a macaroon caveat. If it first had to check whether there was some other type of binding on it then that would make it more awkward.

So we have an implementation where there can be any number of bindings associated with an AT and we loop through the set of keys in the “cnf” object and ensure that each one is satisfied. (We also currently reject unrecognised confirmation methods, I believe - on the assumption that they are all critical. I think the specs are currently silent on what to do with an unrecognised “cnf” value). 

Macaroon ATs somewhat break the whole token_type field, as an AT can start off as a pure bearer token and later become bound by a caveat.

— Neil 

> On 12 Nov 2021, at 22:00, Brian Campbell <> wrote:
> I think Neil commented once somewhere about maybe seeing value in both at the same time. He's smarter than me so I don't like to contradict him. But I've always thought of them as mutually exclusive. And practically/pragmatically I think it really is one or the other.  
>> On Fri, Nov 12, 2021 at 9:39 AM Dmitry Telegin <> wrote:
>> As an implementer of one binding mechanism (DPoP) for the AS (Keycloak) that already features another (MTLS), I'm running into the question whether we should allow those two to be used simultaneously (which could be of course extrapolated to other hypothetical mechanisms). By "simultaneously" I mean binding a single token using both methods given that the material for both has been provided with the request.
>> I guess currently mutual exclusivity is implied. Though in theory the "cnf" section of the AT could contain both "jkt" and "x5t#S256", the mechanisms are using different values for "token_type" and authentication scheme ("DPoP" for DPoP, "Bearer" for MTLS, though the latter might change to "MTLS" in the future) and we define no mechanism to combine them (could be "Bearer+DPoP" or "DPoP+MTLS" for example, which would be valid as per RFCs 7230 and 7235).
>> I apologize if the question has been asked before; didn't find anything relevant in the ML. The implementer of MTLS for Keycloak also voted for mutually exclusive behavior.
>> - Dmitry
>> Backbase / Keycloak
>> _______________________________________________
>> OAuth mailing list
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list