OAuth 2.0 Pushed Authorization Requests
draft-ietf-oauth-par-10

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.