Hi Brian, Thanks for the detailed explanation, that at least resolves part of my concern.
But having said that, I must confess that I still don’t really understand why you wouldn’t want to set a limit (because you are writing an integer value in a field that is actually a double and hence not all integer values will fit) … but it is a non-blocking comment and I won’t push this any further. Regards, Rob From: Brian Campbell <bcampb...@pingidentity.com> Sent: 06 July 2021 22:52 To: Rob Wilton (rwilton) <rwil...@cisco.com> Cc: The IESG <i...@ietf.org>; draft-ietf-oauth-...@ietf.org; oauth-cha...@ietf.org; oauth <oauth@ietf.org>; Hannes Tschofenig <hannes.tschofe...@arm.com> Subject: Re: Robert Wilton's No Objection on draft-ietf-oauth-par-08: (with COMMENT) In this case the only entity that really has to cope with the lifetime is the same entity that controls the lifetime. The authorization server creates the request URI and its lifetime and retains the associated data for the stated time. The URI and expiry information is conveyed to the client. But the client will just use URI value immediately upon receipt (which invalidates it) and not care anything about it after that. The lifetime is largely just some extra information conveyed to the client that's arguably not even necessary. But sometimes things like that creep in during standards development. And I am aware of a test harness that is using the expiration info to test a negative case of checking that an expired URI value can't be successfully used. So I guess it's useful in some cases. But anyway, there's really no reason it'd be an especially large value and the only one that'd have to deal with it if it were is the same one that sets the value. On Thu, Jul 1, 2021 at 6:38 AM Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: Hi Brian, Thanks. Regarding caching, yes, I think that you are right that POST requests don’t get cached. Regarding the lifetime, why wouldn’t you want to specify a limit? It would seem to make it easier for implementations if they know what they never have to cope with a value over X. Thanks, Rob From: Brian Campbell <bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>> Sent: 30 June 2021 22:12 To: Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-oauth-...@ietf.org<mailto:draft-ietf-oauth-...@ietf.org>; oauth-cha...@ietf.org<mailto:oauth-cha...@ietf.org>; oauth <oauth@ietf.org<mailto:oauth@ietf.org>>; Hannes Tschofenig <hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>> Subject: Re: Robert Wilton's No Objection on draft-ietf-oauth-par-08: (with COMMENT) Thanks for the review Rob. I've endeavored to reply to your comments inline below. On Tue, Jun 29, 2021 at 2:54 AM Robert Wilton via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Robert Wilton has entered the following ballot position for draft-ietf-oauth-par-08: No Objection 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'? 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. 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? 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: 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"? Yeah, it probably should be that specific. I'll add the content type specificity to the document. Similarly, the cache control makes sense, but should the document mandate that the response must include "Cache-Control: no-cache, no-store"? 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, Rob 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. 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.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
