> The URI is intended to be a reference not a value. If the client could send a > JWT it would just send a request object instead of a request URI in the first > place. So the intent is that it’s random, and maybe we should just say that > explicitly.
I thought this language was explicitly to allow the use of structured values for the request_uri? From the introduction: > but it also allows clients requiring an even > higher security level, especially cryptographically confirmed non- > repudiation, to explicitly adopt JWT-based request objects. ---- Aaron Parecki aaronparecki.com On Thu, Sep 26, 2019 at 6:49 PM Justin Richer <jric...@mit.edu> wrote: > > Aaron, some comments inline. > > — Justin > > On Sep 26, 2019, at 8:30 AM, Aaron Parecki <aa...@parecki.com> wrote: > > Hi Torsten, > > I'm very glad to see this draft, I think it's definitely needed in > this space. Here are some of my thoughts on the draft. > > "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" > > > Is it acceptable for the AS to return just an opaque string, rather > than something prefixed with "uri:*"? I don't think anyone would be > confused about copypasting the exact string from the "request_uri" > response into the "request_uri" parameter even if it didn't start with > "urn:". If, for whatever reason, it is required that this value is > actually a URI, is there some expected namespace to use other than > "example"? I worry that if all the examples in the spec are just > "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up > using the text "example" because they don't understand why it's there, > and then it serves no purpose really.’ > > > This field must be a URI, as per JAR: > > request_uri The absolute URI as defined by RFC3986 [RFC3986] that > points to the Request Object (Section 2.1) that holds > authorization request parameters stated in section 4 of OAuth 2.0 > [RFC6749]. > > Somewhat awkwardly, the JAR spec currently states that the AS has to do an > HTTP GET on the request URI, so that will need to be fixed in JAR before it > goes forward. I don’t think that was always the case though, and I’m not sure > how that changed. > > As for the namespace, “example” is ok for an example URN. The problem with > URNs is that nobody really understands how to do domain-safe fully compliant > URNs. So perhaps we should instead use “urn:fdc:example.com:….” Instead (as > per https://tools.ietf.org/html/rfc4198). > > > The pushed authorization request endpoint shall be a RESTful API > > > I would drop the term RESTful and just say "HTTP API", as this > description is arguably RESTful at best. > > Depending on client type and authentication method, the request might > also include the "client_id" parameter. > > > I assume this is hinting at the difference between public clients > sending only the "client_id" parameter and confidential clients > sending only the HTTP Basic Authorization header which includes both > the client ID and secret? It would probably be helpful to call out > these two common examples if I am understanding this correctly, > otherwise it seems pretty vague. > > > Not quite, those differences are for the token endpoint, and this is > capturing things from the authorization endpoint. I don’t quite understand > the differentiation listed here either, though. > > > The "request_uri" value MUST be generated using a cryptographically > strong pseudorandom algorithm > > > I assume this includes the use of a random number inside of a JWT, in > case the AS wants to use JWTs as the "request_uri" parameter"? If so, > it's probably worth spelling that out as it kind of reads like it has > to be literally a random string at first glance. > > > The URI is intended to be a reference not a value. If the client could send a > JWT it would just send a request object instead of a request URI in the first > place. So the intent is that it’s random, and maybe we should just say that > explicitly. > > > That's all for now, thanks! > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > On Sat, Sep 21, 2019 at 1:02 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
