So although for this spec, request_uri is just an opaque string, it is defined more generally in https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an:
* Absolute URI from which the Request Object (Section 2.1) can be obtained* And in section 5.2 as: > *The "request_uri" value MUST be either URN as defined in* > * RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230* > * [RFC7230] . The "request_uri" value MUST be reachable by the** > Authorization Server.* So this is why in the spec we have example of a URN and we have an ongoing discussion as to whether we should have a standard urn namespace that we recommend implementers use. In the interest of keeping the specs in sync I think it makes sense to keep it a URN for this spec, but with more of an explanation as to why? Dave On Fri, 27 Sep 2019 at 19:22, Dick Hardt <dick.ha...@gmail.com> wrote: > 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 >> <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 > --
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
