Subject: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-par-08: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 29 Jun 2021 01:54:52 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-oauth-par-08: 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 DISCUSS and COMMENT positions.

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

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

Hi,

Thanks for this document.  Outside my area of expertise, but I have a couple of
questions/comments:

Section 2:
   Due to historical reasons there is potential ambiguity regarding the
   appropriate audience value to use when employing JWT client assertion
   based authentication (defined in Section 2.2 of [RFC7523] with
   "private_key_jwt" or "client_secret_jwt" authentication method names
   per Section 9 of [OIDC]).  To address that ambiguity the issuer
   identifier URL of the authorization server according to [RFC8414]
   SHOULD be used as the value of the audience.  In order to facilitate
   interoperability the authorization server MUST accept its issuer
   identifier, token endpoint URL, or pushed authorization request
   endpoint URL as values that identify it as an intended audience.

I may be misunderstanding this text, but I note that by giving flexibility to
the client (i.e., the SHOULD) and being strict on the receiver (MUST support x,
y, z), this seems to encourage a proliferation.  Hence, I was wondering whether
this might be better the other way round.  I.e., be strict with what is sent,
and less strict with what is received: MUST send 'issuer identifier', MUST
receive 'issuer identifier', SHOULD receive 'token endpoint URL' and 'pushed
authorization request endpoint URL'?

2.
   *  "expires_in" : A JSON number that represents the lifetime of the
      request URI in seconds as a positive integer.  The request URI
      lifetime is at the discretion of the authorization server but will
      typically be relatively short (e.g., between 5 and 600 seconds).

JSON numbers are doubles, but the value is a positive integer.  Does it make
sense to put in a hard limit of 2^53, or given that these are expected to be
small numbers, 2^31 - 1?

3. The success and error examples both define:
    Content-Type: application/json
    Cache-Control: no-cache, no-store

The document states that the response should be JSON, but should it more
specifically specify the content type as "application/json"? Similarly, the
cache control makes sense, but should the document mandate that the response
must include "Cache-Control: no-cache, no-store"?

Regards,
Rob

---

From: Brian Campbell <[email-masked]>
Date: Wed, 30 Jun 2021 15:11:59 -0600

Thanks for the review Rob. I've endeavored to reply to your comments inline
below.

> https://datatracker.ietf.org/doc/draft-ietf-oauth-par/

While definitely not trying to encourage proliferation, the text is aiming
to help interoperability while also accounting for the treatment in other
documents (RFC7523/21) and existing implementations while also allowing for
consistent processing to be implemented across the different endpoints
where JWT client assertion based authentication can be employed. It's kinda
tricky and I don't know for sure that the current text is exactly right but
it's made it through the WG process and seen a number of implementations.

> sense to put in a hard limit of 2^53, or given that these are expected to

 I think the soft general guidance is enough and don't believe a hard upper
limit is needed.

3. The success and error examples both define:
> specifically specify the content type as "application/json"?

Yeah, it probably should be that specific. I'll add the content type
specificity to the document.

> Similarly, the

Although it makes sense not to cache I'm less comfortable mandating cache
control stuff - particularly for a response to a POST (that I'm not sure is
ever cacheable anyway) and for a client that is most likely not doing any
caching at all and would immediately encounter failures if it were.

Regards,

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._