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

From: Brian Campbell <[email-masked]>
Date: Thu, 30 Mar 2017 16:15:34 -0500

This document, which I hope to present and discuss briefly at tomorrow's
meeting, replaces (but keeps the feature) the Mutual TLS Authentication for
OAuth Clients
<https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00> that
was published leading up to the Seoul meeting
<https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html> and
adds mutual TLS sender constrained access to OAuth protected resources. The
concept for the latter was largely derived from one of the options in the
JPOP draft <https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04>. I
apologize for the 11th hour publication but hope some folks will have a
chance to read it.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, Mar 30, 2017 at 3:49 PM
Subject: New Version Notification for draft-campbell-oauth-mtls-00.txt
To: Brian Campbell <[email-masked]>, Nat Sakimura <
[email-masked]>, Torsten Lodderstedt <[email-masked]>, John
Bradley <[email-masked]>

A new version of I-D, draft-campbell-oauth-mtls-00.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:           draft-campbell-oauth-mtls
Revision:       00
Title:          Mutual TLS Profiles for OAuth Clients
Document date:  2017-03-30
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-campbell-oauth-mt
ls-00.txt
Status:         https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/
Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-mtls-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-campbell-oauth-
mtls-00

Abstract:
   This document describes Transport Layer Security (TLS) mutual
   authentication using X.509 certificates as a mechanism for both OAuth
   client authentication to the token endpoint as well as for sender
   constrained access to OAuth protected resources.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Dave Tonge <[email-masked]>
Date: Fri, 31 Mar 2017 17:07:36 +0100

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