Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-11: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss (and Comment) points! Just a couple final notes on the -11: Section 4 Please double-check that describing the resource server as "authenticating with a private-key JWT" is compatible with using the urn:ietf;params:oauth:client-assertion-type:jwt-bearer assertion type. I am not up-to-date on the precise semantics of that assertion type, offhand. Section 5 Token introspection response parameter names intended to be used across domains SHOULD be registered in the OAuth Token Introspection Response registry [IANA.OAuth.Token.Introspection] defined by [RFC7662]. I'm a bit surprised to see any normative terminology used on the question of whether response parameter names are to be registered, since RFC 7662 already has a requirement ("MUST") for this scenario. If the intent truly is to weaken the requirement from RFC 7662, it seems that some additional clarification is in order that this is a change from the existing specification and why it is a desirable change. (The "MAY extend the token introspection response" in the preceding paragraph, not quoted, is also already present in RFC 7662.) _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
