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 <tors...@lodderstedt.net> wrote: > > > > Am 28.08.2019 um 23:23 schrieb Filip Skokan <panva...@gmail.com>: > > > > - 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
