Note: This ballot was opened for revision 31 and is now closed.
After reading Sec 10.5, I was a little unclear how the client and auth server necessarily achieve interoperability, but I think it's just an editorial fix. If the server advertises that a signed object is required, then it cannot communicate with a client that does not support the extension. But if the object_required metadata is missing, then what is the metadata that tells the client to use a signed object if it can? IIUC the answer is that the server metadata includes the request_object_signing_alg_values_supported and/or request_object_encryption_alg_values_supported parameter in the metadata. It might be helpful to spell that out here. Is this correct?
Section 5.2, paragraph 5, comment: > The entire Request URI MUST NOT exceed 512 ASCII characters. There > are three reasons for this restriction. > > 1. Many phones in the market as of this writing still do not accept > large payloads. The restriction is typically either 512 or 1024 > ASCII characters. > > 2. On a slow connection such as 2G mobile connection, a large URL > would cause the slow response and therefore the use of such is > not advisable from the user experience point of view. What is the third reason? Also, 512 bytes at 2G speeds (~40Kb/s) take ~100ms to transmit; it's not clear that larger payloads would therefore be so much worse, given that the 2G latencies are probably the overriding issue here. Would a SHOULD NOT suffice? ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 4, paragraph 10, nit: - Signing it with the "RS256" algorithm results in this Request Object + Signing it with the "RS256" algorithm [RFC7518] results in this Request Object + ++++++++++
Thank you for the new security considerations text in Sections 10.7 and 10.8 since I last reviewed; it does a great job capturing my comments (and the current deployed reality). Thanks also to Watson Ladd for the latest secdir review and the authors for their responses to it. Section 6.2 The Authorization Server MUST validate the signature of the JSON Web Signature [RFC7515] signed Request Object. The signature MUST be validated using a key associated with the client and the algorithm specified in the "alg" Header Parameter. [...] The last version I reviewed had some language tying the algorithm used for verification back to a registration (and I commented that perhaps a registration might not always exist). This language seems to set the recipient up to blindly use the "alg" header parameter, even if it's "none", and we should probably have some hedging language here (I see we do have language elsewhere that bans "none" specifically)... If a "kid" Header Parameter is present, the key identified MUST be the key used, and MUST be a key associated with the client. Algorithm verification MUST be performed, as specified in Sections 3.1 and 3.2 of [RFC8725]. ... and maybe that would just take the form of swapping the order of these two sentences, now that I keep reading. Section 10.2 Do any of the procedures listed for steps (c) and/or (d) need to be performed in step (e) as well? (In particular, the requirements on the returned URI seem like they would still apply, and possibly the need for client authentication. Section 10.3 Nat's response at https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ to my previous review suggested that there might be value in future work that specifies the linkage across these endpoints to try to address the cross-phase attacks discussed in [FETT]. However, the paragraph that I had commented on (that mentions "an extension specification") has since been removed, and I failed to track down why just from a quick mailarchive search. There may well have been a good reason for removing it (and the reference to [FETT]), so please help refresh my memory if that's the case. Section 10.4 The introduction of "request_uri" introduces several attack possibilities. Consult the security considerations in Section 7 of RFC3986 [RFC3986] for more information regarding risks associated with URIs. My previous comments had mentioned that because of time skew the dereferenced request URI might actually have the contents of a different request than the one intended, and Nat's response at https://mailarchive.ietf.org/arch/msg/oauth/hB_ON_BR0fDf3NSDFcFo5MwbZ2Y/ pointed out that OIDC actually does use a nonce that would prevent such an occurrence. Hopefully Nat did get a chance to think about whether there was anything else that we should mention in this document, on this topic. ("There isn't anything else to mention here" is a fine answer; I just wanted to close the loop on that thread, since I didn't find one in the mail archive.) Section 11.1 nit: s/TFP/trusted third-party service/ (multiple instances), since we stopped using "Trust Framework Provider" in the main body. Sction 14.1 Not your fault, but BCP 195 now includes both RFC 7525 and RFC 8996 -- thank you for referencing it as BCP 195! I expect the RFC Editor will catch the new reference if you don't want to figure out how to notate it properly.
Ah, jwsreq. We meet again. Fortunately, looking only at the diff from my last ballot comments to this one, I only have a couple of minor things this time: Sections 9.2 and 9.3 each say they are registering "values", but each registers only one. "+1" to Francesca's points #1 and #5. Thanks for changing the media type name to use hyphens instead of dots. That avoided a big mess.
EDIT (09-04-2021) Thank you for addressing all my comments in v-34. Francesca =============== Original ballot - 07-04-2021 Thank you for the work on this document. I only have minor comments, the most interesting is probably 4. about if additional failure behavior should be defined at the AS. Francesca 1. ----- A Request Object (Section 2.1) has the "mime-type" "application/ FP: Please use "media type" instead of "mime-type" and reference https://tools.ietf.org/html/rfc6838 2. ----- The following is an example of the Claims in a Request Object before base64url encoding and signing. Note that it includes the extension FP: This example is the first time "base64url" appears in the document. I think it would make sense to mention that base64url is used when JWT is introduced, for example in the first paragraph of section 4. 3. ----- If decryption fails, the Authorization Server MUST return an "invalid_request_object" error. ... If signature validation fails, the Authorization Server MUST return an "invalid_request_object" error. ... If the validation fails, then the Authorization Server MUST return an error as specified in OAuth 2.0 [RFC6749]. FP: very minor, but I suggests you add "to the client, in response to the request defined in 5.2.2. of this specification". The reason is that the doc specifies that the AS might be having other exchanges (to fetch the Request Object) at the same time, and it can't hurt to be precise. Also regarding the reference to RFC 6749 - can you add a specific section to reference? 4. ----- specified in the "alg" Header Parameter. If a "kid" Header Parameter is present, the key identified MUST be the key used, and MUST be a key associated with the client. Algorithm verification MUST be ... same parameter is provided in the query parameter. The Client ID values in the "client_id" request parameter and in the Request Object "client_id" claim MUST be identical. The Authorization Server then FP: "MUST be a key associated with the client" - what if it is not? does the AS return an error to the client then? Same comment "... MUST be identical" - is any error returned if it's not? 5. ----- location, (b) check the content type of the response is "application/ FP: For consistency, please change "content type" to "media type".
Thank you for the work put into this document. Not too many differences since my review on the -26 (hence I reviewed mainly the diff). Please find below some non-blocking COMMENT points (but replies would be appreciated). I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 1 -- Is it normal that the abstract has a) and b) while the introduction has a), b), and c) ? -- Section 5.2 -- I see that "Many phones in the market as of this writing" is still in the text... Does this assertion still hold in 2021 ? Is it backed by some references ?