[OAUTH-WG] Review of oauth-mtls-07

[Justin Richer <[e-mail]>]

As promised in yesterday’s meeting, here’s my review of the oauth-mtls draft. We’ve recently implemented the spec from the AS and RS side for an as-yet-unreleased version of the Authlete service, and overall it’s in really good shape and very implementable as it stands today. Great work, and usable right now!



Comments, nits, and suggestions as follows:

§Abstract: Single sentence is a bit of a run-on that’s hard to follow. Suggested rewrite:

This document describes OAuth client authentication and sender-constrained tokens using Transport Layer Security (TLS) mutual authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization sever using mutual TLS, based on either single certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client’s mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.

§1¶1 (and throughout): The document goes back and forth between “mutual TLS authentication” and “TLS mutual authentication”, one should be picked and used consistently throughout. I realize this is spelled out in 1.2 but it might be worth the effort to use one form most of the time.
§1¶3: maybe don’t call it a “basic bearer token” and instead just a “bearer token” to avoid sounding judgmental	
§2¶1: suggest turning parenthetical into a list: “(regardless of whether the client was dynamically registered, statically configured, or otherwise established)”
§2¶3: It seems this paragraph is trying to leave the door open to other MTLS bound client auth methods, but such methods would require the definition of a different auth method parameter value and a new spec, not really an extension of what’s here. Therefore, suggest changing the end of the paragraph into a single compact sentence:

 The authorization server MUST enforce the
   binding a certificate to a specific client as described in either Section 2.1 <https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1> or
   Section 2.2 <https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.2> below.

§2.1¶1: It would be helpful to have a pointer on methods of comparing DNs. In our implementation we serialize them to strings using a canonical format (RFC2253) and doing a string comparison based on that. There are probably other ways, but it would be good to help developers avoid doing something naive like comparing two different serializations as strings. 
§2.1¶1: “configured or registered” is an unnecessary distinction, 6749 calls it “registered” regardless of how it got there
§2.1.1¶1: Is it necessary to introduce the registry here instead of just pointing to it? I’m fine with stating that the values are used in both discovery and client registration. 
§2.1.2: I’m only just now seeing the reference to RFC4514 here so this reference needs to be in the parent section as well. I was previously under the impression that no format was prescribed. 
§2.2¶1: Might want to say explicitly in here that the cert is in the JWK for the client (instead of lower down), as it would make the description of the JWKS_URI method make more sense upfront. This could also live in the parent section.
§2.2¶1: "certificate chain is not validated” should probably more explicitly point to the *client’s* certificate not being validated to prevent clients from not validating the *server’s* certificate chain.
§2.2¶1: Extraneous comma: "successfully authenticated, if the subject”
§2.2.1: Same comment as §2.1.1
§3.1¶2: As Brian mentioned in another message, this should specify “no padding”.
§4.1¶1: Probably intend “set up” instead of “setup”
§4.1¶4: “separate host name” should be “separate host name or port”
§4.2¶1: Wording is a bit awkward, suggest:

Since the resource server relies on the authorization server to perform client authentication, there is no need for the resource server to validate
   the trust chain of the client's certificate in any of the methods
   defined in this document.  
§4.3¶1: I get what this section is trying to say but it is confusingly laid out. Might be better to say something like “MTLS client auth and sender-constrained MTLS bound tokens can be used independently of each other”. 
§4.3¶1: This advice doesn’t just apply to public clients, so we probably don’t mean “would not authenticate the client” here but instead “would not authenticate the client using mutual TLS”, since the client could authenticate in other methods. Though it is important to point out that public clients can do this :too:, it’s just as important to allow a client to use private_key_jwt or client_secret_basic and still get a constrained token.
§A¶2: This paragraph reads a bit overly defensive. I understand the need to position the two drafts in relationship to each other, but the tone here could be adjusted significantly without losing the thrust of the main argument.