Hi! The following is my AD review of draft-ietf-oauth-jwt-introspection-response-03.
(1) Section 4. Per introspection_encrypted_response_alg, how is either signing or encryption being requested? Is it by also including an introspection_signed_response_alg? If that's the case, it is worth explicitly saying. (2) Section 4. Per introspection_encrypted_response_enc, I'm having trouble deconflicting these two sentences: [1] If "introspection_encrypted_response_alg" is specified, the default for this value is A128CBC-HS256. [2] When "introspection_encrypted_response_enc" is included, "introspection_encrypted_response_alg" MUST also be provided Sentence [2] explicitly states that "introspection_encrypted_response_alg" is required. However, the first sentence seems more tentative by saying that "if introspection_encrypted_response_enc" is present. (3) I want to talk through the personally identifiable information being specified as new introspection fields per Section 8.3 (e.g., name, birthday) being exposed. I was looking to ensure that it would always be encrypted in transit (and that only authorized clients could get it). I read that in Section 3, "[d]epending on the specific resource server policy the JWT is either signed, or signed and encrypted" and that per Section 4 that "[t]he authorization server determines what algorithm to employ to secure the JWT for a particular introspection response." Section 6.2 explicitly notes the threat of token data leakage (a more general case of my concern so thanks for that text). [RFC7662], Section 4 notes only that "the server MUST support Transport Layer Security (TLS) 1.2", but "support" is different than "the server MUST _use_ TLS". Therefore, it seems like there could be a case where the server could return an introspection response in the clear (e.g., no TLS, introspection_sig ned_response_alg). Am I missing something? My bias is to say something on the order of "TLS MUST be used". (4) I also want to talk through an unscrupulous protected resource trying to harvest introspection meta-data. I was looking for guidance related to the authorization of the introspection transactions. I found: Section 2.2 of [RFC7662] says important things like "For instance, an authorization server MAY limit which scopes from a given token are returned for each protected resource to prevent a protected resource from learning more about the larger network than is necessary for its operation." Section 4 of [RFC7662] says "If left unprotected and un-throttled, the introspection endpoint could present a means for an attacker to poll a series of possible token values, fishing for a valid token. To prevent this, the authorization server MUST require authentication of protected resources that need to access the introspection endpoint and SHOULD require protected resources to be specifically authorized to call the introspection endpoint." Section 6.2 of this draft provides guidance on defending against unauthenticated clients. How does the authorization server restrict a protected resource that _can_ authenticate to it from getting meta-data is shouldn't have access to? Something on the order of "the authorization server <uses the following data> to determine what a given protected resource is allowed to see". (5) Editorial Nits ** Section 3. Per "This JWT MAY furthermore contain all other claims described in Section 2.2. of [RFC7662] and beyond (e.g. as defined in [OpenID.Core])", would it be more timeless to say the fields specified in "OAuth Token Introspection Response" registry? ** Section 4. The first sentence of each parameters descriptions don't parse -- for example with introspection_signed_response_alg: "JWS [RFC7515] 'alg' algorithm JWA [RFC7518] REQUIRED", fully expanded that's "JSON Web Signature (JWS) [RFC7515] "alg" algorithm JSON Web Algorithms (JWA) [RFC7518] REQUIRED ...". The same is true for the write-ups in Section 5. ** Section 4. Editorial. Per "introspection_encrypted_response_enc": s/REQUIRED for encrypting introspection responses/ REQUIRED for authenticated encryption of introspection responses/ Regards, Roman _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
