Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt

Brian Campbell <> Mon, 03 April 2017 18:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A77E31294D8 for <>; Mon, 3 Apr 2017 11:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id obh0_44BeIjT for <>; Mon, 3 Apr 2017 11:37:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95F361294D4 for <>; Mon, 3 Apr 2017 11:37:30 -0700 (PDT)
Received: by with SMTP id g2so126867388pge.3 for <>; Mon, 03 Apr 2017 11:37:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tx4pTSmiCVevros58vsLYLmf021w5abF8aEiCYDkCOU=; b=d8pxKcFkkuqv8trfOusPe0AxDMegiE9xivtC4VOLnqTA1vKA/HzHqK8+9bayq0p5UF Vkv9FKLuyLUfM93cIjOobXJJ3QIXzwUVowMnV8g2dIjk9HhY4wT1erhA7CUUh4JaXH+1 LQBQ/GTVgfGtCbZI3VipbKR7EV5tnXwuTH1qE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tx4pTSmiCVevros58vsLYLmf021w5abF8aEiCYDkCOU=; b=cZp0NK/YG2aVppe3jUyvwPMi+bJSx6h+ujDZBavX8QY5yO+XtV0Swg9qkqe6SwbCPF fhV3I/wSM/ytr+GQX1Nr/9+E8RAdvBdiU+1OqTyDwCmkdLER/FG72vCpGbc0vktLAInF 8jeMwtB8kHwQlmucb1oDgneTS54ZbOsX699UBiO/V7eUVmfcC1wXFglW5qGDjQKcWRSN Og7uZVNdFPX2kpfWbJwgSZRnA4dQIrvUxIugg+ik8ZxEMl4pTiIPkHjgNiO87BAZueCp 5k7e3WT4ND1oze7Qd3pKNwFoTxo9K4svSIsECGu6hILiUcQfzqlr6kl/h0cFPjKrkoBk 5kFA==
X-Gm-Message-State: AFeK/H37gO9HiVR4YDc1USf0ofb3dI8L6LK1vYLxBnEp8PtytPv8JdsdWSinRkkdUHKrly3W7fizPS3q3f11cEnL
X-Received: by with SMTP id p14mr23423143pli.164.1491244650111; Mon, 03 Apr 2017 11:37:30 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 3 Apr 2017 11:36:59 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Brian Campbell <>
Date: Mon, 03 Apr 2017 12:36:59 -0600
Message-ID: <>
To: Dave Tonge <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="f403045c7934a4bb8a054c47739c"
Archived-At: <>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-mtls-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Apr 2017 18:37:34 -0000

Hi Dave,

Thanks for the review, support, and feedback.

I've already removed the extraneous "can" in the source. The easy part...

I did struggle with terminology for many of the reasons you point out about
there being somewhat established terms that aren't quite the same as those
defined in the RFC.  And apparently I wasn't terribly consistent with the
terminology I did use.

I think the phrasing you suggest is pretty good and yes possibly more
clear. I'd happily take a pull request with such changes. Thank you.

The XML source of the document currently in a bitbucket git repo at


On Fri, Mar 31, 2017 at 10:07 AM, Dave Tonge <>

> Hi Brian
> Thanks for this - it will be very useful for open banking in Europe where
> cert based auth is required by law.
> I have a few suggestions around wording.
> Happy to submit these via pull request if it's helpful.
> 1. Typo - remove can from 1:
>  Mutual TLS sender constrained access tokens and mutual TLS client
> authentication are distinct mechanisms that *can* don't necessarily
> need to be deployed together.
> 2. Consistency of terminology in 2 (and throughout the document).
> In section 2 the following phrases are used:
>    - Mutual TLS for Client Authentication
>    - Mutual TLS Client Authentication to the Token Endpoint
>    - mutual TLS as client credentials
>    - mutual X.509 certificate authentication
> Interestingly RFC5246 does not refer to "mutual authentication" at all,
> but does refer to "client authentication".
> From an OAuth perspective, surely we are more interested in the fact that
> it is TLS client auth - than the fact that it is mutual. However referring
> to TLS Client Authentication would bring confusion as we would have two
> client definitions in play: the TLS Client and the OAuth Client
> "TLS Mutual Auth" and "Mutual TLS" are established phrases in the industry
> - even though they don't seem to be defined in any of the relevant specs,
> however, "Mutual TLS Client Auth" isn't.
> I'm not sure of the best solution for this, but would be interested as to
> whether the authors considered this phrasing to be clearer?
>    - Mutual TLS for Client Authentication
>    -> TLS Mutual Auth for Client Authentication
>    - Mutual TLS Client Authentication to the Token Endpoint
>    -> TLS Mutual Auth for Client Authentication to the Token Endpoint
>    - mutual TLS as client credentials
>    -> TLS X509 client certificate as client credentials
> Or alternatively, a definition of "Mutual TLS" could be provided earlier
> on in the document.
> Thanks again for your work on this spec.
> Dave Tonge