Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.txt

From: [email-masked]
Date: Fri, 31 Jul 2020 06:12:30 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

        Title           : OAuth 2.0 Pushed Authorization Requests
        Authors         : Torsten Lodderstedt
                          Brian Campbell
                          Nat Sakimura
                          Dave Tonge
                          Filip Skokan
	Filename        : draft-ietf-oauth-par-03.txt
	Pages           : 19
	Date            : 2020-07-31

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-par/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-par-03
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-par-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian Campbell <[email-masked]>
Date: Fri, 31 Jul 2020 09:29:44 -0600

WG,

On behalf of my multinational cohort of esteemed co-authors, I published
PAR -03 this morning (MDT) wanting to get a new draft out with some lead
time before the Aug 10 interim
<https://datatracker.ietf.org/meeting/interim-2020-oauth-11/session/oauth>
where PAR will be the topic de jour. The changes are summarized below,
which mostly consist of clarifications and various fixups to the text. The
"bits on the wire" protocol seems to be stable at this point, so we got
that going for us, which is nice.

 -03

   *  Editorial updates
   *  Mention that https is required for the PAR endpoint
   *  Add some discussion of browser form posting an authz request vs.
      the benefits of PAR for any application
   *  Added text about motivations behind PAR - integrity,
      confidentiality and early client auth
   *  Better explain one-time use recommendation of the request_uri
   *  Drop the section on special error responses for request objects
   *  Clarify authorization request examples to say that the client
      directs the user-agent to make the HTTP GET request (vs. making
      the request itself)

---------- Forwarded message ---------
From: <[email-masked]>
Date: Fri, Jul 31, 2020 at 7:12 AM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-03.txt
To: <[email-masked]>
Cc: <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Abstract:

_______________________________________________
OAuth mailing list
[email-masked]
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._

---

From: Francis Pouatcha <[email-masked]>
Date: Fri, 31 Jul 2020 19:00:43 -0400

Bellow is the only remark I found from reviewing the draft draft:

2.1.  Request:

requires the parameters "code_challenge" and "code_challenge_method" but
https://openid.net/specs/openid-financial-api-part-2-ID2.html#confidential-client
mentions
that RFC7636 is not required for confidential clients. I guess those two
parameters have to be taken off the mandatory list and pushed to the list
below.

- Using jwsreq, non repudiation is provided as request is signed (jws).
This section also mentions that the request can be sent as form url
encoded (x-www-form-urlencoded). In this case, there is no way to provide
non repudiation unless we mention that request can be signed by client
using signature methods declared by the AS (AS metadata).

Best regards
/Francis

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/