If I understand the proposal correctly, the request URI is opaque to the client. Correct?
If so, why not just treat it as an opaque string? If I were implementing the protocol, I would have the blob be a signed token so that I could verify the integrity before making a database call. It much easier to throw compute at a DDOS attack to verify a signature, than DB capacity. ᐧ On Thu, Sep 26, 2019 at 2:24 PM Justin Richer <jric...@mit.edu> wrote: > Yes, the request object is JWT-based, but the request URI is not. In other > words, you can post a JWT but what you get back is a URI, not the JWT > itself. The request URI was always meant to be a reference, and originally > it was explicitly a reference to a signed request object. > > — Justin > > On Sep 26, 2019, at 10:03 AM, Aaron Parecki <aa...@parecki.com> wrote: > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
