Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt

[Travis Spencer <[e-mail]>]

Some feedback on this draft compared to the last one that I read:

* The acronym RS and the term "resource server" are used
inconsistently. It would read better IMO if the acronym was always
used after being defined or if resource server was always spelled out.
Same for AS, but less so. Maybe this is just me, so take it as you
will.

* In section 3, is it saying that JWE is MTI? From the end of section
5, it seems not. If so, this statement should be clarified IMO:

> To support encrypted token introspection response JWTs, the authorization server MUST also be provided with the respective resource server encryption keys and algorithms.

Maybe just change it to "If the AS supports encrypted token
introspection response JWTs..."

* Instead of issuing an expired JWT (or in addition) I think it should
be valid for the AS to reply with a 201, no content. For this reason,
I think that section 5 should be updated thusly:

> If the access token is invalid, expired, has been revoked, or is not intended to be consumed by the calling resource server (audience), the authorization server MUST set the value of the response claim
"active" to "false" if it chooses to issue a JWT. Otherwise, this
claim is set to "true". If it does not issue a JWT, the AS MUST reply
with an HTTP 204, no content, status code. If it does include a JWT
with an "active" claim of "false", the AS MAY reply with an HTTP 204,
no content, status code.

The rational is that the AS may not want to exert effort to make a
signed/encrypted JWT that is expired. Not having the token is usually
as good or better than having an expired one.

* This statement makes the audience sound too narrow IMO:

> The value of the "aud" claims MUST identify the resource server receiving the token introspection response.

Because the AS's policy may stipulate that the audience could be
others in addition to the RS some wording should be added like "the
'aud' claim MUST identify the resource server receiving the token
introspection response and MAY contain other values based on its
policy."

* The "M" in email in section 5 should not be capitalized IINM.

* In section 5, this is very broad.

> The AS determines based on the RS-specific policy what claims about the resource owner to return in the token introspection response. The AS MUST ensure that the release of any privacy-sensitive data is legally based.

So, an AS must follow the law? Is that all that it's saying? Section 9
seems to restate this point. Is conformance to the law really up to
this doc to stipulate? If the AS breaks the law, it don't conform to
the protocol. This seems very meta.

* 1st in section 9 should be spelled out as "first" and IINM it should
be "first-party" since it's being used as an adjective.

* Last but certainly not least is the restriction that the current
version places on disallowing of the introspection JWT response as an
access token. This is done in numerous places (the note in section 5,
8.1, etc.). I understand that there are some objection to this usage,
but we have had this protocol deployed for years, and it's running in
dozens of customer's facilities. This will break real applications of
this specification without a clear alternative. As we discussed in
London last year at the IETF meeting, token exchange isn't a viable
alternative (even still in its current draft form to the best of my
knowledge). Without a workable alternative to move to, I emphatically
but humbly request that this specification remove this restriction.




On Fri, Sep 20, 2019 at 2:28 PM <[e-mail]> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
>         Title           : JWT Response for OAuth Token Introspection
>         Authors         : Torsten Lodderstedt
>                           Vladimir Dzhuvinov
>         Filename        : draft-ietf-oauth-jwt-introspection-response-08.txt
>         Pages           : 18
>         Date            : 2019-09-20
>
> Abstract:
>    This specification proposes an additional JSON Web Token (JWT)
>    secured response for OAuth 2.0 Token Introspection.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-08
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth