Thanks for the responses. I’ve cut out places where we seem to agree here and responded to the rest inline 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. > > That's really an implementation detail but I can note that some kind of > normalization is likely needed in comparing DNs. Might be worth pointing to to RFC4514 in a non-normative example here. The thing is, there are equivalent DNs that aren’t exact string copies of each other. We’ll want to avoid developers either doing a naive string comparison (leading to false negatives) or doing their own home-made regexes (leading to probable breakage and potentially security holes). > > > §2.1¶1: “configured or registered” is an unnecessary distinction, 6749 calls > it “registered” regardless of how it got there > > While I suppose that's true about 6749, I think colloquially 'registered' and > 'configured' have come to have more meaning to some/many people about how the > client came to be setup at the AS. So it might be strictly unnecessary but > I'd prefer to keep the "configured or registered" just to help say that it > doesn't matter how the AS came to get the expected DN for client. That’s a fair assessment, and I’m fine with it as-is in that case. > > > §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. > > I had a hard time describing things concisely here because of the history of > how and when the authentication methods registry came to be, it's name, and > where it's used. That text in ¶1 is what I was able to come up with that I > thought adequately explained it. It's admittedly not the most elegant prose > ever written but it does convey the info and I'm inclined to leave it. > However, I would be happy to consider alternative text here, if you've got > something specific to propose. I guess I just don’t think all that history is really needed right here. So I’d replace it with: For the PKI method of mutual TLS client authentication, this specification defines and registers the following authentication method metadata value into the "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters <https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#ref-IANA.OAuth.Parameters>]. If you feel it needs a reference, you can potentially put it in intro paragraph of the IANA section that sets the values, maybe? (§6.3) In the end I’m fine if the text stays — it’s not incorrect, I just feel it’s superfluous. Same comments apply to the other sections so I’m not going to copy them here. > > > §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. > > The line about Token Binding not having a monopoly on the binding of tokens > is admittedly a bit tongue-in-cheek and also a nod to the point you made the > other day about running out of names. > > Honestly though, this text wasn't intended to be defensive and, even when I > read it again, it doesn't come off that way to me. As usual, if you've got > specific text to propose that you think would be better, I'd be happy to > consider it. But I don't feel like the current text is particularly > problematic or in need of change. I took a crack at rewriting the second paragraph (note that I removed the first sentence entirely), but in the end it’s up to you how you want to present the comparison between the documents: Token Binding uses bare keys that are generated on the client, which avoids many of the difficulties of creating, distributing, and managing the certificates used in this specification. However, Token Binding requires support across different portions of the application stack, including TLS and browser implementations. At the time of this writing, there is relatively little support for it in available application development platforms and tooling. On the other hand, mutual TLS has been around for some time and enjoys widespread support in web servers and development platforms. As a consequence, Mutual TLS for OAuth 2.0 can be built and deployed now using existing platforms and tools. In the future, the two specifications are likely to be deployed in parallel for solving similar problems in different environments. — Justin
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
