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

Brian Campbell <> Fri, 12 November 2021 22:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB80D3A1280 for <>; Fri, 12 Nov 2021 14:00:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fg1r-Um2eaov for <>; Fri, 12 Nov 2021 14:00:15 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E85DA3A127A for <>; Fri, 12 Nov 2021 14:00:14 -0800 (PST)
Received: by with SMTP id t11so21154779ljh.6 for <>; Fri, 12 Nov 2021 14:00:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0gR3GQDNSV8xGPxja9wkclRz2DphguVE2kz87EC2XPI=; b=EjB9qdtQlF+LQVZf7UB+p+zRxgmn/ICpMuFWrg/f2SMHzX5Vfc4olPXshviyE2Agd5 W+XPCB+OIC3ojQFZhFDs9BfZPsTWiEMFKRUukVlx7QEhs9LEJukRZhqcqMC1RW3iBzKX MY0Aexg/0GyUdb7ktFARD5NakVXfCOxsPLgUTaSgAq4sfGuUBLr67JOSe/mbr4FSI9IZ ynUrX46+JhFM13kTHRW+hw/e9dCDMNSiQCJA5qmDSbSBc5r6reSTZNjkq6YL0Vl4P8e5 oZCzmk4jDPopKc3r68bgf+M7eqHDeJtV7rkZSCO5a44AH9fJoMrHzwBq0bzv5RPi0ye3 WpyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0gR3GQDNSV8xGPxja9wkclRz2DphguVE2kz87EC2XPI=; b=PccJVymRZEHYz+cOzme9JzlHMr1MRJ2ia9xRybsyVwnzF1hp2Z+eAWph389lEJAJkS Da3aHjxrfdPbQRvFVTfmk35+x3SEwH0yyVjJa+xv5th0D8OYk9rrHcE4aO8CrD0O42ZY dlqJTEgdwerhKi22Z62f2uHTCTOe7nbDmMnceil00dpX37OZlp7f0F7uXDhuV8gpmL1c MDYPCp7Q16pbn9r2hOoPPP7zKyosseB/4H/Sx+v/9Gf8am/R1gj7AjAnN5uvBpKe8sPJ +Mfl1ER+jGKM3d+w9vcRAhE8wyNab5KTdoMyvrP+Z0wREKpPtkovPMkGIb//c8ek6UTs WFIQ==
X-Gm-Message-State: AOAM531F7U3fpq2rj7k+u6RAE7mwHAB8jDmhj9C63d3QaL7QHmQxDCSf psRUnMmgph04JcZ6iSg0F5VddAXwdhK4bfsgY+rBbUBzrNzLZ7tA0561KxCWqFyq5kQ0c9qttaT ZnUNQiVTmRlOJAJUfUlM=
X-Google-Smtp-Source: ABdhPJyZV2UJqlsgmCQReMi1Se8PrtRHV9j0C8DLutEMuHtDLE2SAZL9ygFFDIs8dENaoIWRfkE+yTYmdV/xGV6/6no=
X-Received: by 2002:a2e:9349:: with SMTP id m9mr19046484ljh.178.1636754412234; Fri, 12 Nov 2021 14:00:12 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Fri, 12 Nov 2021 14:59:46 -0700
Message-ID: <>
To: Dmitry Telegin <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="000000000000539ff705d09e9551"
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: Fri, 12 Nov 2021 22:00:20 -0000

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 <dmitryt=> 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._