[OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-jwsreq-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.