Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)

Warren Parad <> Thu, 09 December 2021 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB0E73A0CB3 for <>; Thu, 9 Dec 2021 06:10:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Status: No, score=-2.088 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bhG2wl4oK3JI for <>; Thu, 9 Dec 2021 06:10:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A08F3A083D for <>; Thu, 9 Dec 2021 06:10:31 -0800 (PST)
Received: by with SMTP id v64so13935130ybi.5 for <>; Thu, 09 Dec 2021 06:10:31 -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=eOF1LVJZr0aWmdXspniDWhSUKU5n+5VSgq3YNJm4/dE=; b=GFiMftSos0+PA9/sC3KnDoli9xCKZZwfy+IrK3nI30Xy93ebZSrcXbSXqhcI4WE29V FEYgvbxpNcUq0TFvGfNubaiZv2aVib3RsJnM4xxgwx5cpZ5unBVq0ThcbvuxGx3b9ViD R2rfAKPSTCoETtjv/lsRDqmXu96Q+FCPc4RPoEcEDvhu0jygWqBl/BPLgIhlNZCLblXD exFLyTM5tPDgNkBcapd8YQZJ2yWQGPjbp1KQbBc5stdjnVwcjOJqYfdvK7s/5c8b7iTr KCZ+a46QpgpGBdU9lVUaZ+yariB5/Cdu9g2Fw9k8dIm1QBVwkbChPgoVfGBX7mSUQHhE Mv3w==
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=eOF1LVJZr0aWmdXspniDWhSUKU5n+5VSgq3YNJm4/dE=; b=yDI8wjvwJF6IglCENbPEWnOIKAGSMLHGNyzmofkxYK2d6d1vjgIHOceUGY4hRJZaJ8 KyvWdg8gIMv4BzbxSTHEevxT8ZQ5hpe9PRcAMK822iQ5/bGgsLxLA8gjtsgggeOXxrdk ZuHj76Opsdwde+fgqFxwfaeDCy20MHMOMtw2XqrWPbxbFl3STgf4TSGAxjyua1y3+GCk WPvLrV3iC98YxOvRBuKEcDqLuCju3tgRUb9VcDyw2ZmgB9FRYY6RXjREZlp3yD3Hw3GZ Bk6LlCU+sEETPZgAmBCdGuwd+LiAuClsPBExVtCYiGIJJhqI+CHJaRT96u/7Fegf9i+d V/pw==
X-Gm-Message-State: AOAM5307gPGv44yU3NOKv5R2r1xqNxetgr7NgowYHXGaa7K2TmieXMzU c24UVWXvHzXBxYPF0fIBUV250IOmnOWZz8tAXJSI
X-Google-Smtp-Source: ABdhPJw2Fg+XFsypKvLT9z9rK++pctGMAjpL1Ols0NHiLv/zvgmZSN2E9C4m8X9laD+e2LIH2FS4w7QE5WhXwmquvik=
X-Received: by 2002:a25:2304:: with SMTP id j4mr6117189ybj.359.1639059029049; Thu, 09 Dec 2021 06:10:29 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Warren Parad <>
Date: Thu, 09 Dec 2021 15:10:18 +0100
Message-ID: <>
To: Neil Madden <>
Cc: Dmitry Telegin <>, oauth <>
Content-Type: multipart/alternative; boundary="00000000000031542305d2b72b30"
Archived-At: <>
Subject: Re: [OAUTH-WG] Proposed changes to RFC 8705 (oauth-mtls)
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: Thu, 09 Dec 2021 14:10:35 -0000

This is a great answer.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <>.

On Thu, Dec 9, 2021 at 2:52 PM Neil Madden <>

> I don’t mind about a new error code, although I think it’s of limited
> value - error codes (rather than descriptive error *messages*) imply that
> the client may be able to dynamically react to the situation and so
> something different. But TLS client certs are usually configured
> statically, so it seems highly unlikely that the client could satisfy this
> requirement on its own. (Especially without all the other hints that would
> be missing from the TLS layer, like trusted CAs, supported signature
> algorithms, etc).
> I am against changing the token type/scheme from Bearer to MTLS.  Mostly
> because of backwards compatibility issues - we already have customers that
> have deployed mTLS widely, but also because of conceptual issues I have
> generally with distinct token_type/schemes:
> 1. Whether an access token is mTLS-bound or a pure bearer token is a
> property of what the RS enforces, not intrinsic to the token. As far as I
> am aware, there is no spec anywhere that says what an RS should do if it
> doesn’t understand a particular confirmation method associated with an
> access token. So you can easily at present have a situation where an AT is
> valid at multiple RSes, some of which understand mTLS-binding and some of
> which do not. Indeed, this is very likely (and desirable) when you are in
> the process of rolling out stronger security mechanisms on an RS-by-RS
> basis. (And what if you later decide to move from mTLS to DPoP?) IMO
> requiring that ATs always have one and only one associated PoP mechanism is
> a recipe for ossification.
> 2. IMO the “token_type” and Authorization scheme should be primarily about
> how the AT itself is conveyed to the RS, not about how any associated proof
> is. Although “Bearer” is not the most appropriate name, I would rather we
> stuck to that one scheme for conveying ATs regardless of whether they are
> pure bearer tokens, bound tokens, or whatever. To me, the important part of
> “Bearer” is that it tells the RS that it can send this token directly to an
> introspection endpoint (or examine it locally) without first performing
> some additional processing on it.
> 3. I am generally in favour of allowing ATs to have 0, 1, 2 or any number
> of confirmation methods associated with them. If we want to make it easier
> for a client to figure out which ones an RS supports, I’d rather see this
> as an enhancement to the Bearer WWW-Authentication challenge - e.g.
> WWW-Authenticate: Bearer … supported_cnf_methods=mtls,dpop
> Anyway, can of worms well and truly opened…
> — Neil
> On 9 Dec 2021, at 13:23, Dmitry Telegin <
>> wrote:
> There following changes to RFC 8705 have been proposed:
> - introduce a new error code (e.g. "invalid_mtls_certificate") to be used
> when the certificate is required by the AS/RS, but the underlying stack has
> been misconfigured and the client didn't send one;
> - for bound token use, change Authorization scheme from Bearer to MTLS;
> - for token response returning a bound token, change token_type from
> Bearer to MTLS
> See discussion:
> Accepting the changes would imply a new RFC and the obsolescence of the
> current one. Two questions so far:
> - what's the group's general stance on this, would that be a welcome
> change?
> - if so, could we also hear from the implementors if there any other
> issues / suggested changes.
> Dmitry
> Backbase / Keycloak
> _______________________________________________
> OAuth mailing list
> _______________________________________________
> OAuth mailing list