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

Dave Tonge <> Fri, 31 March 2017 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D87B124281 for <>; Fri, 31 Mar 2017 09:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 E2MksEcCHaHP for <>; Fri, 31 Mar 2017 09:07:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 301CB12950C for <>; Fri, 31 Mar 2017 09:07:58 -0700 (PDT)
Received: by with SMTP id y18so15654142itc.0 for <>; Fri, 31 Mar 2017 09:07:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7MbIkD4IIxP2j1ke19vp+4kORU/SZjBIdobIkS/pGSI=; b=T9bmjo0hHbEXw82ubpZoC1th9szv3lsD2LNiHkWHK/TeF51UfqNU9VtPpjY/sRLifU n5jB4vTgPk4TWxowkiFcdjW5XSVdk2ueFNd5avuaH74pvKrAAAkNhnJEbR1m0ZbZl9zK zLws+2h/PXzR8P2gM/WBVekqIBvTa52WPbm3U=
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; bh=7MbIkD4IIxP2j1ke19vp+4kORU/SZjBIdobIkS/pGSI=; b=hqQlTA2dcVG2Un5tflUDln51fwJUFX4Vsmsq/dioSkWbykg7Q+lXiWXICWuAWa/92H pQjiTeWEqo6EFK5zDGiZhxNcMG0/fx22SKcH323mLasMcJO7TGUkw3tPc1/BK3fGdP2F ku99G5sgH+I89jZYRjqDFGMndJqyY0Zr8O07FXoyxOAWbI5/QLnbM0wAEHERMvhmzcQg kKicfoXbaiG6fGBfEIcjvJE+HJvBsyrp0qXMFkd1tEwvtXD1xlDmkricTyuDG025stZ+ a1HHNrkNrft9p3f1kD/EkYSklKAy8oFwaFEkAjBdMrMP8h3A+q6UI0VR0yiZaSW7Rw5y yKBA==
X-Gm-Message-State: AFeK/H25Czaxopsth0hAc1zj+7LWkYLUORpEJKC4icUixj96PGUN5DX9GiR9AeKakDICRu4KhslrErKc7Tj0thVS
X-Received: by with SMTP id h185mr4880478ita.121.1490976477458; Fri, 31 Mar 2017 09:07:57 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 31 Mar 2017 09:07:36 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Dave Tonge <>
Date: Fri, 31 Mar 2017 17:07:36 +0100
Message-ID: <>
To: Brian Campbell <>,
Content-Type: multipart/alternative; boundary=001a1146f4704ed638054c09034d
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: Fri, 31 Mar 2017 16:08:00 -0000

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