Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

[Takahiko Kawasaki <[e-mail]>]

I'm sorry for this late response, but I'm also afraid that the requirement
"the authorization server supporting this specification MUST only use the
parameters included in the request object." in Section 6 of the draft 20
<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20> is problematic.

What I'd like to point out in addition to Filip's concerns is "error
handling before the request object is parsed successfully".


   1. If it is not allowed to refer to client_id outside the request
   object, errors that may occur before the request object is parsed
   successfully cannot be reported to the redirect URI (which is either
   explicitly specified by redirect_uri or the default redirect URI for the
   client) because it is impossible to check if the redirect URI has been
   registered for the client.
   2. If it is not allowed to refer to response_type outside the request
   object, it is impossible to determine the default position for response
   parameters (the query part and the fragment part) before the request object
   is parsed successfully.
   3. If it is not allowed to refer to response_mode outside the request
   object, errors that may occur before the request object is parsed
   successfully cannot be reported to the redirect URI in the way the client
   wished (query, fragment, form_post, query.jwt, fragment.jwt or
   form_post.jwt).
   4. If it is not allowed to refer to state outside the request object,
   the state cannot be included in error reporting caused by errors that
   may occur before the request object is parsed successfully.


Decent authorization server implementations try to report errors to the
redirect URI whenever possible. If it is not allowed to refer to parameters
outside the request object, the program waiting for a response at the place
pointed to by the redirect URI will never receive
error=invalid_request_object when the cause is "the request object failed
to be parsed".

I haven't found any convincing reasons yet that can justify introducing the
requirement that dares to break the backward compatibility. For me, the
following requirement in FAPI Part 2
<https://openid.net/specs/openid-financial-api-part-2-ID2.html>, 5.2.2.
<https://openid.net/specs/openid-financial-api-part-2-ID2.html#authorization-server>,
10. seems a good compromise.

shall require that all parameters are present inside the signed request
object passed in the request or request_uri parameter;



Best Regards,
Takahiko Kawasaki
Authlete, Inc.



On Thu, Aug 29, 2019 at 5:04 PM Torsten Lodderstedt <[e-mail]>
wrote:

>
>
> > Am 28.08.2019 um 23:23 schrieb Filip Skokan <[e-mail]>:
> >
> > - allows merging request object and regular parameters with request
> object taking precedence since it is a very useful feature when having
> pre-signed request object that's not one time use and clients using it wish
> to vary state/nonce per-request.
>
> +1_______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>