On Wed, Nov 20, 2019 at 03:40:34AM +0000, Mike Jones wrote: > I did a complete read of > draft-ietf-oauth-security-topics-13<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13>. > My review comments follow, divided into substantive and editorial sections. > > SUBSTANTIVE > [...] > > 4.8.1.1. Metadata - This section suggests the use of a "resource_servers" > metadata value. This isn't defined by RFC 8414 nor do I see it the IANA > OAuth Authorization Server Metadata registry at > https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata. > Is this something that's been standardized elsewhere? If so, please add a > citation. If not, please clearly say that this metadata value is not > standardized, and is therefore unlikely to be interoperable.
I would go further and say that we should not document "best practices" that involve non-standardized values. > 4.8.1.1. Metadata - This section suggests the use a > "access_token_resource_server" token response value. Please likewise clearly > say that this parameter isn't a standard. (ditto) [...] > 4.8.1.3. Audience Restricted Access Tokens - Delete "basically". > > Many locations - The draft often uses the word "which" when you mean "that".. > For instance, in 4.9.2, please change "which could" to "that could" and in > 4.11 change "which are" to "that are". There's lots of places to look up the > difference in meaning, but a rule of thumb that's usually right is that if > you don't have a comma before the "which", it should probably be "that". The RFC Editor uses a "restrictive" vs. "non-restrictive" split for "that" and "which" -- see https://www.rfc-editor.org/styleguide/tips/ . -Ben (no hats) _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
