Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-par-08: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I made a github PR with some editorial suggestions, at https://github.com/oauthstuff/draft-oauth-par/pull/70 . Section 1 Those apps typically invoke a custom tab with an URL that is translated into a GET request. Using "POST" would require the app to first open a web page under its control in the custom tab that in turn would initiate the form "POST" towards the authorization server. PAR is simpler to use and has additional security benefits as described above. This description leaves me with a feeling that I only have an incomplete picture of why POST is "prohibitively difficult" to use with mobile apps. It seems like the setup is describing a scenario where the authorization logic is operating inside a framework or environment provided by some other entity that is unwilling or unable to change the framework to accomodate new OAuth behavior. Is this other entity the author of the mobile app, or an app framework, or somethint else? Having a bit more description of the multiple entities involved and which one is trying to control the specific mechanics of the authorization request would make this depiction a more compelling argument that POST is unusable. Section 1.1 POST /as/par HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 My personal preference would be to have examples that just want a generic HTTP authentication mechanism to use something stronger than Basic, though I don't think this is something that I can insist on, at present. (Applies throughout.) HTTP/1.1 201 Created Cache-Control: no-cache, no-store Content-Type: application/json { "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", "expires_in": 90 } The "request_uri" element's semantics feels like a very natural fit for the native HTTP "Location" response header field (vs requiring a specific element in the JSON body of the response). I am less sure that there's a native HTTP element for the expiration time, as the HTTP timeouts tend to be associated with HTTP caching vs the actual lifetime of the resource. Section 2 It feels a little unfortunate that we have to reuse the metadata parameters relating to the token_endpoint_auth_method for PAR, but creating new metadata parameters that are basically always going to hold the same values is probably worse... Section 2.1 Any token endpoint parameters that are not related to client authentication have no defined meaning for a pushed authorization request. [...] I suppose that in most cases, whether or not a token endpoint parameter is related to client authentication should be fairly unambiguous ... but the registry at https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters has a dedicated column for "parameter usage location". It seems like it would be fairly straightforward to add "pushed authorization request" as an additional possible value there and remove the ambiguity. We could enumerate the existing parameters that are applicable and update the references for the registry to include this document. Section 2.1 The authorization server MUST process the request as follows: We often see descriptions along the lines of "this is not intended to constrain implementation techniques; any procedure that results in an equivalent outcome is permissible". This procedure is simple enough that we may not need to have concerns of that nature, though. Section 2.2 * "request_uri" : The request URI corresponding to the authorization request posted. This URI is used as reference to the respective request data in the subsequent authorization request only. [...] Would it be appropriate to use the phrase "single-use" in this description? Section 2.4 It is at the discretion of the authorization server to apply restrictions on supplied "redirect_uri" values, e.g. the authorization server MAY require a certain URI prefix or allow only a query parameter to vary at runtime. Is this expected to be discoverable by the client? Would there be a particular error code used, for example? Section 3 When the "application/x-www-form- urlencoded" HTTP entity-body "request" parameter is used, the request object MUST contain all the authorization request parameters as claims of the JWT. Additional request parameters as required by the given client authentication method are to be included as 'application/x-www-form-urlencoded' parameters in the HTTP request entity-body [...] I might flip this around and start off with "authentication request parameters required by a given client authentication method are included in the application/x-www-form-urlencoded request directly, and are the only parameters other than 'request' in the form body. All other request parameters, i.e., those pertaining to the authorization request itself, MUST appear as claims of the JWT representing the authorization request". The current formulation kind of hides the specifics of how to determine which parameter goes where -- the spec for the client authentication method in use is the authoritative one, IIUC. 1. If applicable, decrypt the request object as specified in JAR [I-D.ietf-oauth-jwsreq], section 6.1. 2. Validate the request object signature as specified in JAR [I-D.ietf-oauth-jwsreq], section 6.2. Do we want to say anything more about error handling if decryption or signature validation fails? Section 4 I think we should explicitly state that expired "request_uri"s are rejected as invalid. Section 5 Note that the presence of "pushed_authorization_request_endpoint" is sufficient for a client to determine that it may use the pushed authorization request flow. A "request_uri" value obtained from the PAR endpoint is usable at the authorization endpoint regardless of other authorization server metadata such as "request_uri_parameter_supported" or "require_request_uri_registration". Since this is the only mention of it in this document, and it's an OIDC parameter, maybe we should provide a reference for "require_request_uri_registration"? Section 7.1 An attacker could attempt to guess and replay a valid request URI value and try to impersonate the respective client. [...] Just to confirm my analysis here: an attacker that does guess a valid request URI value would probably also need to guess the corresponding "client_id", and if the request used PKCE, would also need to guess the PKCE value in order to successfully obtain a token response? I'm not sure whether any of that is worth mentioning or not here, though. Section 10.3 Section 12 Why is RFC 6749 not a normative reference? NITS Section 2 The pushed authorization request endpoint is an HTTP API at the authorization server that accepts HTTP "POST" requests with parameters in the HTTP request entity-body using the "application/x- www-form-urlencoded" format with a character encoding of UTF-8 as I'm not sure where "entity-body" is defined as the name for the request body in this case; draft-ietf-httpbis-semantics would seem to just have us refer to this as the "message body". Section 2.1 The client adds the parameters in "x-www-form-urlencoded" format with I'd suggest a different word than "adds"; these paratmers are the entire body, not appended to some earlier structure. Some parameters of the example request (e.g., "state") are duplicated across the multiple examples in the document. For those which are typically single-use in practice, we might consider using different values in the different examples (including in the JWT payload of the example request in Section 3). Section 7.4 The section heading is "Client Policy Change", which to me indicates a change in the policy of the client, that is, what the client requires. The text of the section indicates that this is discussing the AS's per-client policy, though, so I wonder if there is a better phrasing that could be used. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
