Hi Neil, Torsten added this issue https://github.com/oauthstuff/draft-oauth-par/issues/53 from your questions/comments, which touches on some things, and maybe he can provide more thoughts. But I'll make an attempt here too.
In my mind, the one-time use suggestion on the request_uri came about less from the risks of replay and more from the fact that the contents of a particular auth request are unique to the one request. So it just kinda made sense to similarly limit the reference to the data in a request. A specific request can only be made once so it's suggested (though not required) that a request_uri that represents that request also be usable only once. I believe state and/or PKCE and/or nonce can prevent replay already but those take effect at different points in the whole dance and to catch replay of different artifacts. Agreed that it'd be good for the draft to have some more discussion about the risks of modification and disclosure of the request content. Torsten also agreed yesterday at a brief discussion during OSW so I'm hopeful he can add some good content to the draft :) Thinking about richer authorization requests that might have transaction data like payee account numbers or amounts or similar etc. gives some idea of requests where integrity and confidentiality would be good. And even more basic requests, preventing control or modification of something like code_challenge seems useful. On Thu, Jul 23, 2020 at 1:53 AM Neil Madden <[email protected]> wrote: > Can you expand on the risks of replay? It seems like if the request can be > replayed an attacker can also block the original request and inject the URI > into a different request - ie no replay. > > (Shouldn’t state and/or PKCE and/or nonce prevent replay already?) > > In general the draft could do with some discussion of why an attacker > being able to modify an authorization request is a risk. I might just be > lacking enough coffee this morning to understand the risk here. > > — Neil > > On 22 Jul 2020, at 23:14, Brian Campbell <bcampbell= > [email protected]> wrote: > > > Thanks Vladimir, both comments should be easy to address in -03 (HTTPS/TLS > required and SHOULD on short lifetime *and* single use). > > On Sun, Jul 19, 2020 at 12:55 PM Vladimir Dzhuvinov < > [email protected]> wrote: > >> Thanks for the update. With the "require PAR" AS and client metadata the >> spec is now "policy complete". I can't think of what else there is to add. >> >> >> I have two comments about -02: >> >> >> https://tools.ietf.org/html/draft-ietf-oauth-par-02#section-2 >> >> I didn't see a mention of https / TLS being required for the PAR >> endpoint. The reader could assume http is fine. >> >> >> https://tools.ietf.org/html/draft-ietf-oauth-par-02#section-2.2 >> >> Since the request URI can be replayed, its lifetime SHOULD be short >> and preferably limited to one-time use. >> >> The SHOULD is ambiguous here - does it apply to the lifetime only, or to >> the lifetime and the single use. >> >> >> Vladimir >> >> >> On 10/07/2020 21:36, Brian Campbell wrote: >> >> WG, >> >> A new -02 draft of "OAuth 2.0 Pushed Authorization Requests" has been >> published. A summary of the changes, taken from the document history, is >> included below for ease of reference. >> >> -02 >> >> * Update Resource Indicators reference to the somewhat recently >> published RFC 8707 <https://datatracker.ietf.org/doc/html/rfc8707> >> >> * Added metadata in support of pushed authorization requests only >> feature >> >> * Update to comply with draft-ietf-oauth-jwsreq-21 >> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21>, which >> requires >> "client_id" in the authorization request in addition to the >> "request_uri" >> >> * Clarified timing of request validation >> >> * Add some guidance/options on the request URI structure >> >> * Add the key used in the request object example so that a reader >> could validate or recreate the request object signature >> >> * Update to draft-ietf-oauth-jwsreq-25 >> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-25> and added >> note regarding >> "require_signed_request_object" >> >> >> ---------- Forwarded message --------- >> From: <[email protected]> >> Date: Fri, Jul 10, 2020 at 1:21 PM >> Subject: New Version Notification for draft-ietf-oauth-par-02.txt >> To: Filip Skokan <[email protected]>, Torsten Lodderstedt < >> [email protected]>, Brian Campbell <[email protected]>, >> Dave Tonge <[email protected]>, Nat Sakimura <[email protected]> >> >> >> >> A new version of I-D, draft-ietf-oauth-par-02.txt >> has been successfully submitted by Brian Campbell and posted to the >> IETF repository. >> >> Name: draft-ietf-oauth-par >> Revision: 02 >> Title: OAuth 2.0 Pushed Authorization Requests >> Document date: 2020-07-10 >> Group: oauth >> Pages: 18 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-oauth-par-02.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ >> Htmlized: https://tools..ietf.org/html/draft-ietf-oauth-par-02 >> <https://tools.ietf...org/html/draft-ietf-oauth-par-02> >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par >> <https://datatracker..ietf.org/doc/html/draft-ietf-oauth-par> >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-par-02 >> >> Abstract: >> This document defines the pushed authorization request endpoint, >> which allows clients to push the payload of an OAuth 2..0 >> authorization request to the authorization server via a direct >> request and provides them with a request URI that is used as >> reference to the data in a subsequent authorization request. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org.. >> >> The IETF Secretariat >> >> >> >> *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 [email protected]https://www.ietf.org/mailman/listinfo/oauth >> >> -- >> Vladimir Dzhuvinov >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > -- _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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
