Hi Torsten, >2.3.1.5. Request entity too large > > If the request size was beyond the upper bound that the authorization > server allows, the authorization server shall return a "413 Request > Entity Too Large" HTTP error response.
"413 Request Entity Too Large" should be changed to "413 Payload Too Large".. c.f. https://bitbucket.org/openid/fapi/issues/256/pushed-request-object-payload-too-large > Depending on client type and authentication method, the request might > also include the "client_id" parameter. The "request_uri" > authorization request parameter MUST NOT be provided in this case > (see Section 3). How about changing to: *the request might also include other request parameters such as the "client_id" parameter, the "client_secret" parameter, the "client_assertion" parameter, and so on.* Taka On Tue, Oct 1, 2019 at 3:36 PM Justin Richer <jric...@mit.edu> wrote: > To be clear, PAR is not the same as XYZ. Both are going to be inputs into > the conversation under txauth, and there are similarities, but they > shouldn’t be conflated. > > In PAR, the result has to be a URI because that’s what JAR defines as the > input. With XYZ, you get returned two things: a transaction handle and an > interaction URI. These are both opaque to the client. > > — Justin > > On Sep 30, 2019, at 8:33 AM, Dick Hardt <dick.ha...@gmail.com> wrote: > > I can understand the request URI being a URI that the client is providing > the AS, but why would the client's request URI be at the AS? > > As Justin has explained it in the past, the AS is returning a handle to > the transaction. The only party that understands that handle as far as I > know is the AS. It is meaningless to the client. Perhaps I am missing > something else? > ᐧ > > On Mon, Sep 30, 2019 at 2:53 AM Dave Tonge <dave.to...@momentumft.co.uk> > wrote: > >> 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
