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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
