Thanks Aaron, The timing here is a bit awkward as the draft is actually in IETF wide last call. But the AD has requested publication of a new -15 draft soon and concurrent with the LC to address some residual feedback from his review that didn't make it into -14. I'd like to aim to get changes addressing your feedback into -15. As such, PR https://github.com/oauthstuff/draft-oauth-rar/pull/91 has proposed changes based on your comments and my replies inline below.
On Fri, Oct 28, 2022 at 12:40 PM Aaron Parecki <aa...@parecki.com> wrote: > In reviewing RAR, I noticed a couple things. I've submitted the editorial > suggestions below as a PR. > > * Changed "the requested scope, i.e., the permission, of an access token" > to "the requested scope, i.e., the limited capability, of an access token". > Scope isn't defined as "permission" in OAuth 2.0. Permissions are often > handled by internal mechanisms other than scopes, and scopes are more about > limiting the capability of an access token. > * Clarified the description of Token Introspection > * "the user consent" -> "the user consent prompt" > * "attacker vector" -> "attack vector" > > https://github.com/oauthstuff/draft-oauth-rar/pull/90 > The PR has been merged and the changes will be in draft -15. > > I have some other notes as well, which I didn't have a quick fix for to > suggest in the PR. > > https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-9.1 > > Would it be more appropriate to reference the JWT Access Token spec > (RFC9068) rather than just the JWT spec (RFC7519) now that it's an RFC? > I think RFC7519 is still the appropriate reference in this context. The authorization_details claim here is for conveying the authz deets in any JWT access token. Not just RFC9068 ones. > > https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-9.2 > > Section 9.2 about the token introspection response is missing normative > language about whether and what specifically is recommended. The section > 9.1 above does have "RECOMMENDED" for the authorization_details parameter. > I think this should match, but I'm not clear on exactly where this should > go. Perhaps this also suggests that "The authorization_details member > contains..." is ambiguous as to whether this is normative or just a > suggestion, and should be fixed as well. > I agree they should match and that it's not clear where exactly it would fit with the text that's there now. I made an attempt at it in the PR though. > > https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-10 > > Again, "The AS publishes" and "Clients announce" are missing a keyword > "MUST/SHOULD/MAY", so it's not clear whether these are required. > Keywords (that seemed most appropriate) added with the PR. > > https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-11.3 > > "the JSON schema id" should this be "the JSON Schema ID" or "the JSON > Schema `id`"? > I'm honestly not sure but after looking around a bit on json-schema.org I'm thinking it should be "JSON Schema identifier". > > https://www.ietf.org/archive/id/draft-ietf-oauth-rar-14.html#section-13 > > Is this a "MUST" or a "must"? > Probably "MUST" for consistency with the section at least. > > "to learn the user data" - this sounds awkward, should it be "the user's > data"? Not sure if there is a better suggestion. > Will go with your suggestion. -- _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
