Hi Janak, thanks for your feedback to PAR as well.
> On 22. Sep 2019, at 21:51, Janak Amarasena <janakama...@gmail.com> wrote: > > Hi, > > Since the /as/par endpoint is intended to be used to store the actual > authorization request I feel that validating the authorization request as > mentioned in point 2 section 2.1(Request) should not be a responsibility of > the /as/par endpoint and that it should not validate the authorization > request. Why do you think so? Validating the request data at the pushed authorisation request endpoint has the advantage that the AS can refuse the process early. It also means the authorisation endpoint of the AS can safely assume all request URIs sent in Authorization Request that are minted by the same AS (which is detected based on its structure), are pre-checked and can be trusted (regarding the input validation). > Also, the majority case could be the endpoint receiving valid requests and > the validation process will be duplicated at the authorization endpoint. I would assume the same core service is used to check the payload, so no code duplication required. > > Also since section 2.2 (Successful Response) states; > The "request URI" MUST be bound to the "client_id" of the client that posted > the authorization request. > Wouldn't it be good to enforce the use of the clientId in section 4 > (Authorization Request) when the authorization request is made with the > "request_uri" parameter? > GET > /authorize?request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2&client_id=s6BhdRkqt3 > HTTP/1.1 There is no need for an additional client id since the request URI is already bound to the client_id passed to and, in case of a confidential client, authenticated in the pushed authorization request. best regards, Torsten. > > > Best Regards, > Janak Amarasena > > On Sat, Sep 21, 2019 at 4:32 PM Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: > Hi all, > > I just published a new draft that Brian Campbell, Dave Tonge, Filip Skokan, > Nat Sakimura and I wrote. > > https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 > > It proposes a new endpoint, called "pushed authorization request endpoint”, > that allows the client to push the Authorization Request payload with the AS > on a backchannel connection instead of a front channel interaction. The AS > provides the client with a request URI (according to draft-ietf-oauth-jwsreq) > that the client uses in a subsequent authorization requests to refer to the > pushed request data. > > We believe this simple mechanism will significantly increase OAuth security > and robustness since any application can use it by just sending the > parameters in the same encoding as used at the authorisation endpoint over a > HTTPS-protected and (for confidential clients) mutually authenticated > connection to the AS. It can also be used to push signed and encrypted > request objects to the AS, i.e. it provides an interoperable way to use > request objects managed at the AS for use cases requiring an even higher > security level. > > We look forward to getting your feedback. > > kind regards, > Torsten. > >> Begin forwarded message: >> >> From: internet-dra...@ietf.org >> Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt >> Date: 21. September 2019 at 12:47:28 CEST >> To: "Nat Sakimura" <n...@sakimura.org>, "Brian Campbell" >> <bcampb...@pingidentity.com>, "Torsten Lodderstedt" >> <tors...@lodderstedt.net>, "Dave Tonge" <d...@tonge.org>, "Filip Skokan" >> <panva...@gmail.com> >> >> >> A new version of I-D, draft-lodderstedt-oauth-par-00.txt >> has been successfully submitted by Torsten Lodderstedt and posted to the >> IETF repository. >> >> Name: draft-lodderstedt-oauth-par >> Revision: 00 >> Title: OAuth 2.0 Pushed Authorization Requests >> Document date: 2019-09-21 >> Group: Individual Submission >> Pages: 12 >> URL: >> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt >> Status: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ >> Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par >> >> >> 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 >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
