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

[Vladimir Dzhuvinov <[e-mail]>]

Why not leave this to be an AS policy, or to be defined by specific
profiles?

We have had a simple AS setting which allows or prohibits parameters
outside the JWT:

  * If parameters outside the JWT are allowed, they are merged, with the
    JWT-secured ones having precedence.

  * If parameters outside the JWT are prohibited, and any are found, an
    invalid_request error with message is returned.

This allowed us to handle OpenID requests in applications requiring all
parameters to be signed. I believe the FAPI profile also has this
requirement. But there can well be applications and scenarios where some
of the parameters (e.g. client_id, scope, redirect_uri) may need to be
pre-signed / made invariable by some 3rd party, while leaving state and
PKCE be set by the client.

My concern is not so much about the backward compatibility, but that
we're trying to make a decision which seems to be better left to JAR
applications and profiles.

Letting the AS decide on the merge or not-merge is my preference.

Vladimir

On 02/01/2020 19:35, Justin Richer wrote:
> For solution [2], this is the behavior that’s required for OIDC today,
> so I would say that’s the New Client behaving like an Old Client in
> order to talk to an Old Server. So in reality, (2) causes the request
> to be rejected, and that’s OK.
>
> I don’t think it’s viable to require parameters to exist inside the
> request object at all times. Nor should we try to enumerate which
> parameters go inside and outside at all times — at least from the
> JAR/OAuth level of things. I think there are too many things that are
> application and deployment specific for us to make this call. The very
> nature of the request object changes for people — some have a static
> object that’s deployed with clients and some have something that the
> client creates at runtime for each request. 
>
> If the instead the New Server requires that any parameters duplicated
> between the two places have to match (the OIDC method) or that in a
> conflict the request object values take precedence (the merge method),
> then problems 3-1 and 3-2 go away. 
>
> With the merge-and-precedence behavior, which is what I thought that
> JAR had during WGLC, [3-1] is well-defined. The request is processed
> the same way every time because this is a New Server. The client is
> going to do OIDC’s “duplicate” method, so “merge with precedence” is
> effectively a no-op.
>
> With the merge-and-precedence behavior, [3-2] doesn’t happen because
> the required parameters aren’t required to be in the request object
> itself. As long as the request object is valid, it protects all
> parameters within it. I don’t think it’s up to us to determine what
> makes sense to put in that object. Security guidance is probably a
> good idea here.
>
> Solution [3] is what Old Clients already do in OIDC today, so that’s
> what already happens and why problem space (3) isn’t a problem.
>
>  — Justin
>
>> On Jan 2, 2020, at 12:24 PM, Takahiko Kawasaki <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>> Thank you, Justin. Actually, I wanted to see someone write a summary
>> about what happens in each combination from a viewpoint of both RP
>> and AS with regard to backward compatibility (as I told you in other
>> channel just before you posted your email ^_^).
>>
>> So,
>>
>> *(1) New Client + New Server*
>> No problem will happen.
>>
>> *(2) New Client + Old Server*
>> *[Problem 2-1]* If an authorization request contains 'request' or
>> 'request_uri' but doesn't have old mandatory request parameters
>> ('client_id' and 'response_type') outside the request object, the
>> request is rejected.
>>
>> *[Solution 2]* New Client should include the old mandatory request
>> parameters duplicately outside the request object. This means that
>> New Client should always send old mandatory request parameters
>> duplicately outside the request object if it wants to get maximum
>> compatibility.
>>
>> *(3) Old Client + New Server*
>> *[Problem 3-1]* If an authorization request contains 'request' or
>> 'request_uri' and some "optional" request parameters are not included
>> in the request object, AS will interpret the request differently.
>> Imagine what happens when optional parameters such as 'scope',
>> 'state', 'nonce', 'redirect_uri', 'response_mode', 'max_age',
>> 'acr_values', 'code_challenge', 'code_challenge_method' and 'prompt'
>> are not included in the request object but present outside the
>> request object.
>>
>> *[Problem 3-2]* If an authorization request contains 'request' or
>> 'request_uri' and some "mandatory" request parameters ('client_id'
>> and 'response_type') are not included in the request object, the
>> request is rejected.
>>
>> *[Solution 3]* Old Client should include all request parameters
>> duplicately in the request object. This means that Old Client should
>> always include all request parameters duplicately in the request
>> object if it wants to get maximum compatibility.
>>
>> *(4) Old Client + Old Server*
>> No problem will happen.
>>
>> - - -
>>
>> From a Client's point of view, for maximum compatibility, both Old
>> and New Clients should put mandatory request parameters outside the
>> request object and put all request parameters duplicately inside the
>> request object.
>>
>> [Problem 3-1] is difficult to detect because the authorization
>> request is not rejected. But, if New Server requires that all request
>> parameters outside the request object be put inside the request
>> object duplicately, [Problem 3-1] is handled as an error and thus
>> client developers can detect the problem.
>>
>> Consequently, introducing the following requirement in "FAPI Part 2,
>> 5.2.2
>> <https://openid.net/specs/openid-financial-api-part-2-ID2.html#authorization-server>,
>> 10" to JAR seems a good compromise (as I told before)
>>
>>     shall require that all parameters are present inside the signed
>>     request object passed in the request or request_uri parameter;
>>
>>
>> instead of just saying "the authorization server supporting this
>> specification MUST only use the parameters included in the request
>> object." which will bring about [Problem 3-1]. That is, how about
>> adding a rule like "if request parameters exist outside the request
>> object, they must exist inside the request object, too."?
>>
>> Any thoughts?
>>
>> Best,
>> Taka
>>
>>
>> On Fri, Jan 3, 2020 at 12:48 AM Justin Richer <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     I think the nature of the backwards incompatibility is important
>>     here. The way that things are now, using merge-with-precedence,
>>     you have the following matrix of compatibility:
>>
>>
>>                  New Server  |  Old Server  |
>>     -----------+-------------+--------------+
>>     New Client |      YES    |      NO      |
>>     Old Client |      YES    |     YES      |
>>
>>
>>     If you ask me, this is the right balance for a breaking change.
>>     Old clients, where the vast majority of the code is, don’t have
>>     to change. New clients can only talk to servers with the new
>>     features, which is the ability to drop parameters from the
>>     external request. This would apply to both OIDC and plain OAuth.
>>
>>     I think we should follow this kind of pattern in the discussions
>>     on OAuth 2.1, which I think JAR should be a part of/
>>
>>      — Justin
>>
>>
>>
>>>     On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki <[e-mail]
>>>     <mailto:[e-mail]>> wrote:
>>>
>>>     Breaking backward compatibility in this part would mean that
>>>     OpenID Certification given to AS implementations with
>>>     request_uri support will be invalidated once they support JAR.
>>>     It also would mean that test cases in the official conformance
>>>     suite need to be changed in a backward-incompatible manner,
>>>     which would implicitly encourage that all certified
>>>     implementations should re-try to get certification.
>>>
>>>     Changing the spec now might need more three to six months, but
>>>     it would be worth considering what we get and lose by saving the
>>>     months and breaking backward compatibility.
>>>
>>>     Best Regards,
>>>     Taka
>>>
>>>     On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura <[e-mail]
>>>     <mailto:[e-mail]>> wrote:
>>>
>>>         So, no change is OK? 
>>>
>>>         On Wed, Dec 11, 2019 at 10:01 PM John Bradley
>>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>             I also slightly prefer the merge approach. 
>>>
>>>             There are plusses and minuses to both. 
>>>
>>>             Changing again now that it is past ISEG review and
>>>             backing out a Discuss will add another three to six
>>>             months at this point, if we can get them to agree to the
>>>             change. 
>>>
>>>             John B. 
>>>
>>>             On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura
>>>             <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>                 Correct. The WG supported the precedence approach
>>>                 and even merge just like OIDC as it is very useful
>>>                 from the implementation point of view and helps with
>>>                 a bunch of deployment patter. 
>>>
>>>                 The push back came in from the Ben Campbell’s DISCUSS. 
>>>                 See 
>>>                 https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actually-specifies-the
>>>
>>>                 I am willing to go either way as long as people
>>>                 agree. My slight preference is to the original
>>>                 approach. 
>>>
>>>                 Best, 
>>>
>>>                 Nat Sakimura
>>>
>>>                 2019年8月29日(木) 6:56 Brian Campbell
>>>                 <bcampbell=[e-mail]
>>>                 <mailto:[e-mail]>>:
>>>
>>>                     FWIW, as best I can remember the change in
>>>                     question came as I result of directorate/IESG
>>>                     review rather than a WG decision/discussion.
>>>                     Which is likely why you can't find the "why"
>>>                     anywhere in the mailing list archive.
>>>
>>>                     On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan
>>>                     <[e-mail] <mailto:[e-mail]>>
>>>                     wrote:
>>>
>>>                         Well it kind of blows, doesn't it? I wasn't
>>>                         able to find the "why" anywhere in the
>>>                         mailing list archive around the time this
>>>                         was changed.
>>>
>>>                         My take on satisfying both worlds looks like
>>>                         this
>>>
>>>                         - allow just JAR - no other params when
>>>                         possible.
>>>                             (which btw isn't possible to do with
>>>                         request_uri when enforcing client based uri
>>>                         whitelist and the jwsreq 5.2.2 shows as much)
>>>                         - enforce the "dupe behaviours" defined in
>>>                         OIDC (if response_type or client_id is in
>>>                         request object it must either be missing or
>>>                         the same in regular request).
>>>                         - 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.
>>>
>>>                         I wish the group reconsidered making this
>>>                         breaking change from OIDC's take on request
>>>                         objects - allow combination of parameters
>>>                         from the request object with ones from
>>>                         regular parameters (if not present in
>>>                         request object).
>>>
>>>                         S pozdravem,
>>>                         *Filip Skokan*
>>>
>>>
>>>                         On Wed, 28 Aug 2019 at 23:02, Brian Campbell
>>>                         <[e-mail]
>>>                         <mailto:[e-mail]>> wrote:
>>>
>>>                             Filip, for better or worse, I believe
>>>                             your assessment of the situation is
>>>                             correct. I know of one AS that didn't
>>>                             choose which of the two to follow but
>>>                             rather implemented a bit of a hybrid
>>>                             where it basically ignores everything
>>>                             outside of the request object per JAR
>>>                             but also checks for and enforces the
>>>                             presence and value of the few regular
>>>                             parameters (client_id, response_type)
>>>                             that OIDC mandates.
>>>
>>>                             On Tue, Aug 27, 2019 at 5:47 AM Filip
>>>                             Skokan <[e-mail]
>>>                             <mailto:[e-mail]>> wrote:
>>>
>>>                                 Hello everyone,
>>>
>>>                                 in an earlier thread I've posed the
>>>                                 following question that might have
>>>                                 gotten missed, this might have
>>>                                 consequences for the existing
>>>                                 implementations of Request Objects
>>>                                 in OIDC implementations - its making
>>>                                 pure JAR requests incompatible with
>>>                                 OIDC Core implementations.
>>>
>>>                                 draft 14 of jwsreq (JAR) introduced
>>>                                 this language
>>>
>>>                                     The client MAY send the
>>>                                     parameters included in the
>>>                                     request object
>>>                                     duplicated in the query
>>>                                     parameters as well for the backward
>>>                                     compatibility etc.  *However,
>>>                                     the authorization server
>>>                                     supporting this
>>>                                     specification MUST only use the
>>>                                     parameters included in the request
>>>                                     object. *
>>>
>>>
>>>                                     Server MUST only use the
>>>                                     parameters in the Request Object
>>>                                     even if the
>>>                                     same parameter is provided in
>>>                                     the query parameter.  The
>>>                                     Authorization
>>>
>>>
>>>                                     The client MAY send the
>>>                                     parameters included in the
>>>                                     request object
>>>                                     duplicated in the query
>>>                                     parameters as well for the backward
>>>                                     compatibility etc.  *However,
>>>                                     the authorization server
>>>                                     supporting this
>>>                                     specification MUST only use the
>>>                                     parameters included in the request
>>>                                     object.. *
>>>
>>>
>>>                                 Nat, John, everyone - *does this
>>>                                 mean a JAR compliant AS ignores
>>>                                 everything outside of the request
>>>                                 object while OIDC Request Object one
>>>                                 merges the two with the ones in the
>>>                                 request object being used over ones
>>>                                 that are sent in clear?* The OIDC
>>>                                 language also includes sections
>>>                                 which make sure that some required
>>>                                 arguments are still passed outside
>>>                                 of the request object with the same
>>>                                 value to make sure the request is
>>>                                 "valid" OAuth 2.0 request
>>>                                 (client_id, response_type),
>>>                                 something which an example in the
>>>                                 JAR spec does not do. Not having
>>>                                 this language means that existing
>>>                                 authorization request pipelines
>>>                                 can't simply be extended with e.g. a
>>>                                 middleware, they need to branch
>>>                                 their codepaths.
>>>
>>>                                 Is an AS required to choose which of
>>>                                 the two it follows?
>>>
>>>                                 Thank you for clarifying this in
>>>                                 advance. I think if either the
>>>                                 behaviour is the same as in OIDC or
>>>                                 different this should be called out
>>>                                 in the language to avoid confusion,
>>>                                 especially since this already exists
>>>                                 in OIDC and likely isn't going to be
>>>                                 read in isolation, especially
>>>                                 because the Request Object is even
>>>                                 called out to be already in place in
>>>                                 OIDC in the JAR draft.
>>>
>>>                                 Best,
>>>                                 *Filip*
>>>                                 _______________________________________________
>>>                                 OAuth mailing list
>>>                                 [e-mail] <mailto:[e-mail]>
>>>                                 https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>                             /CONFIDENTIALITY NOTICE: This email may
>>>                             contain confidential and privileged
>>>                             material for the sole use of the
>>>                             intended recipient(s)... Any review,
>>>                             use, distribution or disclosure by
>>>                             others is strictly prohibited.  If you
>>>                             have received this communication in
>>>                             error, please notify the sender
>>>                             immediately by e-mail and delete the
>>>                             message and any file attachments from
>>>                             your computer. Thank you./
>>>
>>>
>>>                     /CONFIDENTIALITY NOTICE: This email may contain
>>>                     confidential and privileged material for the
>>>                     sole use of the intended recipient(s). Any
>>>                     review, use, distribution or disclosure by
>>>                     others is strictly prohibited..  If you have
>>>                     received this communication in error, please
>>>                     notify the sender immediately by e-mail and
>>>                     delete the message and any file attachments from
>>>                     your computer. Thank
>>>                     you./_______________________________________________
>>>                     OAuth mailing list
>>>                     [e-mail] <mailto:[e-mail]>
>>>                     https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>                 -- 
>>>                 Nat Sakimura (=nat)
>>>                 Chairman, OpenID Foundation
>>>                 http://nat.sakimura.org/
>>>                 @_nat_en
>>>                 _______________________________________________
>>>                 OAuth mailing list
>>>                 [e-mail] <mailto:[e-mail]>
>>>                 https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>         -- 
>>>         Nat Sakimura (=nat)
>>>         Chairman, OpenID Foundation
>>>         http://nat.sakimura.org/
>>>         @_nat_en
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         [e-mail] <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>