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

Note: This ballot was opened for revision 05 and is now closed.

Roman Danyliw Yes

Comment (2021-01-26 for -10)
No email
send info
To IESG: This is a returning item.  The change required to address a DISCUSS from the first round was significant enough that the document was brought back to the WG to confirm the consensus.  This change moved the data of the introspected token into a top-level JWT claim to allow for the separation of the carrier JWT claims from the actual 
token introspection response claims.

Alvaro Retana No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2021-06-23 for -11)
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.)

Erik Kline No Objection

Martin Duke No Objection

Martin Vigoureux No Objection

Murray Kucherawy No Objection

Comment (2021-02-01 for -10)
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.

Robert Wilton (was Discuss) No Objection

Comment (2021-06-28 for -11)
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.

Warren Kumari No Objection

Comment (2021-02-02 for -10)
No email
send info
Refreshing my earlier NoObj position (I don't really understand the changes anyway :-))

Éric Vyncke No Objection

Comment (2019-09-02 for -07)
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.

(Adam Roach; former steering group member) (was Discuss) No Objection

No Objection (2020-01-18 for -08)
Thanks for addressing my discuss and comments.

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2019-09-04 for -07)
No email
send info
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?

(Alissa Cooper; former steering group member) No Objection

No Objection (2019-09-04 for -07)
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.).

(Barry Leiba; former steering group member) No Objection

No Objection (2021-01-31 for -10)
No email
send info
Refreshing “no objection” position for -10.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Mirja Kühlewind; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -07)
No email
send info