[OAUTH-WG] Status summary of document in AD Evaluation status

[Roman Danyliw <[e-mail]>]

Hi!

Below is a summary explanation of where all of the documents that are with me (as AD) stand.  I hope this better explains the status in the datatracker.  

==[ draft-ietf-oauth-access-token-jwt
Status: AD Evaluation::Revised I-D Needed
(aka, after WG LC but before IETF LC pending edits the AD has requested)

Pending edits from AD review confirmed at https://mailarchive.ietf.org/arch/msg/oauth/t57XP7RICTpoI3FbOyrY0gpsNnE/.  After these are merged, this document can proceed to IESG Review.

==[ draft-ietf-oauth-jwsreq
Status: Status: Waiting for AD Go-Ahead:Revised I-D Needed
(aka, after the second WG and IETF LC, but IETF LC Directorate reviews require action)

All AD review and individual IETF LC feedback was addressed.

A few outstanding updates remain from the IETF LC SECDIR review -- https://mailarchive.ietf.org/arch/msg/secdir/5CrZTLR8v6cm8wZVkfY_Yywckcw/.

After these changes are made, this document can return for IESG Review.

==[ draft-ietf-oauth-jwt-introspection-response
Status: Waiting for AD Go-Ahead:Revised I-D Needed
(aka, after the second WG and IETF LC, but IESG DISCUSS position from first IESG requires actions)

-10 addressed:

* the 2nd AD review  -- https://mailarchive.ietf.org/arch/msg/oauth/6VPGZxXt12WRgXe4IXsWN7UA054/
* and the negotiated text from the thread in the 2nd IETF LC -- https://mailarchive.ietf.org/arch/msg/last-call/ZdceEhKUiBSmrBfKm2Nqa2jYs4Q/

Outstanding are closure on two DISCUSS points from the -08 IESG ballot (https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ballot/) 

* Ben Kaduk said: It looks like we need to register 'active' as a JWT claim?

'active' appears to be registered in https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response, but I believe Ben's point is that it is NOT registered in https://www.iana.org/assignments/jwt/jwt.xhtml#claims

* Ben Kaduk also said: 

I don't think the new semantics for "jti" in the introspection response are compatible with the RFC 7519 definition.  Specifically, we say that "jti" will be tied to the input access token, but 7519 says that "jti"
has to change when the contents of the JWT change ("MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object"), and we admit at least the possibility of "active" and "iat" changing.

Checking Section 5 of the -10, it contains:

         If the access token is invalid, expired, revoked, or is not
           intended for the calling resource server (audience), the
           authorization server MUST set the value of the "active"
           member in the "token_introspection" claim to "false" and
           other members MUST NOT be included.  Otherwise, the "active"
           member is set to "true".

I believe this is the source of Ben's concern.

Other necessary actions:

* Updated Shepherd write-up to capture the 2nd IETF LC feedback

Regards,
Roman