Hi Brock Answers inline:
> On 28 Sep 2023, at 19:39, Brock Allen <brockal...@gmail.com> wrote: > > Hello -- > > While implementing PAR, some questions came up around the request_uri, > expiration, and one-time use semantics. > > 1: I found this conversation: > https://mailarchive.ietf.org/arch/msg/oauth/Xp5Wyt4N9U6RZZzMd6RctU3koQw/# > > And so after reading it, my sense is that the request_uri one-time use > semantics is "upon successful authorization response". Is that a fair > conclusion? I’m not sure there was a clear conclusion in those messages - I’m definitely interested to hear other people’s interpretations. I have certainly heard of cases on Android where treating the request_uri as strictly one time use has resulted in failures due to some browsers appearing to fetch the url before launching the deep link as per the web2app pattern. So some leeway seems necessary. > 2: The spec says that a typical range of values for the expiration to be > between 5 and 600 seconds. I guess someone with a low value is not expecting > the end user to do any sort of interactive login, whereas the higher number > is assuming the user does need to perform an interactive login. Is that a > fair conclusion? I have always expected that the expiry relates to the time until the request_uri is presented to the authorization server. If it is not expired at that point I think the authorization server server should continue and that the expiry time of the request_uri should not be a factor after that. > 3: Any suggestions for an error response from the authorize endpoint when an > expired or consumed request_uri is passed? invalid_request_uri as per https://www.rfc-editor.org/rfc/rfc9101.html#section-7 seems like the appropriate one to me, and is the one the various FAPI certification tests that test PAR expect. Joseph
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
