I support adoption of draft-campbell-oauth-mtls. Now some comments on the doc:
1. [§2.3] The syntax of tls_client_auth_subject_dn is not specified. Perhaps LDAP's "String Representation of Distinguished Names" [RFC4514]? Perhaps a base64url-encoding of a DER-encoded DN? It would actually be better to allow any subjectAltName to be specified, instead of a DN. 2. [§2.3] Change the name of tls_client_auth_issuer_dn (maybe tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be too easy to assume this pair refer to the issuer and subject fields of the cert. PKI chains can be complex so the expected root might not be such a stable concept. For example, the Let's Encrypt CA chains to an ISRG Root and an IdenTrust DST Root [https://letsencrypt.org/certificates/]. 3. [§2.3] If a client dynamically registers a "jwks_uri" does this mean the authz server MUST automatically cope when the client updates the key(s) it publishes there? 4. [§3] An access token is bound to a specific client certificate. That is probably ok, but does mean all access tokens die when the client updates their certificate (which could be every 2 months if using Let's Encrypt). This at least warrants a paragraph in the Security Considerations. 5. [§3.1] "exp" and "nbf" values in the example need to be numbers, not strings (drop the quotes). 6. An access token linked to a client TLS cert isn't a bearer token. The spec should really define a new token_type for responses from the token endpoint. That might not necessarily mean we needs a new HTTP authentication scheme as well (it might just hint that "Bearer" wasn't quite the right name). -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
