Dear Brian, I'd like to make some small comments.
2. / 1st paragraph / 4th line "for client authentications" --> "for client authentication" (remove 's' at the end) 2.1.1. / 1st paragraph / 4th line "used to indicated" -> "used to indicate" (remove 'd' at the end) 2.2. / 1st paragraph / 3rd line "a X.509 certificate" -> "an X.509 certificate" (replace "a" with "an") 2.2. / 1st paragraph / 11th line "info of one the" -> "info of one of the" (insert "of" between "one" and "the") 2.2. / 1st paragraph / 17th line "directly with at the" -> "directly at the" (remove "with") 2.2.1. / 1st paragraph / 4th line "used to indicated" -> "used to indicate" (remove 'd' at the end) 3.1. / 1st paragraph / 1st line "as a JSON Web Tokens" -> "as JSON Web Tokens" (remove 'a') 3.1. / 2nd paragraph / 6th-7th lines "are also sometimes also" -> "are sometimes also" (remove one "also") 3.3. & 3.4. After reading the specification, for me, "certificate_bound_access_tokens" sounds more natural than "mutual_tls_sender_constrained_access_tokens". Is there any special reason for the parameter name? 4.3. / 1st paragraph / 1st line "allows for the use" -> "allows use" (remove "for the", but I'm not sure because I'm not a native English speaker.) 6.1. / 1st paragraph / 2nd line "it is latest" -> "it is the latest" (insert "the" between "is" and "latest") By the way, isn't it necessary to define rules for REFRESH tokens? For example, "if a refresh token is issued, it MUST/SHOULD/MAY be also bound to the same certificate. When the token endpoint of the authorization server receives a refresh token request with a certificate-bound refresh token, ..." Best Regards, Taka 2017-10-13 17:31 GMT+01:00 Brian Campbell <bcampb...@pingidentity.com>: > Thanks for the review, Vladimir. And yes, sender-constrained access tokens > should also work in a token exchange scenario. > > On Fri, Oct 13, 2017 at 3:18 AM, Vladimir Dzhuvinov < > vladi...@connect2id.com> wrote: > >> Superb! Thanks for putting down everything that was discussed. I read the >> new version and have zero comments about it. >> >> Will sender-constrained access tokens also work in a token exchange >> scenario? >> >> (draft-ietf-oauth-token-exchange-09) >> >> Vladimir >> >> On 13/10/17 01:07, Brian Campbell wrote: >> >> I'm pleased to announce that a new draft of "Mutual TLS Profile for OAuth >> 2.0" has been published. The changes, based on feedback and discussion on >> this list over the last two months, are listed below. >> >> >> draft-ietf-oauth-mtls-04<https://tools.ietf.org/html/draft-ietf-oauth-mtls-04> >> <https://tools.ietf.org/html/draft-ietf-oauth-mtls-04> >> >> o Change the name of the 'Public Key method' to the more accurate >> 'Self-Signed Certificate method' and also change the associated >> authentication method metadata value to >> "self_signed_tls_client_auth". >> o Removed the "tls_client_auth_root_dn" client metadata field as >> discussed in >> https://mailarchive.ietf.org/arch/msg/oauth/<https://mailarchive.ietf.org/arch/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc> >> <https://mailarchive.ietf.org/arch/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc> >> >> swDV2y0be6o8czGKQi1eJV-g8qc<https://mailarchive.ietf.org/arch/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc> >> <https://mailarchive.ietf.org/arch/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc> >> o Update >> draft-ietf-oauth-discovery<https://tools.ietf.org/html/draft-ietf-oauth-discovery> >> <https://tools.ietf.org/html/draft-ietf-oauth-discovery> reference to >> -07 >> o Clarify that MTLS client authentication isn't exclusive to the >> token endpoint and can be used with other endpoints, e.g. >> RFC<https://tools.ietf.org/html/rfc7009> >> <https://tools.ietf.org/html/rfc7009> >> 7009 <https://tools.ietf.org/html/rfc7009> >> <https://tools.ietf.org/html/rfc7009> revocation and 7662 >> introspection, that utilize client >> authentication as discussed in >> >> https://mailarchive.ietf.org/arch/msg/oauth/<https://mailarchive.ietf.org/arch/msg/oauth/bZ6mft0G7D3ccebhOxnEYUv4puI> >> <https://mailarchive.ietf.org/arch/msg/oauth/bZ6mft0G7D3ccebhOxnEYUv4puI> >> >> bZ6mft0G7D3ccebhOxnEYUv4puI<https://mailarchive.ietf.org/arch/msg/oauth/bZ6mft0G7D3ccebhOxnEYUv4puI> >> <https://mailarchive.ietf.org/arch/msg/oauth/bZ6mft0G7D3ccebhOxnEYUv4puI> >> >> o Reorganize the document somewhat in an attempt to more clearly >> make a distinction between mTLS client authentication and >> certificate bound access tokens as well as a more clear >> delineation between the two (PKI/Public key) methods for client >> authentication >> o Editorial fixes and clarifications >> >> >> ---------- Forwarded message ---------- >> From: <internet-dra...@ietf.org> <internet-dra...@ietf.org> >> Date: Thu, Oct 12, 2017 at 3:50 PM >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt >> To: i-d-annou...@ietf.org >> Cc: oauth@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Web Authorization Protocol WG of the IETF. >> >> Title : Mutual TLS Profile for OAuth 2.0 >> Authors : Brian Campbell >> John Bradley >> Nat Sakimura >> Torsten Lodderstedt >> Filename : draft-ietf-oauth-mtls-04.txt >> Pages : 18 >> Date : 2017-10-12 >> >> Abstract: >> This document describes Transport Layer Security (TLS) mutual >> authentication using X.509 certificates as a mechanism for OAuth >> client authentication to the authorization sever as well as for >> certificate bound sender constrained access tokens. >> >> >> The IETF datatracker status page for this draft >> is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ >> >> There are also htmlized versions available >> at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-04https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-04 >> >> A diff from the previous version is available >> at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-04 >> >> >> 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. >> >> Internet-Drafts are also available by anonymous FTP >> at:ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
