[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwt-introspection-response-11: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 23 June 2021 18:14 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>, rifaat.s.ietf@gmail.com
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <162447208286.21677.10494308416979645858@ietfa.amsl.com>
Date: Wed, 23 Jun 2021 11:14:43 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5Pt_ZnF2iWmSyHuxgONNvVhlTf8>
Subject: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwt-introspection-response-11: (with COMMENT)

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-WG] Benjamin Kaduk's No Objection on draft… Benjamin Kaduk via Datatracker