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. Also, the majority case could be the endpoint receiving valid requests and the validation process will be duplicated at the authorization endpoint.
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 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
