JWT Response for OAuth Token Introspection
draft-ietf-oauth-jwt-introspection-response-12

Sections 11.1.1 and 11.2.1 each appear to contain three registration actions, but they all blend together in a common bullet list.  It might be nicer on IANA to separate them somehow, either into individual sub-subsections, or at least make them distinct lists.

Refreshing my earlier NoObj position (I don't really understand the changes anyway :-))

Thank you for the hard work put into this easy to read document. I have one single COMMENT (which is more a question)

Regards,

-éric

== COMMENTS ==

-- Section 1 --

"  ... However, there are
   use cases where the resource server requires stronger assurance that
   the authorization server issued the access token, including cases
   where the authorization server assumes liability for the token's
   content... "

C.1) The example given after the above text is not obvious to understand why this memo is required. While I am not an expert on OAuth, some more explanations would probably be useful.

Thanks for addressing my discuss and comments.

I am agreeing with what Alissa said:

I support Benjamin's DISCUSS point about the IESG being listed as the change controller for the registry entries. Overall I'd like to understand better the relationship between these registry entries and future updates to OpenID Connect (i.e., if the claims in the OpenID spec change, will this registry automatically need to change as well?).

I also support Adam's DISCUSS. How are claims like preferred_username currently used for the described use case of verifying person data to create certificates?

I support Benjamin's DISCUSS point about the IESG being listed as the change controller for the registry entries. Overall I'd like to understand better the relationship between these registry entries and future updates to OpenID Connect (i.e., if the claims in the OpenID spec change, will this registry automatically need to change as well?).

I also support Adam's DISCUSS. How are claims like preferred_username currently used for the described use case of verifying person data to create certificates?

If the linkage with the OpenID Connect 1.0 claims remains in the document, I think it would be good to add a note in Section 1.1 or a new Section 1.2 to indicate that the document uses terminology as defined in that spec (e.g., "End-User," "Relying Party," etc.).

Refreshing “no objection” position for -10.

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.)

I still believe that using non 2119 language (i.e., "must" rather than "MUST") would be better for the privacy section, but won't block the document on this minor point.