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

From: Brian Campbell <[email-masked]>
Date: Mon, 3 Apr 2017 12:36:59 -0600

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
https://bitbucket.org/b_c/internet-drafts/src/master/draft-campbell-oauth-mtls.xml?at=master&fileviewer=file-view-default

Thanks,
Brian

On Fri, Mar 31, 2017 at 10:07 AM, Dave Tonge <[email-masked]>
wrote:

> 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
>
>
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 6 Apr 2017 10:54:05 +0300

The cert / token binding is a significant upgrade on the previous
version, and I hope it will become an official WG item.

I also see that the comments about which certificate fields to use to
identify the client were addressed, this is important for interop.

Thanks for the great work,

Vladimir

On 31/03/17 00:15, Brian Campbell wrote:
> 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
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 7 Apr 2017 13:58:28 +0100

Hi Brian

Thanks, a minor typo in the example,
"x5t#s256" as opposed to "x5t#S256"

(sorry if it was already reported, might've missed it)

Cheers, Sergey
On 30/03/17 22:15, Brian Campbell wrote:
> 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
> 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.
>
> From: ** <[email-masked] <mailto:[email-masked]>>
> To: Brian Campbell <[email-masked]
> <mailto:[email-masked]>>, Nat Sakimura <[email-masked]
> <mailto:[email-masked]>>, Torsten Lodderstedt
> <[email-masked] <mailto:[email-masked]>>, John Bradley
> <[email-masked] <mailto:[email-masked]>>
>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt
> <https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt>
> Status:
>  https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/
> <https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/>
> <https://tools.ietf.org/html/draft-campbell-oauth-mtls-00>
> Htmlized:
>  https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00
> <https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00>
>
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org
> <http://tools.ietf.org>.
>
> The IETF Secretariat
>
>
>
>
>

---

From: John Bradley <[email-masked]>
Date: Fri, 7 Apr 2017 14:54:20 +0100

It was a test to see who was really reading it:)

---

From: Brian Campbell <[email-masked]>
Date: Fri, 7 Apr 2017 08:36:47 -0600

And Sergey is the only person to pass the test...

Thanks for catching that, Sergey. I'll get it fixed in the next revision.

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 7 Apr 2017 15:42:06 +0100

Hi John

I spotted it probably after the 10th iteration :-)

Cheers, Sergey
On 07/04/17 14:54, John Bradley wrote:
> On Fri, Apr 7, 2017 at 1:58 PM, Sergey Beryozkin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Brian
>
>         <https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00
>         <https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00>>
>         <https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html
>         <https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html>>
>         and
>         <https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04
>         <https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04>>. I
>         apologize
>         From: ** <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>, Nat Sakimura
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>,
>         Torsten Lodderstedt
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>, John Bradley
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>
>
>
>         <https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt
>         <https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt>>
>         Status:
>         <https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/
>         <https://datatracker.ietf.org/doc/draft-campbell-oauth-mtls/>>
>         Htmlized:
>          https://tools.ietf.org/html/draft-campbell-oauth-mtls-00
>         <https://tools.ietf.org/html/draft-campbell-oauth-mtls-00
>         <https://tools.ietf.org/html/draft-campbell-oauth-mtls-00>>
>         Htmlized:
>         <https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00
>         <https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00>>
>
>
>         Abstract:
>         until the htmlized version and diff are available at
>         tools.ietf.org <http://tools.ietf.org>
>         <http://tools.ietf.org>.
>
>         The IETF Secretariat
>
>
>
>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>

---

From: Steve Hutchinson <[email-masked]>
Date: Fri, 07 Apr 2017 16:28:24 +0000

Every time I think I couldn't be more impressed with the people who do
actual standards work, someone raises the bar.

Thanks Sergey!

Hutch

On Fri, Apr 7, 2017 at 10:42 AM Sergey Beryozkin <[email-masked]>
wrote:

> >         <
> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00
> >         <
> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00>>
> >         <
> https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html
> >         <
> https://www.ietf.org/mail-archive/web/oauth/current/msg16704.html>>
> >         and
> >         <
> https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt>
> >         <
> >         <
> https://www.ietf.org/internet-drafts/draft-campbell-oauth-mtls-00.txt>>
> >         Status:
> >         <
> https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00>
> >         <
> >         <
> https://datatracker.ietf.org/doc/html/draft-campbell-oauth-mtls-00>>
> >
> >
> >         Abstract:

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 7 Apr 2017 21:51:17 +0100

Hi All

I'm starting really believing now doing OAuth2 is as simple as spotting 
a difference between 'S' and 's' :-)

Thanks, Sergey
On 07/04/17 17:28, Steve Hutchinson wrote:
> On Fri, Apr 7, 2017 at 10:42 AM Sergey Beryozkin <[email-masked]
>     > On Fri, Apr 7, 2017 at 1:58 PM, Sergey Beryozkin
>     <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Hi Brian
>     >
>     >         <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >         <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>>>>, Nat Sakimura
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >         <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>,
>     >         Torsten Lodderstedt
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>>>>, John Bradley
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >         <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>
>     >
>     >
>     >
>     >         tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>
>     >         <http://tools.ietf.org>.
>     >
>     >         The IETF Secretariat
>     >
>     >
>     >
>     >
>     >
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>