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 > <[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 >>> >>> * Added metadata in support of pushed authorization requests only >>> feature >>> >>> * Update to comply with 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 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 >>> Htmlized: 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 list >>> [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
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
