> Am 23.09.2019 um 20:46 schrieb Janak Amarasena <janakama...@gmail.com>: > > > Hi, > >> Why do you think so? > > This is because I feel that validating the authorization request is part of > the authorization process and doing the validation is the responsibility of > the authorization endpoint. > > >> I would assume the same core service is used to check the payload, so no >> code duplication required. > > At the time what I meant was that the authorization request validation will > be done twice. Once at the /as/par endpoint and again at the authorization > endpoint. > > >> 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). > > I see, so if the authorization request is validated at the /as/par endpoint > the validation can be omitted at the authorization endpoint if the request > contains a "request_uri" (given that it belongs to the AS). If this is the > case I think it might be good to mention this in the spec with something like > "The authorization server MAY decided to omit the validation of the > authorization request if the uri sent in the request_uri parameter belongs to > the authorization server." WDYT?
WFM > > > Best Regards, > Janak Amarasena > >> On Mon, Sep 23, 2019 at 11:47 PM Torsten Lodderstedt >> <tors...@lodderstedt..net> wrote: >> 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
