Ballot for draft-ietf-oauth-jwsreq
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
The directorate reviews are from 15 or more versions ago. I wonder if returning documents like this should be sent through the directorates again as matter of course. Abstract: "... the communication through the user agents are not ..." -- s/are/is/ Section 1 expressly cites two IANA URLs. I suggest simply naming the registry or sub-registry; the URLs might not be permanent. Or if you like the URL, do it as a reference, as you did with [IANA.MediaType]. The two bullets at the end of Section 1 toggle between "crypto" and "cryptography". I suggest picking one, preferably the latter (as did the rest of the document). In Section 3, should URI and URL include references to their defining RFCs? I realize a reader familiar with this space probably knows those terms, but they seem to be the only acronyms without a reference here. When would an implementer legitimately disregard the SHOULD in Section 4? As Benjamin Kaduk also expressed, I'm a little puzzled by this text in Section 5.2: "The "request_uri" value MUST be reachable by the Authorization Server." Is this part of the protocol? All of the subsections of Section 9 say: "This specification adds the following values to the "OAuth Parameters" registry established ..." but they all are actually modifying different sub-registries. I suggest naming the sub-registries explicitly. I realize the subsection titles have it right, but this line of repeated prose had me squinting a bit.
"NoObj" in the "I read the protocol action, and I trust the sponsoring AD so have no problem and / or this is outside my area of expertise or have no cycles" sense of the term. I'm largely relying on the fact that the previous Ops&Mgmt AD's, Kathleen, Jari, Ben, et al balloted Yes or NoObj.
Thank you for the work put into this document. Please find below a couple of non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -éric == COMMENTS == Should the document shepherd's write-up be updated ? It is dated October 2016... about 4 years ago. -- Section 5.2 -- Based on the long history of this document, is the following statement "Many phones in the market as of this writing still" still valid ? -- Section 5.2.1 -- Suggest to give a hint about the use of tfp.example.org (TFP is expanded only in section 10.2). == NITS == Please check the ID-NITS at https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-oauth-jwsreq-26.txt
- 4, "Since it is a JWT, JSON strings MUST be represented in UTF-8. ": Is that a new requirement, or a statement of fact about an existing JWT requirement? - 5.2: I'm not sure all readers will understand the meaning of "feature phone". Also, WAP and 2G don't seem all that relevant in 2017. - 5.2.1, first sentence, "The URL MUST be HTTPS URL.": Is that redundant to the similar requirement in the previous section? That instance had an "unless" clause, but this one does not. --2nd paragraph: "... MUST have appropriate entropy for its lifetime." Can you offer discussion (or a reference) for what constitutes "appropriate entropy"? -- 3rd paragraph: Is it reasonable that one would know if TLS would offer adequate authentication at the time of the signing decision? - 5.2.3, 2nd paragraph: "SHOULD use a unique URI": Why not MUST? Would it ever be reasonable to not do this? - 6.1, 2nd paragraph: What if validation fails? - 13: Do you want this in the final RFC? If not, it would be wise to add a note to the RFC editor to that effect.
Thank you for addressing my DISCUSS point. New nit: URN needs a reference to RFC 8141.
[updating again to link to https://mailarchive.ietf.org/arch/msg/oauth/POfiIMFXpUQTl5nPvgb7YDcLkE0/ to note that my first update kind of missed the point.] [updated to note that, per https://mailarchive.ietf.org/arch/msg/oauth/Lqu15MJikyZrXZo5qsTPK2o0eaE/ and the JWT BCP (RFC 8725), some discussion of why explicit typing is not used would be in order] Thanks for the many updates as we worked through the issues. Let's also add a note about "whose JWT Claims Set holds the JSON encoded OAuth 2.0 authorization request parameters" to the definition of Request Object in Section 2.1 (in addition to the note in the Introduction); my apologies for not including that when I suggested the change to the Introduction. Please update the Content-Length in the example in Section 5.2.3. Section 4 The client determines the algorithms used to sign and encrypt request objects. This decision can be based on metadata the client registered via dynamic client registration [RFC7591] using the parameters "request_object_signing_alg", "request_object_encryption_alg", "request_object_encryption_enc" as defined in the the IANA "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]. I had to read this ("this decision can be based on [...]") a few times to understand it. If I understand correctly, the idea is that the client will register with the AS the keys it will use for constructing the JAR, and in that way the AS has a binding from JAR-signing key to the specific client and request. So it's true that the decision of what key to use "can be based on" the metadata that the client registered, in that deciding to use a different key than the registered one(s) is likely to cause the AS to reject the request, but that's perhaps not the main point. Would it work to instead just say that "The keys used to sign and encrypt request objects (and thus, the algorithms that can be used with those keys) can be registered via dynamic client registration [...]"? Section 5.2 The contents of the resource referenced by the URI MUST be a Request Object, unless the URI was provided to the client by the Authorization Server. The "request_uri" value MUST be either URN as defined in RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230 [RFC7230] . The "request_uri" value MUST be reachable by the Authorization Server. I defer to my ART-area colleagues, but I'm not sure what it means for a URN URI to be "reachable"; is this requirement intended to only apply to the "https:" case? Section 5.2.1 It is possible for the Request Object to include values that are to be revealed only to the Authorization Server. As such, the "request_uri" MUST have appropriate entropy for its lifetime. For Is there a good reference for what the lifetime of such a request might be? Perhaps I've been reading too much of GNAP, but my intuition is that much of the time these requests will be single-use, and I don't have as clear of a picture for when they might persist longer. There are also potential security considerations for long-lived request objects, in terms of making sure that there is a binding between the client's intent to use a given request object for a given request, the user's authorization, etc. Section 5.2.3 (side note) I'd consider updating the timestamps in the example response (and perhaps moving to Apache 2.4+ as well?). Section 6.x (nit) I suggest consistency in subsection headings, so, e.g., "JWE Encrypted Request Object" and "JWS Signed Request Object". Section 6.2 The Authorization Server MUST perform the signature validation of the JSON Web Signature [RFC7515] signed request object. For this, the "alg" Header Parameter in its JOSE Header MUST match the value of the pre-registered algorithm. The signature MUST be validated against the appropriate key for that "client_id" and algorithm. This text suggests that pre-registration is mandatory, whereas up in Section 4 the client's choice of algorithm was merely something that "can be based on [metadata registered via dynamic registration]". I know that dynamic registration is not the only kind of registration possible, but we may want to wordsmith one (or both) location to improve the consistency. Section 6.3 I'd suggest reiterating here the requirement to verify "client_id" consistency between Request Object and request parameters. Section 10 I'd consider reiterating the security importance (i.e., what breaks if you don't apply the check) of a few key compliance requirements and which entity is responsible for enforcing them: - the "request" and "request_uri" parameters MUST NOT be included in request objects, from Section 4 - The request object has the mime-type "application/oauth.authz.req+jwt", also from Section 4 - The client_id in the request object has to match the client_id from the request query parameters, from Section 5 - The AS must only use parameters from the request object, even if the client has duplicated them in the query parameters, also from Section 5 Section 10.2 (e) When a third party, such as a Trust Framework Provider(TFP), provides an endpoint that provides a Request Object URI in exchange for a Request Object. The same requirements as (b) and (c) above apply. In addition, the Authorization Server MUST The (b) case is "the symmetric key for JWE encryption"; do we mean "(c) and (d)" here? Section 10.3 I'm not sure whether the key point of this section is "the following endpoints are RECOMMENDED [...] to use this practice" or "an extension specification should be created as a measure to address the risk". That is, can a deployment unilaterally apply the message-position and intended-interaction-endpoint protections now, or is there need for additional specification work first? Section 10.4 I'm not sure how much of this is distinct from the Request URI Rewrite discussed in Section 10.4.2, but having the request object contents be in a separately dereferenceable URI introduces risk of the dereferenced Request Object being dissociated from the triggering request. (This could happen due to internal error on the client or service hosting the requested URI or content skew over time, in addition to a request URI rewrite.) Having an externally provided single-use nonce in the reqest object would provide a mitigation, but it also (if I understand correctly) not compatible with all of the envisioned use cases for JAR. Section 10.5 Should the rejection of "alg":"none" be limited to the require_signed_request_object case, or universally applied? Section 12.1 (2) (Translation Process) The client uses the client credential that it got to push the request object to the TFP to get the "request_uri". If I understand correctly, the TFP also verifies that the request object is consistent with the claims the client is eligible for based on the certification step in (1). Section 12.2.2 Therefore, per-user Request Object URI should be avoided. If I understand correctly, the only possible alternative is to have per-request URIs (right?), as coalescing multiple user's requests into a single request object URI seems to pose several difficulties. We could perhaps make the recommended alternative more clear.
Should this document maybe update rfc6749?
Hi, Only one minor comment: I liked the reference to max URL size for older versions of Internet Explorer, but wonder if that is still really relevant in 2020? Or perhaps it could now be removed? Regards, Rob
- intro: "attacks... have been identified." yells out for a reference - it'd be a good bit better if implementers could easily find details of some such attacks, so I hope you add some refs here. - section 3; WAP? Really? I'm surprised any WAP technology would still be in use, even on feature-phones. Do you really need this? - section 4: I think it will turn out to be an error to allow for mixing query parameters and protected parameters (in a Request Object) in a single request. Do you really need that level of flexibility? It'd be simpler and less likely to be attackable to insist that all parameters be in the Request Object if one is used. (See also section 11.2.1 below.) - section 10: Is there nothing to be said about the new indirection caused by the request_uri? I'd have thought there were some corner cases that'd warrant a mention, e.g. if some kind of deadlock or looping could happen, or if one client (in OAuth terms) could use a request_uri value as a way to attempt attacks (to be assisted by an innocent browser) against some resource owner. - section 11: thanks for that, it's good. - section 11: Saying that an ISO thing is "good to follow" is quite weak IMO. (And is that ISO spec accessible? Hmm... it seems that one needs to accept cookies to get it which is wonderfully ironic;-) If the authors have the energy, I'd suggest trying to find better guidance that's more publically available in a privacy-friendly manner. (Or just drop the ISO reference if 6973 is good enough.)