Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-par-02.txt

[Neil Madden <[e-mail]>]

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=[e-mail]> 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 <[e-mail]> 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: <[e-mail]>
>>> Date: Fri, Jul 10, 2020 at 1:21 PM
>>> Subject: New Version Notification for draft-ietf-oauth-par-02.txt
>>> To: Filip Skokan <[e-mail]>, Torsten Lodderstedt <[e-mail]>, Brian Campbell <[e-mail]>, Dave Tonge <[e-mail]>, Nat Sakimura <[e-mail]>
>>> 
>>> 
>>> 
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> -- 
>> Vladimir Dzhuvinov
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth