Thank you for the review and comments, Takahiko. I've made all the editorial fixes in the github working copy so they will be in the next draft. I'll plan to publish that when the publication window opens again.
There is no special reason for the "mutual_tls_sender_constrained_access_tokens" name that I'm aware of. I believe Torsten chose the name and based it off of language in the draft. While "certificate_bound_access_tokens" does sound somewhat more natural, I'm hesitant to change it at this point. Unless there's support/consensus from the WG to make the change? Section 6 of The OAuth 2.0 Authorization Framework / RFC 6749 requires that refresh tokens be bound to the client to which they are issued. That indirectly binds the refresh token to the client credentials, which would be a certificate in the case of Mutual TLS OAuth Client Authentication. So I don't believe any additional treatment of refresh tokens is needed in the draft. On Wed, Nov 8, 2017 at 4:34 AM, Takahiko Kawasaki <daru...@gmail.com> wrote: > 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 >> >> > -- *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
