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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
