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

From: Takahiko Kawasaki <[email-masked]>
Date: Thu, 2 Jan 2020 17:40:26 +0900

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 <[email-masked]> wrote:

> So, no change is OK?
>
> On Wed, Dec 11, 2019 at 10:01 PM John Bradley <[email-masked]> 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 <[email-masked]> 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=
>>> [email-masked] <[email-masked]>>:
>>>
>>>> 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 <[email-masked]>
>>>> 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 <
>>>>> [email-masked]> 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 <[email-masked]>
>>>>>> 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 thisspecification
>>>>>>>> MUST only use the parameters included in the requestobject. *
>>>>>>>
>>>>>>>
>>>>>>> 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 thisspecification
>>>>>>>> MUST only use the parameters included in the requestobject. *
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>> [email-masked]
>>>>>>> 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
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>> --
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 2 Jan 2020 10:48:29 -0500

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> So, no change is OK? 
> 
> On Wed, Dec 11, 2019 at 10:01 PM John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> 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 <[email-masked] <mailto:[email-masked]>> 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. 
> 
> https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actually-specifies-the <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=[email-masked] <mailto:[email-masked]>>:
> 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 <[email-masked] <mailto:[email-masked]>> 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.
> 
>     (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 <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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.
> 
> compatibility etc.  However, the authorization server supporting this
> specification MUST only use the parameters included in the request
> object. 
> 
> same parameter is provided in the query parameter.  The Authorization
> 
> 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.
> 
> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> -- 
> Nat Sakimura (=nat)
> http://nat.sakimura.org/ <http://nat.sakimura.org/>
> @_nat_en
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://nat.sakimura.org/ <http://nat.sakimura.org/>
> @_nat_en
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Takahiko Kawasaki <[email-masked]>
Date: Fri, 3 Jan 2020 02:24:33 +0900

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 <[email-masked]> 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:
>
>
> 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
>
>
>
>>>> [email-masked] <[email-masked]>
>>>> >:
>>>>
>>>>> 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.
>>>>>
>>>>>>>>> MUST only use the parameters included in the requestobject.. *
>>>>>>>>
>>>>>>>>
>>>>>>> privileged material for the sole use of the intended recipient(s)... Any

---

From: Justin Richer <[email-masked]>
Date: Thu, 2 Jan 2020 12:35:25 -0500

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 4 Jan 2020 12:02:43 +0200

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 <[email-masked]
>> <mailto:[email-masked]>> 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,
>>
>> ('client_id' and 'response_type') outside the request object, the
>> request is rejected.
>>
>> 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.
>>
>> '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.
>>
>> '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.
>>
>> 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.
>>
>>     shall require that all parameters are present inside the signed
>>     request object passed in the request or request_uri parameter;
>>
>>
>> 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
>>
>>
>>     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:
>>
>>
>>     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
>>
>>
>>
>>>     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 11, 2019 at 10:01 PM John Bradley
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             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
>>>             <[email-masked] <mailto:[email-masked]>> 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. 
>>>
>>>                 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=[email-masked]
>>>                 <mailto:[email-masked]>>:
>>>
>>>                     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
>>>                     <[email-masked] <mailto:[email-masked]>>
>>>                     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.
>>>
>>>                             (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
>>>                         <[email-masked]
>>>                         <mailto:[email-masked]>> 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 <[email-masked]
>>>                             <mailto:[email-masked]>> 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
>>>                                     The client MAY send the
>>>                                     parameters included in the
>>>                                     request object
>>>                                     duplicated in the query
>>>                                     compatibility etc.  *However,
>>>                                     the authorization server
>>>                                     supporting this
>>>                                     object. *
>>>                                     Server MUST only use the
>>>                                     parameters in the Request Object
>>>                                     even if the
>>>                                     The client MAY send the
>>>                                     parameters included in the
>>>                                     request object
>>>                                     duplicated in the query
>>>                                     compatibility etc.  *However,
>>>                                     the authorization server
>>>                                     supporting this
>>>                                     object.. *
>>>                                 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
>>>                                 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*
>>>                             /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
>>>                             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

---

From: n-sakimura <[email-masked]>
Date: Mon, 6 Jan 2020 06:04:51 +0000

Up until -12 (Feb 13, 2017), it was using merge + JAR precedence if duplicated.
As of -13 (Mar 30, 2017), it was changed that the server does not have to do the merge, at least for OAuth Authorization request parameters. It says nothing about other parameters.
As of -14 (Jul 21, 2017), the wording was further strengthened by adding

The Authorization Server MUST only use the parameters in the Request Object even if the same parameter is provided in the query parameter.

So, the entire 6.3 now became
6.3<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-6.3>.  Request Parameter Assembly and Validation

   The Authorization Server MUST extract the set of Authorization

   Request parameters from the Request Object value.  The Authorization

   Server then validates the request as specified in OAuth 2.0

   [RFC6749<https://tools.ietf.org/html/rfc6749>].

It says nothing on the non-OAuth parameters that came with the authorization request.
My take on the text is that all OAuth Authorization Request parameters MUST be in the request object.
Behaviors towards other parameters that happens to have come together with the authorization request outside of request object will be treated as non-OAuth parameters.

Nat Sakimura
Research Fellow, Nomura Research Institute
E: [email-masked]
T: +81(90)60136276
---------------------------------------------------------
PLEASE READ:This e-mail is confidential and intended for the named recipient only.
If you are not an intended recipient, please notify the sender and delete this e-mail.

From: OAuth <[email-masked]> On Behalf Of Justin Richer
Sent: Friday, January 3, 2020 2:35 AM
To: Takahiko Kawasaki <[email-masked]>
Cc: Brian Campbell <bcampbell=[email-masked]>; oauth <[email-masked]>; Nat Sakimura <[email-masked]>
Subject: Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

 — Justin

On Jan 2, 2020, at 12:24 PM, Takahiko Kawasaki <[email-masked]<mailto:[email-masked]>> wrote:

So,

- - -

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;

Any thoughts?

Best,
Taka

On Fri, Jan 3, 2020 at 12:48 AM Justin Richer <[email-masked]<mailto:[email-masked]>> 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:

 — Justin

On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki <[email-masked]<mailto:[email-masked]>> wrote:

Best Regards,
Taka

On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
So, no change is OK?

On Wed, Dec 11, 2019 at 10:01 PM John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
I also slightly prefer the merge approach.

John B.

On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura <[email-masked]<mailto:[email-masked]>> 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.

Best,

Nat Sakimura

2019年8月29日(木) 6:56 Brian Campbell <bcampbell=[email-masked]<mailto:[email-masked]>>:
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 <[email-masked]<mailto:[email-masked]>> 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.

S pozdravem,
Filip Skokan

On Wed, 28 Aug 2019 at 23:02, Brian Campbell <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hello everyone,

Best,
Filip
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Filip Skokan <[email-masked]>
Date: Mon, 6 Jan 2020 10:43:19 +0100

I don't think we have the separation of OAuth and non-OAuth parameters and
let's please not. Even OIDC parameters are part of the OAuth parameters
registry
<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters>
and
I cannot imagine the hardship if we were to explain that to developers.

With passing time I believe it should be up to the profile or application
of JAR to define how to treat *recognized* parameters outside of the
request object. In my personal OSS project the AS can be configured to be
*strict* (jar), *lax* (oidc merge all) or *whitelist* (merge only
whitelisted - code_challenge, nonce, state, ...) similar to what Vladimir
is describing.

S pozdravem,
*Filip Skokan*

On Mon, 6 Jan 2020 at 07:05, n-sakimura <[email-masked]> wrote:

> As of -13 (Mar 30, 2017), it was changed that the server does not have to
> do the merge, at least for OAuth Authorization request parameters. It says
> nothing about other parameters.
>
> The Authorization Server MUST only use the parameters in the Request
> Object even if the same parameter is provided in the query parameter.
>
>
>
> 6.3 <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-6.3>.
> Request Parameter Assembly and Validation
>
>    [RFC6749 <https://tools.ietf.org/html/rfc6749>].
>
>
>
> Behaviors towards other parameters that happens to have come together with
> the authorization request outside of request object will be treated as
> non-OAuth parameters.
>
>
>
> Nat Sakimura
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Justin Richer
> *Sent:* Friday, January 3, 2020 2:35 AM
> *To:* Takahiko Kawasaki <[email-masked]>
> *Cc:* Brian Campbell <bcampbell=[email-masked]>; oauth
> <[email-masked]>; Nat Sakimura <[email-masked]>
> *Subject:* Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC
> request object
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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
>
>
>
> 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.
>
> 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.
>
>
>
> 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 <[email-masked]> wrote:
>
>     (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)
>
> - 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
> On Wed, 28 Aug 2019 at 23:02, Brian Campbell <[email-masked]>
> 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 <[email-masked]> 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
> *However, the authorization server supporting this specification MUST only
> use the parameters included in the request object. *
>
>
>
> *However, the authorization server supporting this specification MUST only
> use the parameters included in the request object.. *
>
>
>
> 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"
> 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
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Takahiko Kawasaki <[email-masked]>
Date: Mon, 6 Jan 2020 20:00:15 +0900

Apparently, the description in the JAR spec has made some AS implementers,
at least Vladimir - Connect2id and Filip - node-oidc-provider, decide to
devise a workaround, and the approach (preparing a configuration switch) is
attracting Taka (me) - Authlete, too. This may be a typical answer by AS
implementers who face compatibility-breaking and interoperability-breaking
issues, although I personally prefer to modify the specification itself to
allow old/new RPs and ASes to coexist seamlessly. If the current draft is
not modified any more, I will probably prepare per-AS and per-RP
configuration switches. Anyway, this is feedback from AS implementers.

If preparing a configuration switch is a typical answer by AS implementers,
it might be good to define a new IdP metadata about JAR support (e.g.
strict, lax, whitelist, as Filip showed). Rather, the existence of such
metadata might be a must for the automated regular tests
<https://gitlab.com/openid/conformance-suite/-/wikis/Users/How-to-be-added-to-the-regular-automated-tests-run>
of conformance suite, but I'm not sure and want to consult Joseph Heenan
regarding this.

Best,
Taka

On Mon, Jan 6, 2020 at 6:43 PM Filip Skokan <[email-masked]> wrote:

> <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters> and
>> Behaviors towards other parameters that happens to have come together
>> with the authorization request outside of request object will be treated as
>> non-OAuth parameters.
>>
>>
>>
>> Nat Sakimura
>>
>> *Cc:* Brian Campbell <bcampbell=[email-masked]>;
>> oauth <[email-masked]>; Nat Sakimura <[email-masked]>
>> *Subject:* Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs
>> OIDC request object
>>
>>
>>
>> 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
>> 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.
>>
>> I think the nature of the backwards incompatibility is important here.
>> The way that things are now, using merge-with-precedence, you have the
>> 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
>>
>>
>>
>> *However, the authorization server supporting this specification MUST
>> only use the parameters included in the request object. *
>>
>>
>>
>> *However, the authorization server supporting this specification MUST
>> only use the parameters included in the request object.. *
>>
>>
>>

---

From: John Bradley <[email-masked]>
Date: Mon, 6 Jan 2020 19:50:21 -0300

My take would be that any paramater in the OAuth registy is a OAuth
paramater.

A client could duplicate those outside the request object for some sort
of backwards compatability but they will be ignored.

What we have lost is the merge capability.  There are some use cases
that could use that to have a presigned object that some paramaters like
state are outside.  

That was not popular with the IESG. 

John B.

On 1/6/2020 3:04 AM, n-sakimura wrote:
> As of -13 (Mar 30, 2017), it was changed that the server does not have
> to do the merge, at least for OAuth Authorization request parameters.
> It says nothing about other parameters.
>
>       6.3<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-6.3>. 
> with the authorization request outside of request object will be
> treated as non-OAuth parameters.
>
>  
>
> Nat Sakimura
>
> *From:*OAuth <[email-masked]> *On Behalf Of *Justin Richer
>     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,
>
>     '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.
>
>     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.
>
>     and New Clients should put mandatory request parameters outside
>     the request object and put all request parameters duplicately
>     inside the request object.
>
>     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.
>
>         shall require that all parameters are present inside the
>         signed request object passed in the request or request_uri
>         parameter;
>
>
>     adding a rule like "if request parameters exist outside the
>     request object, they must exist inside the request object, too."?
>
>     Any thoughts?
>
>      
>
>     Best,
>
>     Taka
>
>      
>
>      
>
>         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:
>
>          
>
>          
>
>         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
>             <[email-masked] <mailto:[email-masked]>> 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
>                     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. 
>
>                      
>
>                         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. 
>
>                          
>
>                         I am willing to go either way as long as
>                         people agree. My slight preference is to the
>                         original approach. 
>
>                          
>
>                         Best, 
>
>                          
>
>                         Nat Sakimura
>
>                          
>
>                             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
>                                 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.
>
>                                  
>
>                                 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 <[email-masked]
>                                     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,
>                                     On Tue, Aug 27, 2019 at 5:47 AM
>                                     Filip Skokan <[email-masked]
>                                         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
>                                             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
>                                             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.
>
>                                          
>
>                                         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*
>
>                                         <mailto:[email-masked]>
>                                     */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
>                             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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 7 Jan 2020 10:19:19 +0100

> Am 06.01.2020 um 23:50 schrieb John Bradley <[email-masked]>:
> 
> A client could duplicate those outside the request object for some sort of backwards compatability but they will be ignored.
> 
Is this used for backward compatibility with the OIDC servers?
> What we have lost is the merge capability.  There are some use cases that could use that to have a presigned object that some paramaters like state are outside.  
> 

Is this option used in the wild? As far as I understand the main use case is a 3rd party signing the request object that way entitling the client for something. I‘m asking since in my experience any kind of entitlement by a 3rd party is handled behind the scene using registries.

---

From: Justin Richer <[email-masked]>
Date: Fri, 10 Jan 2020 09:46:08 -0500

I believe the IESG was incorrect in their review and what’s in the text now is not what the WG agreed to.

Question is, what’s our next step, then?

 — Justin

> On Jan 6, 2020, at 5:50 PM, John Bradley <[email-masked]> wrote:
> 
> My take would be that any paramater in the OAuth registy is a OAuth paramater. 
> 
>>  <>6.3 <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-6.3>.  Request Parameter Assembly and Validation
>> 
>> E: [email-masked] <mailto:[email-masked]>
>> T: +81(90)60136276
>> PLEASE READ:This <read:This> e-mail is confidential and intended for the named recipient only.
>> From: OAuth <[email-masked]> <mailto:[email-masked]> On Behalf Of Justin Richer
>> To: Takahiko Kawasaki <[email-masked]> <mailto:[email-masked]>
>> Cc: Brian Campbell <bcampbell=[email-masked]> <mailto:bcampbell=[email-masked]>; oauth <[email-masked]> <mailto:[email-masked]>; Nat Sakimura <[email-masked]> <mailto:[email-masked]>
>> On Jan 2, 2020, at 12:24 PM, Takahiko Kawasaki <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: John Bradley <[email-masked]>
Date: Fri, 10 Jan 2020 11:49:08 -0300

I haven't seen any real use of merge.   It happens with Connect as a side
effect of OAuths current requirement to have some of the parameters outside
the JAR.

Nothing stops servers from ignoring parameters outside JAR or acting on
query parameters outside the JAR if they are not in the OAuth registry.   A
server can merge but that would not be JAR compliant if they care.

If the AS returned an error for parameters values that differ between the
JAR and the query that is not required but I don't think that is
prohibited.  I need to look at that.

JAR dosen't say your server can't do something else, but that is not JAR.

Clients should be updated to have all the parameters in the JAR.  That
should be the case for most of not all clients now.

For older servers they need to continue to include the required OAuth
parameters outside.

Servers need to migrate and eventually move to returning a warning or error
when a registry parameter is outside the JAR if JAR is used.

Especially if PAR is used (I suspect that will become the prefers pattern)
then merging won't really make sense.

John B.

On Tue, Jan 7, 2020, 6:19 AM Torsten Lodderstedt <[email-masked]>
wrote:

> A client could duplicate those outside the request object for some sort of
> backwards compatability but they will be ignored.
>
> What we have lost is the merge capability.  There are some use cases that
> could use that to have a presigned object that some paramaters like state
> are outside.
>
>
> Is this option used in the wild? As far as I understand the main use case
> is a 3rd party signing the request object that way entitling the client for
> something. I‘m asking since in my experience any kind of entitlement by a
> 3rd party is handled behind the scene using registries.
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 10 Jan 2020 10:01:10 -0500

But merge gives us the ability, which has been stated here before, to have a fixed core set of parameters inside the JAR and a mixed set of variable parameters outside the JAR. 

What if by “merge” we really mean “you can’t repeat things in both places but you can have fields in either”.

— Justin

> On Jan 10, 2020, at 9:49 AM, John Bradley <[email-masked]> wrote:
> 
> I haven't seen any real use of merge.   It happens with Connect as a side effect of OAuths current requirement to have some of the parameters outside the JAR. 
> 
> Nothing stops servers from ignoring parameters outside JAR or acting on query parameters outside the JAR if they are not in the OAuth registry.   A server can merge but that would not be JAR compliant if they care. 
> 
> If the AS returned an error for parameters values that differ between the JAR and the query that is not required but I don't think that is prohibited.  I need to look at that. 
> 
> Clients should be updated to have all the parameters in the JAR.  That should be the case for most of not all clients now.   
> 
> For older servers they need to continue to include the required OAuth parameters outside. 
> 
> Servers need to migrate and eventually move to returning a warning or error when a registry parameter is outside the JAR if JAR is used. 
> 
> Especially if PAR is used (I suspect that will become the prefers pattern) then merging won't really make sense. 
> 
> John B. 
> 
> On Tue, Jan 7, 2020, 6:19 AM Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> Am 06.01.2020 um 23:50 schrieb John Bradley <[email-masked] <mailto:[email-masked]>>:
>>

---

From: John Bradley <[email-masked]>
Date: Fri, 10 Jan 2020 12:53:31 -0300

Yes that is what it comes down to.

Is that a feature having a fixed set of parameters in the signed JAR and
some number of OAuth parameters unsigned outside the JAR, that people want
badly enough for us to pull the spec back and restart IESG review.

I think Torsten is speculating that is not a feature people use.

It was a feature that people on the IESG objected to.

If we can get concensus in the WG to pull it back, we can do it.

That is the decision we should make.

John B.

On Fri, Jan 10, 2020, 12:01 PM Justin Richer <[email-masked]> wrote:

> But merge gives us the ability, which has been stated here before, to have
> a fixed core set of parameters inside the JAR and a mixed set of variable
> parameters outside the JAR.
>
> Servers need to migrate and eventually move to returning a warning or
> error when a registry parameter is outside the JAR if JAR is used.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 10 Jan 2020 19:13:48 +0100

> Am 10.01.2020 um 16:53 schrieb John Bradley <[email-masked]>:
> 

I’m still trying to understand the use case for merging signed and unsigned parameters. Nat once explained a use case, where a client uses parameters signed by a 3rd party (some „certification authority“) in combination with transaction-specific parameters. Is this being done in the wild? 

PS: PAR would work with both modes.

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 10 Jan 2020 22:18:48 +0200

I just realised there is one class of JARs where it's practially
impossible to process the request if merge isn't supported:

The client submits a JAR encrypted (JWT) with a shared key. OIDC allows
for that and specs a method for deriving the shared key from the
client_secret:

https://openid.net/specs/openid-connect-core-1_0.html#Encryption

If the JAR is encrypted with the client_secret, and there is no
top-level client_id parameter, there's no good way for the OP to find
out which client_secret to get to try to decrypt the JWE. Unless the OP
keeps an index of all issued client_secret's.

OP servers which require request_uri registration
(require_request_uri_registration=true) and don't want to index all
registered request_uri's, also have no good way to process a request_uri
if the client_id isn't present as top-level parameter.

Vladimir

---

From: Filip Skokan <[email-masked]>
Date: Fri, 10 Jan 2020 21:39:44 +0100

Vladimir, 

For that very case the payload claims may be repeated in the JWE protected header. An implementation wanting to handle this may look for iss/client_id there. 

Odesláno z iPhonu

> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov <[email-masked]>:
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 10 Jan 2020 23:29:10 +0200

Yes, putting the client_id into the JWE header is a way around the need
to have the client_id outside the JWE as top-level authZ request parameter.

Unfortunately this work around isn't mentioned anywhere, I just checked
the most recent draft-ietf-oauth-jwsreq-20.

Our DDoS attack mitigation (for OIDC request_uri) also relies on the
presence of client_id as top-level parameter, together with requiring
RPs to register their request_uri's (so that we don't need to build and
store an index of all request_uri's). I just had a look at "DDoS Attack
on the Authorization Server" and also realised the request_uri
registration isn't explicitly mentioned as attack prevention ("the
server should (a) check that the value of "request_uri" parameter does
not point to an unexpected location").

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1

To be honest, I feel quite bad about the situation with JAR we are in
now. For some reason I had the impression that OAuth JAR was going to be
the OIDC request / request_uri for general OAuth 2.0 use, as with other
OIDC bits that later became general purpose OAuth 2.0 specs.

I find it unfortunate I didn't notice this when I was reviewing the spec
in the past.

Vladimir

---

From: John Bradley <[email-masked]>
Date: Fri, 10 Jan 2020 19:14:36 -0300

The intent was to do that, but specs change once the OAuth WG and IESG get
there hands on them.

Being backwards compatible with OIDC is not a compelling argument to the
IESG.

We were mostly thinking of asymmetric encryption.

Specifying puting the issuer and or the audience in the headder has come up
in the past but probably is not documented.

John B

On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov <[email-masked]>
wrote:

> > For that very case the payload claims may be repeated in the JWE
> protected header. An implementation wanting to handle this may look for
> iss/client_id there.
> >
> > Odesláno z iPhonu
> >
> >>> I’m still trying to understand the use case for merging signed and
> unsigned parameters. Nat once explained a use case, where a client uses
> parameters signed by a 3rd party (some „certification authority“) in
> combination with transaction-specific parameters. Is this being done in the
> wild?
> >>>

---

From: Mike Jones <[email-masked]>
Date: Sat, 11 Jan 2020 00:41:33 +0000

The technique of replicating JWT claims that need to be publicly visible in an encrypted JWT in the header is defined at https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick Hardt for bringing this need to my attention as we were finishing the JWT spec.)

                                                       -- Mike

From: OAuth <[email-masked]> On Behalf Of John Bradley
Sent: Friday, January 10, 2020 2:15 PM
To: Vladimir Dzhuvinov <[email-masked]>
Cc: IETF oauth WG <[email-masked]>
Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

The intent was to do that, but specs change once the OAuth WG and IESG get there hands on them.

Being backwards compatible with OIDC is not a compelling argument to the IESG.

Specifying puting the issuer and or the audience in the headder has come up in the past but probably is not documented.

John B

On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov <[email-masked]<mailto:[email-masked]>> wrote:
Yes, putting the client_id into the JWE header is a way around the need
to have the client_id outside the JWE as top-level authZ request parameter.

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-jwsreq-20%23section-10.4.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=%2FvHVp68SN5CAHimqZ5jx93aOCIruxqLCRMUFCc5DSxc%3D&reserved=0>

Vladimir

On 10/01/2020 22:39, Filip Skokan wrote:
>> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov <[email-masked]<mailto:[email-masked]>>:
>>
>> https://openid.net/specs/openid-connect-core-1_0.html#Encryption<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23Encryption&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=soK9t7pzu504iILuDNFnG%2BMLxZPP2pN6ugEJ4ZOpqd4%3D&reserved=0>
>>
>>>>> Am 10.01.2020 um 16:53 schrieb John Bradley <[email-masked]<mailto:[email-masked]>>:

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068803145&sdata=kobH%2FsGT7ElSSUCJvu%2FbiAqnRCXx%2B4SZNJsrL%2FCuVyc%3D&reserved=0>

---

From: John Bradley <[email-masked]>
Date: Fri, 10 Jan 2020 21:58:14 -0300

Right we just don't say to put the iss there in OIDC if it's symetricly
encrypted.

On Fri, Jan 10, 2020, 9:41 PM Mike Jones <[email-masked]>
wrote:

> The technique of replicating JWT claims that need to be publicly visible
> in an encrypted JWT in the header is defined at
> https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick Hardt
> for bringing this need to my attention as we were finishing the JWT spec.)
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of * John Bradley
> *Sent:* Friday, January 10, 2020 2:15 PM
> *To:* Vladimir Dzhuvinov <[email-masked]>
> *Cc:* IETF oauth WG <[email-masked]>
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request
> (JAR) vs OIDC request object
>
>
>
> Specifying puting the issuer and or the audience in the headder has come
> up in the past but probably is not documented.
>
>
>
> John B
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-jwsreq-20%23section-10.4.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=%2FvHVp68SN5CAHimqZ5jx93aOCIruxqLCRMUFCc5DSxc%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23Encryption&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=soK9t7pzu504iILuDNFnG%2BMLxZPP2pN6ugEJ4ZOpqd4%3D&reserved=0>
> >>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068803145&sdata=kobH%2FsGT7ElSSUCJvu%2FbiAqnRCXx%2B4SZNJsrL%2FCuVyc%3D&reserved=0>
>
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 11 Jan 2020 11:16:56 +0200

Thanks Mike for the rfc7519 section-5.3
<https://tools.ietf.org/html/rfc7519#section-5.3> pointer. Can this
parameter replication be used for client_id or the client_id ass "iss"
even though it isn't explicitly mentioned in the JAR spec?

On 11/01/2020 02:58, John Bradley wrote:
> Right we just don't say to put the iss there in OIDC if it's
> symetricly encrypted.

OIDC doesn't have the symmetric key selection issue, I suppose that why
the possibility to replicate params to the JWE header isn't mentioned at
all. OIDC requires the top-level query params to represent a valid OAuth
2.0 request, and there client_id is required. If the client_id is
present the client registration together with any present client_secret
can be retrieved.

I reread the JAR spec, this is the only place that mentions handling of
symmetric JWE.

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2

>    (b)  Verifying that the symmetric key for the JWE encryption is the
>         correct one if the JWE is using symmetric encryption.

Vladimir

>
> On Fri, Jan 10, 2020, 9:41 PM Mike Jones <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     The technique of replicating JWT claims that need to be publicly
>     visible in an encrypted JWT in the header is defined at
>     https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick
>     Hardt for bringing this need to my attention as we were finishing
>     the JWT spec.)
>
>      
>
>                                                            -- Mike
>
>      
>
>     *From:* OAuth <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of * John Bradley
>     *To:* Vladimir Dzhuvinov <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* IETF oauth WG <[email-masked] <mailto:[email-masked]>>
>     *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization
>     Request (JAR) vs OIDC request object
>
>      
>
>     Specifying puting the issuer and or the audience in the headder
>     has come up in the past but probably is not documented.  
>
>      
>
>     John B 
>
>      
>
>     On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         > For that very case the payload claims may be repeated in the
>         JWE protected header. An implementation wanting to handle this
>         may look for iss/client_id there.
>         >
>         > Odesláno z iPhonu
>         >
>         >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov
>         <[email-masked] <mailto:[email-masked]>>:
>         >>
>         >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley
>         <[email-masked] <mailto:[email-masked]>>:
>         >>> I’m still trying to understand the use case for merging
>         signed and unsigned parameters. Nat once explained a use case,
>         where a client uses parameters signed by a 3rd party (some
>         „certification authority“) in combination with
>         transaction-specific parameters. Is this being done in the wild?
>         >>>
-- 
Vladimir Dzhuvinov

---

From: John Bradley <[email-masked]>
Date: Sat, 11 Jan 2020 16:36:25 -0300

Yes JAR is not prohibiting paramater replication in the header. 

I will see if i can add something in final edits to call that out.

John B.

On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
> OIDC doesn't have the symmetric key selection issue, I suppose that
> why the possibility to replicate params to the JWE header isn't
> mentioned at all. OIDC requires the top-level query params to
> represent a valid OAuth 2.0 request, and there client_id is required.
> If the client_id is present the client registration together with any
> present client_secret can be retrieved.
>
> I reread the JAR spec, this is the only place that mentions handling
> of symmetric JWE.
>
>>         > For that very case the payload claims may be repeated in
>>         the JWE protected header. An implementation wanting to handle
>>         this may look for iss/client_id there.
>>         >
>>         > Odesláno z iPhonu
>>         >
>>         signed and unsigned parameters. Nat once explained a use
>>         case, where a client uses parameters signed by a 3rd party
>>         (some „certification authority“) in combination with

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 13 Jan 2020 17:57:10 +0200

John, thanks, much appreciated!

On 11/01/2020 21:36, John Bradley wrote:
>> parameter replication be used for client_id or the client_id ass
>> "iss" even though it isn't explicitly mentioned in the JAR spec?
>>
>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones
>>> <[email-masked] <mailto:[email-masked]>>
>>> wrote:
>>>
>>>     https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to
>>>     Dick Hardt for bringing this need to my attention as we were
>>>     finishing the JWT spec.)
>>>
>>>      
>>>
>>>                                                            -- Mike
>>>
>>>      
>>>
>>>         the JWE protected header. An implementation wanting to
>>>         handle this may look for iss/client_id there.
>>>         >
>>>         > Odesláno z iPhonu
>>>         >
>>>         https://

---

From: Takahiko Kawasaki <[email-masked]>
Date: Wed, 15 Jan 2020 02:20:39 +0900

Well, embedding a client_id claim in the JWE header in order to achieve
"request parameters outside the request object should not be referred to"
is like "putting the cart before the horse". Why do we have to avoid using
the traditional client_id request parameter so stubbornly?

The last paragraph of Section 3.2.1
<https://tools.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749 says as
follows.

*A client MAY use the "client_id" request parameter to identify itself when
sending requests to the token endpoint.  In the "authorization_code"
"grant_type" request to the token endpoint, an unauthenticated client MUST
send its "client_id" to prevent itself from inadvertently accepting a code
intended for a client with a different "client_id".  This protects the
client from substitution of the authentication code.  (It provides no
additional security for the protected resource.)*

If the same reasoning applies, a client_id must always be sent with request
/ request_uri because client authentication is not performed at the
authorization endpoint. In other words, *an unauthenticated client (every
client is unauthenticated at the authorization endpoint) MUST send its
"client_id" to prevent itself from inadvertently accepting a request object
for a client with a different "client_id".*

Best Regards,
Taka

On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov <[email-masked]>
wrote:

> parameter replication be used for client_id or the client_id ass "iss" even
> though it isn't explicitly mentioned in the JAR spec?
> 2.0 request, and there client_id is required. If the client_id is present
> the client registration together with any present client_secret can be
> retrieved.
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 15 Jan 2020 23:02:33 +0200

On 14/01/2020 19:20, Takahiko Kawasaki wrote:
> Well, embedding a client_id claim in the JWE header in order to
> achieve "request parameters outside the request object should not be
> referred to" is like "putting the cart before the horse". Why do we
> have to avoid using the traditional client_id request parameter so
> stubbornly?
>
> <https://tools.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749 says
> as follows.
>
>     /A client MAY use the "client_id" request parameter to identify
>     itself when sending requests to the token endpoint.  In the
>     "authorization_code" "grant_type" request to the token endpoint,
>     *an unauthenticated client MUST send its "client_id" to prevent
>     itself from inadvertently accepting a code intended for a client
>     with a different "client_id".*  This protects the client from
>     substitution of the authentication code.  (It provides no
>     additional security for the protected resource.)/
>
>
> If the same reasoning applies, a client_id must always be sent with
> request / request_uri because client authentication is not performed
> at the authorization endpoint. In other words, */an unauthenticated
> client (every client is unauthenticated at the authorization endpoint)
> MUST send its "client_id" to prevent itself from inadvertently
> accepting a request object for a client with a different "client_id"./*
>
Identifying the client in JAR request_uri requests can be really useful
so that an AS which requires request_uri registration to prevent DDoS
attacks and other checks can do those without having to index all
request_uris individually. I mentioned this before.

I really wonder what the reasoning of the IESG reviewers was to insist
on no params outside the JAR JWT / request_uri.

I'm beginning to realise this step of the review process isn't
particularly transparent to WG members.

Vladimir

> Best Regards,
> Taka
>
>
>
> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov
>>>     <https://tools.ietf.org/html/rfc7519#section-5.3> pointer. Can
>>>     this parameter replication be used for client_id or the
>>>     client_id ass "iss" even though it isn't explicitly mentioned in
>>>     the JAR spec?
>>>
>>>     OIDC doesn't have the symmetric key selection issue, I suppose
>>>     that why the possibility to replicate params to the JWE header
>>>     isn't mentioned at all. OIDC requires the top-level query params
>>>     to represent a valid OAuth 2.0 request, and there client_id is
>>>     required. If the client_id is present the client registration
>>>     together with any present client_secret can be retrieved.
>>>
>>>     I reread the JAR spec, this is the only place that mentions
>>>     handling of symmetric JWE.
>>>
>>>>     <[email-masked]
>>>>         The technique of replicating JWT claims that need to be
>>>>         publicly visible in an encrypted JWT in the header is
>>>>         defined at
>>>>         https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks
>>>>         to Dick Hardt for bringing this need to my attention as we
>>>>         were finishing the JWT spec.)
>>>>
>>>>          
>>>>
>>>>                                                                -- Mike
>>>>
>>>>          
>>>>
>>>>         *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured
>>>>         Authorization Request (JAR) vs OIDC request object
>>>>
>>>>          
>>>>
>>>>         Specifying puting the issuer and or the audience in the
>>>>         headder has come up in the past but probably is not
>>>>         documented.  
>>>>
>>>>          
>>>>
>>>>         John B 
>>>>
>>>>          
>>>>
>>>>             > For that very case the payload claims may be repeated
>>>>             in the JWE protected header. An implementation wanting
>>>>             to handle this may look for iss/client_id there.
>>>>             >
>>>>             > Odesláno z iPhonu
>>>>             >
>>>>             >>> I’m still trying to understand the use case for
>>>>             merging signed and unsigned parameters. Nat once
>>>>             explained a use case, where a client uses parameters
>>>>             signed by a 3rd party (some „certification authority“)
>>>>             in combination with transaction-specific parameters. Is
>>>>             this being done in the wild?
>>>>             >>>
-- 
Vladimir Dzhuvinov

---

From: Mike Jones <[email-masked]>
Date: Wed, 15 Jan 2020 21:27:38 +0000

I’m increasingly thinking that we should push back on the IESG and go back to the semantics that the working group approved.  We can use the client_id example with an encrypted request object to motivate the (Connect-compatible) syntax and semantics.

                                                       -- Mike

From: Vladimir Dzhuvinov <[email-masked]>
Sent: Wednesday, January 15, 2020 1:03 PM
To: Takahiko Kawasaki <[email-masked]>
Cc: John Bradley <[email-masked]>; Mike Jones <[email-masked]>; IETF oauth WG <[email-masked]>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

On 14/01/2020 19:20, Takahiko Kawasaki wrote:
Well, embedding a client_id claim in the JWE header in order to achieve "request parameters outside the request object should not be referred to" is like "putting the cart before the horse". Why do we have to avoid using the traditional client_id request parameter so stubbornly?

The last paragraph of Section 3.2.1<https://tools.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749 says as follows.
A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint.  In the "authorization_code" "grant_type" request to the token endpoint, an unauthenticated client MUST send its "client_id" to prevent itself from inadvertently accepting a code intended for a client with a different "client_id".  This protects the client from substitution of the authentication code.  (It provides no additional security for the protected resource.)

If the same reasoning applies, a client_id must always be sent with request / request_uri because client authentication is not performed at the authorization endpoint. In other words, an unauthenticated client (every client is unauthenticated at the authorization endpoint) MUST send its "client_id" to prevent itself from inadvertently accepting a request object for a client with a different "client_id".

Identifying the client in JAR request_uri requests can be really useful so that an AS which requires request_uri registration to prevent DDoS attacks and other checks can do those without having to index all request_uris individually. I mentioned this before.

I really wonder what the reasoning of the IESG reviewers was to insist on no params outside the JAR JWT / request_uri.

I'm beginning to realise this step of the review process isn't particularly transparent to WG members.

Vladimir

Best Regards,
Taka

On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov <[email-masked]<mailto:[email-masked]>> wrote:

John B.

Thanks Mike for the rfc7519 section-5.3<https://tools.ietf.org/html/rfc7519#section-5.3> pointer. Can this parameter replication be used for client_id or the client_id ass "iss" even though it isn't explicitly mentioned in the JAR spec?
On 11/01/2020 02:58, John Bradley wrote:
Right we just don't say to put the iss there in OIDC if it's symetricly encrypted.

OIDC doesn't have the symmetric key selection issue, I suppose that why the possibility to replicate params to the JWE header isn't mentioned at all. OIDC requires the top-level query params to represent a valid OAuth 2.0 request, and there client_id is required. If the client_id is present the client registration together with any present client_secret can be retrieved.

I reread the JAR spec, this is the only place that mentions handling of symmetric JWE.

Vladimir

On Fri, Jan 10, 2020, 9:41 PM Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
The technique of replicating JWT claims that need to be publicly visible in an encrypted JWT in the header is defined at https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick Hardt for bringing this need to my attention as we were finishing the JWT spec.)

                                                       -- Mike

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of John Bradley
Sent: Friday, January 10, 2020 2:15 PM
To: Vladimir Dzhuvinov <[email-masked]<mailto:[email-masked]>>
Cc: IETF oauth WG <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

John B

Vladimir

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068803145&sdata=kobH%2FsGT7ElSSUCJvu%2FbiAqnRCXx%2B4SZNJsrL%2FCuVyc%3D&reserved=0>

--

Vladimir Dzhuvinov

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 15 Jan 2020 20:12:52 -0800

I'm only the irresponsible AD here, but I expect that you would be welcome
(nay, encouraged!) to write up a clear explanation of why the current
(post-IESG) formulation is bad, what a better formulation should be, and
why.  This would presumably also include some justification for how the
better formulation remains secure (which can be somewhat challenging when
combining data sources that have differing levels of provenance).  The
strongest voice that drove the change at IESG evaluation (Ben C) is no longer
on the IESG, though IIRC the arguments resonated pretty well with me.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 15 Jan 2020 20:20:34 -0800

> on the IESG, though IIRC the arguments resonated pretty well with me.

[looks like I'm misremembering the bit about Ben C, at least as far as
shows up at
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/history/]

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 15 Jan 2020 20:53:02 -0800

> particularly transparent to WG members.

Could you expand on that a bit more?  My understanding is that the IESG
ballot mail gets copied to the WG precisely so that there is transparency,
e.g., the thread starting at
https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI
Which admittely is from almost three years ago, but that's the earliest
that I found that could be seen as the source of this behavior.

-Ben

P.S. some other discussion at
https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 and
https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY and
so on.

---

From: Neil Madden <[email-masked]>
Date: Thu, 16 Jan 2020 07:07:28 +0000

If the AS can’t validate the request_uri it may also open itself up to SSRF attacks where a malicious client uses the request_uri to probe/attack resources inside the AS’s private network. This was a crucial part of the recent Capital One breach for example [1].  ForgeRock currently requires strict validation of request_uris against a client-specific whitelist for exactly this reason. 

NB some clients might legitimately be on that private network (eg microservices) so changing to a global whitelist for all clients is undesirable. 

[1]: https://ejj.io/blog/capital-one

— Neil

> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov <[email-masked]> wrote:
>> The last paragraph of Section 3.2.1 of RFC 6749 says as follows.
>> 
>> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov <[email-masked]> wrote:
>>>>> Thanks Mike for the rfc7519 section-5.3 pointer. Can this parameter replication be used for client_id or the client_id ass "iss" even though it isn't explicitly mentioned in the JAR spec?
>>>>> 
>>>>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones <[email-masked]> wrote:
>>>>>>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov <[email-masked]> wrote:
>>>>>>>

---

From: Dominick Baier <[email-masked]>
Date: Thu, 16 Jan 2020 09:15:29 +0100

Agreed - that’s why we disabled request_uri by default and added
extensibility points to implement validation.

I thought it is odd that this was not mentioned in the typical “security
considerations” in the OIDC spec..

———
Dominick Baier

On 16. January 2020 at 08:07:44, Neil Madden ([email-masked])
wrote:

If the AS can’t validate the request_uri it may also open itself up to SSRF
attacks where a malicious client uses the request_uri to probe/attack
resources inside the AS’s private network. This was a crucial part of the
recent Capital One breach for example [1].  ForgeRock currently requires
strict validation of request_uris against a client-specific whitelist for
exactly this reason.

NB some clients might legitimately be on that private network (eg
microservices) so changing to a global whitelist for all clients is
undesirable.

— Neil

On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov <[email-masked]>
wrote:

Identifying the client in JAR request_uri requests can be really useful so
that an AS which requires request_uri registration to prevent DDoS attacks
and other checks can do those without having to index all request_uris
individually. I mentioned this before.

I really wonder what the reasoning of the IESG reviewers was to insist on
no params outside the JAR JWT / request_uri.

I'm beginning to realise this step of the review process isn't particularly
transparent to WG members.

Vladimir

Best Regards,
Taka

On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov <[email-masked]>
wrote:

> <[email-masked]>> wrote:
>
>> *From:* OAuth <[email-masked]> *On Behalf Of* John Bradley
--
Vladimir Dzhuvinov

---

From: Neil Madden <[email-masked]>
Date: Thu, 16 Jan 2020 08:34:06 +0000

Is it too late to add it to the security considerations for JAR? 

— Neil

> On 16 Jan 2020, at 08:15, Dominick Baier <[email-masked]> wrote:
> 
> 
> Agreed - that’s why we disabled request_uri by default and added extensibility points to implement validation.
> 
> I thought it is odd that this was not mentioned in the typical “security considerations” in the OIDC spec..
> 
> ———
> Dominick Baier
> 
>> On 16. January 2020 at 08:07:44, Neil Madden ([email-masked]) wrote:
>>

---

From: John Bradley <[email-masked]>
Date: Thu, 16 Jan 2020 10:40:39 -0300

I agree with the IESG reasoning that merging is problimatic.  Once we
allow that given a unknown list of possible paramaters with diffrent
security properties it would be quite difficult to specify safely.

Query paramaters can still be sent outside the JAR, but if they are in
the OAuth registry the AS MUST ignore them.

Puting the iss in the JWE headder addresses the encryption issue without
merging.

I understand that some existing servers have dependencys on getting the
clientID as a query paramater.

Is that the only paramater that people have a issue with as oposed to a
nice to have?

Would allowing the AS to not ignore the clientID as a query paramater as
long as it matches the one inside the JAR, basicly the same as Connect
request object but for just the one paramater make life easier for the
servers?

I am not promising a change but gathering info before proposing something.

John B.

---

From: Neil Madden <[email-masked]>
Date: Thu, 16 Jan 2020 14:01:18 +0000

I believe just client_id would be sufficient for us, so I'd support a compromise position in which that is the only additional query parameter allowed.

-- Neil

> On 16 Jan 2020, at 13:40, John Bradley <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 16 Jan 2020 06:32:33 -0800

It is not too late to add to the security considerations.

It seems that the new application/oauth.authz.req+jwt media-type is helpful
in this regard, in that if an AS can require that content-type from
dereferencing the request_uri, then seeing anything else indicates that the
request was bogus (or an attack).  I guess existing OIDC deployments aren't
exactly in a position to do that, though.

-Ben

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 17 Jan 2020 00:47:45 +0900

Right. We could add a security consideration like that, though the
mitigation probably is pretty much the same as what is stated in 10.4.1:

the server should (a) check that
   the value of "request_uri" parameter does not point to an unexpected
   location, (b) check the content type of the response is "application/
   oauth.authz.req+jwt" (c) implement a time-out for obtaining the
   content of "request_uri", and (d) not perform recursive GET on the
   "request_uri".

If not, please let me know so that we can add that as the mitigation as
well.

Existing OIDC deployment cannot make use of application/oauth.authz.req+jwt
but it has to validate that content is a valid request object anyways and
if it is malformed, it MUST stop the processing and return an error
invalid_request_uri. So, unlike in the case of Capital One's SSRF, the
content of the request_uri will not be exposed. The main downside is
therefore as depicted in the current draft, consumption of the network and
processing power of the AS, and the unwanted access load to the servers
serving the URL pointed by request_uri. The above-quoted mitigations were
introduced to address these issues.

On Thu, Jan 16, 2020 at 11:33 PM Benjamin Kaduk <[email-masked]> wrote:

> > > I thought it is odd that this was not mentioned in the typical
> “security considerations” in the OIDC spec..
> > >
> > > ———
> > > Dominick Baier
> > >
> > >> If the AS can’t validate the request_uri it may also open itself up
> to SSRF attacks where a malicious client uses the request_uri to
> probe/attack resources inside the AS’s private network. This was a crucial
> part of the recent Capital One breach for example [1].  ForgeRock currently
> requires strict validation of request_uris against a client-specific
> whitelist for exactly this reason.
> > >>
> referred to" is like "putting the cart before the horse". Why do we have to
> avoid using the traditional client_id request parameter so stubbornly?
> > >>>>
> > >>>> A client MAY use the "client_id" request parameter to identify
> "authorization_code" "grant_type" request to the token endpoint, an
> unauthenticated client MUST send its "client_id" to prevent itself from
> inadvertently accepting a code intended for a client with a different
> "client_id".  This protects the client from substitution of the
> authentication code.  (It provides no additional security for the protected
> resource.)
> > >>>>
> request / request_uri because client authentication is not performed at the
> authorization endpoint. In other words, an unauthenticated client (every
> for a client with a different "client_id".
> > >>>>
> > >>> Identifying the client in JAR request_uri requests can be really
> useful so that an AS which requires request_uri registration to prevent
> DDoS attacks and other checks can do those without having to index all
> > >>> I really wonder what the reasoning of the IESG reviewers was to
> insist on no params outside the JAR JWT / request_uri.
> > >>>
> > >>>>>>> Thanks Mike for the rfc7519 section-5.3 pointer. Can this
> that why the possibility to replicate params to the JWE header isn't
> mentioned at all. OIDC requires the top-level query params to represent a
> valid OAuth 2.0 request, and there client_id is required. If the client_id
> is present the client registration together with any present client_secret
> can be retrieved.
> > >>>>>>>
> publicly visible in an encrypted JWT in the header is defined at
> headder has come up in the past but probably is not documented.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> John B
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> JWE protected header. An implementation wanting to handle this may look for
> iss/client_id there.
> > >>>>>>>>> >
> > >>>>>>>>> > Odesláno z iPhonu
> > >>>>>>>>> >
> signed and unsigned parameters. Nat once explained a use case, where a
> client uses parameters signed by a 3rd party (some „certification
> authority“) in combination with transaction-specific parameters. Is this
> being done in the wild?
> > >>>>>>>>> >>>

---

From: Neil Madden <[email-masked]>
Date: Thu, 16 Jan 2020 16:31:30 +0000

The mitigations of 10.4.1 are related, but the section heading is about (D)DoS attacks. I think this heading needs to be reworded to apply to SSRF attacks too or else add another section with similar mitigations. 

Mitigation (a) is a bit vague as to what an "unexpected location" is. Perhaps specific wording that it should be a URI that has been pre-registered for the client (and validated at that time) or is otherwise known to be safe (e.g., is a URI scheme controlled by the AS itself as with PAR).

In addition for this to be effective the AS should not follow redirects when fetching the URI. It's not clear to me whether that is implied by "not perform recursive GET" so it may be worth explicitly spelling that out.

-- Neil

> On 16 Jan 2020, at 15:47, Nat Sakimura <[email-masked]> wrote:
> 
> Right. We could add a security consideration like that, though the mitigation probably is pretty much the same as what is stated in 10.4.1: 
> If not, please let me know so that we can add that as the mitigation as well. 
> 
> Existing OIDC deployment cannot make use of application/oauth.authz.req+jwt but it has to validate that content is a valid request object anyways and if it is malformed, it MUST stop the processing and return an error invalid_request_uri. So, unlike in the case of Capital One's SSRF, the content of the request_uri will not be exposed. The main downside is therefore as depicted in the current draft, consumption of the network and processing power of the AS, and the unwanted access load to the servers serving the URL pointed by request_uri. The above-quoted mitigations were introduced to address these issues. 
> 
> 
> 
> 
> On Thu, Jan 16, 2020 at 11:33 PM Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
> > > On 16 Jan 2020, at 08:15, Dominick Baier <[email-masked] <mailto:[email-masked]>> wrote:
> > > 
> > > 
> > >> On 16. January 2020 at 08:07:44, Neil Madden ([email-masked] <mailto:[email-masked]>) wrote:
> > >> 
> > >> [1]: https://ejj.io/blog/capital-one <https://ejj.io/blog/capital-one>
> > >> 
> > >> — Neil
> > >> 
> > >>> On 15 Jan 2020, at 21:02, Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>> wrote:
> > >>>> On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>> wrote:
> > >>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2 <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2>
> > >>>>>>> 
> > >>>>>>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> > >>>>>>>>> The technique of replicating JWT claims that need to be publicly visible in an encrypted JWT in the header is defined at https://tools.ietf.org/html/rfc7519#section-5.3 <https://tools.ietf.org/html/rfc7519#section-5.3>.  (Thanks to Dick Hardt for bringing this need to my attention as we were finishing the JWT spec.)
> > >>>>>>>>> 
> > >>>>>>>>>  
> > >>>>>>>>> 
> > >>>>>>>>>                                                        -- Mike
> > >>>>>>>>> 
> > >>>>>>>>>  
> > >>>>>>>>> 
> > >>>>>>>>> From: OAuth <[email-masked] <mailto:[email-masked]>> On Behalf Of John Bradley
> > >>>>>>>>> To: Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>>
> > >>>>>>>>> Cc: IETF oauth WG <[email-masked] <mailto:[email-masked]>>
> > >>>>>>>>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>> wrote:
> > >>>>>>>>> 
> > >>>>>>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1 <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1>
> > >>>>>>>>> 
> > >>>>>>>>> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>>:
> > >>>>>>>>> >>
> > >>>>>>>>> >> https://openid.net/specs/openid-connect-core-1_0.html#Encryption <https://openid.net/specs/openid-connect-core-1_0.html#Encryption>
> > >>>>>>>>> >>
> > >>>>>>>>> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley <[email-masked] <mailto:[email-masked]>>:

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 17 Jan 2020 02:42:39 +0900

Agree that the heading at least should be changed. I am OK with adding a
dedicated section to describe the possible attacks as well. I was merely
pointing out that the mitigation can be very similar to 10.4.1 and was
asking if there is anything else to be added.

The wording around Mitigation (a) can be a bit tricky as it cannot be an
exact match as it should have enough entropy to thwart guessing attacks.
That's why I resorted to "unexpected location." Perhaps we could say that
it should be under a pre-registered path or something like that. I would
love a pull request to
https://bitbucket.org/Nat/oauth-jwsreq/src/default/draft-ietf-oauth-jwsreq.xml
by
the way.

By "recursive" I exactly meant that AS should not follow redirect blindly.
I did not state that AS MUST NOT follow redirect as I feared that there
could be an implementation or middleware that implements a limited number
of redirects for its internal reasons. Again, I would love a pull request
to
https://bitbucket.org/Nat/oauth-jwsreq/src/default/draft-ietf-oauth-jwsreq.xml
 .

On Fri, Jan 17, 2020 at 1:31 AM Neil Madden <[email-masked]>
wrote:

> The mitigations of 10.4.1 are related, but the section heading is about
> (D)DoS attacks. I think this heading needs to be reworded to apply to SSRF
> attacks too or else add another section with similar mitigations.
>
> Mitigation (a) is a bit vague as to what an "unexpected location" is.
> Perhaps specific wording that it should be a URI that has been
> pre-registered for the client (and validated at that time) or is otherwise
> known to be safe (e.g., is a URI scheme controlled by the AS itself as with
> PAR).
>
> In addition for this to be effective the AS should not follow redirects
> when fetching the URI. It's not clear to me whether that is implied by "not
> perform recursive GET" so it may be worth explicitly spelling that out.
>
> -- Neil
>
>
> Existing OIDC deployment cannot make use of
> application/oauth.authz.req+jwt but it has to validate that content is a
> valid request object anyways and if it is malformed, it MUST stop the
> processing and return an error invalid_request_uri. So, unlike in the case
> of Capital One's SSRF, the content of the request_uri will not be exposed.
> The main downside is therefore as depicted in the current draft,
> consumption of the network and processing power of the AS, and the unwanted
> access load to the servers serving the URL pointed by request_uri. The
> above-quoted mitigations were introduced to address these issues.
>
>
>
>
>> > >>>> If the same reasoning applies, a client_id must always be sent
>> with request / request_uri because client authentication is not performed
>> at the authorization endpoint. In other words, an unauthenticated client
>> (every client is unauthenticated at the authorization endpoint) MUST send
>> its "client_id" to prevent itself from inadvertently accepting a request
>> object for a client with a different "client_id".
>> > >>>>
>> the JWE protected header. An implementation wanting to handle this may look
>> for iss/client_id there.
>> > >>>>>>>>> >
>> > >>>>>>>>> > Odesláno z iPhonu
>> > >>>>>>>>> >

---

From: Joseph Heenan <[email-masked]>
Date: Fri, 17 Jan 2020 09:38:01 +0900

I agree with this, particularly the security concerns of merging. If we merge, we can much guarantee there will eventually be a security issue where an attacker is able to gain an advantage by adding a parameter to the url query (which the server would then happily process if that parameter isn’t found inside the request object). Ruling out that case makes security analysis (particularly when creating new OAuth2 parameters) significantly simpler.

Putting the iss in the JWE header and having the client_id duplicated outside the request object seem to address all the concerns I’ve seen raised.

(It seems like it may be unnecessary to have the client_id duplicated outside if the request_uri is a PAR one though.)

Joseph

> On 16 Jan 2020, at 22:40, John Bradley <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 16 Jan 2020 19:38:50 -0800

> If not, please let me know so that we can add that as the mitigation as

We should probably make sure that we talk about the risks and scope of
potential problems if these checks are not correctly performed.  (I forget
whether we talk about them already or not.)

> introduced to address these issues.

Understood; thanks.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 16 Jan 2020 19:58:44 -0800

> Mitigation (a) is a bit vague as to what an "unexpected location" is. Perhaps specific wording that it should be a URI that has been pre-registered for the client (and validated at that time) or is…

pedantic nit: "URI scheme" is probably not what we want, as the authority
component of the URI (per RFC 3986) seems more likely to match "controlled
by the AS itself"

-Ben

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 Jan 2020 08:44:18 -0500

I don’t agree with this stance from a security or implementation perspective. 

If there’s a clear order of precedence for the information, it’s not particularly problematic. Everything inside the request object is to be taken over things outside the request object. We have the exact same semantics and process with dynamic registration, where the software statement is carried alongside plain JSON claims, and the two are mixed with a very simple algorithm:

 - If a field is inside the signed payload, use that value and ignore any copy of it on the outside
 - If a field is not inside the signed payload and is outside the signed payload, use the outside value

Can someone please point out a concrete security issue with this algorithm? This is the extent of the “merge” semantics that we need here, and it would solve not only the ability to use this for use cases that call for a more static request object (perhaps signed by a third party and not the client) along side the plain parameters that can vary, but also the backwards compatibility issue that’s been discussed. With this algorithm in place, you could have OIDC clients actually be compliant with the spec, since OIDC requires replication of the values inside the request object on the outside with exact matches. An OIDC server wouldn’t be fully compliant with the new spec since it would reject some compliant JAR requests that are missing the external parameters, but that’s fairly easy logic to add on the OIDC side. And in that case you get a matrix of compatibility like:

              JAR Server | OIDC Server  |
------------+------------+--------------+
JAR Client  |     YES    |      NO      |
OIDC Client |     YES    |     YES      |

Breaking one out of the four possible combinations in a very predictable way is, I think, the best way to handle backwards compatibility here. 

But between this issue and JAR’s problematic call for the value of a request_uri to always be a JWT and be fetchable by the AS (neither of which are true in the case of PAR) makes me think we need to pull this back and rework those things, in a push back to the IESG’s comments.

 — Justin

> On Jan 16, 2020, at 7:38 PM, Joseph Heenan <[email-masked]> wrote:
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 17 Jan 2020 16:24:37 +0000

+1 to Justin’s comments. From a security standpoint parameters in the query  string are no different from those in JWT unprotected headers (or protected if they’re also in the request object). Although I‘d amend Justin’s suggestion to say that if a parameter is both inside the request object and outside and they do not match, reject the request as suspicious.

On Jan 17, 2020, at 5:45 AM, Justin Richer <[email-masked]> wrote:

 — Justin

On Jan 16, 2020, at 7:38 PM, Joseph Heenan <[email-masked]<mailto:[email-masked]>> wrote:

Joseph

On 16 Jan 2020, at 22:40, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

John B.

-Ben

---

From: Jim Manico <[email-masked]>
Date: Fri, 17 Jan 2020 11:29:29 -0500

It’s actually worse. Parameters in a URL leak over bookmarks, browser history, logs everywhere, referrer headers... 

One of the most primary rules of secure coding on the web is to never put sensitive data in a URL for •any• verb, not just GET.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Jan 17, 2020, at 11:24 AM, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> 
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 17 Jan 2020 16:34:10 +0000

We should not be prescriptive about how the AS recognizes request URIs from itself. Trusted authority or custom URI scheme are fine as examples, but ultimately this is an internal implementation of the AS. It could just as easily be using data URIs containing a symmetrically encrypted database record ID.

> On Jan 16, 2020, at 8:00 PM, Benjamin Kaduk <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 Jan 2020 13:29:08 -0500

But that’s also the same for parameters in a signed (non-encrypted) request object.

 — Justin

> On Jan 17, 2020, at 11:29 AM, Jim Manico <[email-masked]> wrote:
> 
>>>> On Jan 16, 2020, at 7:38 PM, Joseph Heenan <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>>> On 16 Jan 2020, at 22:40, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>>>>> <https://tools.ietf.org/html/rfc6749#section-3.2.1 <https://tools.ietf.org/html/rfc6749#section-3.2.1>> of RFC 6749 says
>>>>>>>> as follows.
>>>>>>>> 
>>>>>> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI <https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 17 Jan 2020 13:17:01 -0700

I'd support this (client_id being the only additional query parameter
allowed/required) as well.

FWIW, our AS implementations looks for and requires that the response_type
and client_id parameters be present as regular request parameters. This was
done largely to maintain some semblance of compatibility/compliance to
Connect. But client_id is the only one that's helpful.

I also agree with the IESG and others that merging is problematic. I've
personally never believed there was enough real world utility in the merge
approach to justify the added complexity in policy and implementation
and/or reduced security as a result.

On Thu, Jan 16, 2020 at 7:01 AM Neil Madden <[email-masked]>
wrote:

> I believe just client_id would be sufficient for us, so I'd support a
> compromise position in which that is the only additional query parameter
> allowed.
>
> -- Neil
>

-- 
_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._

---

From: Joseph Heenan <[email-masked]>
Date: Sat, 18 Jan 2020 09:17:30 +0900

In my opinion it's still problematic if an attacker can inject claims that aren't in the request object.

A simple (albeit OIDC specific) example would injecting prompt=none or a login_hint, where the request object doesn't have a prompt/login_hint already. In that case if/when people design protocol extensions they have to consider in each case what will happen if a client doesn't specify it (and hence the attacker can inject it) rather than being sure that the values they get will always be genuinely sent by the client if the client is using JAR. (I’m not clear if injecting prompt/login_hint can actually be formed into a useful attack, but I’d don’t think that justifies leaving the whole vector open.)

If there’s really a case for having parameters outside the signed object, it feels like the signed object should explicitly list which unsigned parameters it allows to be used with it. That would mean existing OIDC clients aren’t compatible with JAR. I’m not sure the extra complexity is justified.

I think it’s also arguable that if using PAR the case for ignoring all parameters that are outside the request object is even stronger. We quickly give up some of the easy security gains of PAR if we allow it, and whilst I concede there may be some sensible use cases for pre-signed objects mixed with unsigned parameters (Justin mentioned one of combining a pre-signed request object containing scope/client_id/redirect_uri with unsigned nonce/state/code_challenge) I’m not sure there’s any reason to do this when using PAR.

Joseph

> On 18 Jan 2020, at 01:24, Richard Backman, Annabelle <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 17 Jan 2020 18:50:01 -0800

Definitely; thanks for raising that explicitly.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 17 Jan 2020 18:53:20 -0800

> Can someone please point out a concrete security issue with this algorithm? This is the extent of the “merge” semantics that we need here, and it would solve not only the ability to use this for us…

I agree that the merge algorithm is simple and fairly straightforward to
implement.  But, as Joseph has been alluding, it's only simple if you've
already made the decision to use all the parameters, both from inside and
from outside the signed payload.  The security risk lies about having to
make the trust decision twice, more than the mundane details of actually
doing the merge.  (Though there is still some latent risk, given that we've
seen some really crazy quality of implementation out there.)

It's certainly *possible* that things end up fine in many well-deliniated
cases where merging can be used.  But it's more complicated to reason
about, and I don't remmber seeing much previous discussion about the
specifics of the double trust decision.

-Ben

---

From: Neil Madden <[email-masked]>
Date: Sat, 18 Jan 2020 10:21:04 +0000

> component of the URI (per RFC 3986) seems more likely to match "controlled

Well that's what actually I wanted to prevent. The authority component may refer to services *owned by* the AS (e.g. related microservices) but the authority component of a URI is not under the control of the AS - anybody can put whatever they like in there either from guessing likely hostnames or looking them up in things like certificate transparency logs. Compare that to something like x-request-id:<random-uuid> where the AS has complete control over the address space.

As Nat requested, I'll try and come up with some wording in a pull request that captures the issue in a more general way.

-- Neil

---

From: John Bradley <[email-masked]>
Date: Thu, 23 Jan 2020 18:55:04 -0300

---------- Forwarded message ---------
From: John Bradley <[email-masked]>
Date: Sat, Jan 18, 2020, 9:31 PM
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request
(JAR) vs OIDC request object
To: Benjamin Kaduk <[email-masked]>

If you put the iss in the JWE header it is integrity protected, as JWE
only supports AAD encryption algs.

It is more of a problem when the client is sending a requestURI in that
case having the clientID in the GET to the Authorization endpoint is useful.

I think there is a argument for explicitly allowing the clientID as long as
it exactly matches the clientID in the JAR.

John B.

On Fri, Jan 17, 2020 at 11:53 PM Benjamin Kaduk <[email-masked]> wrote:

> > If there’s a clear order of precedence for the information, it’s not
> particularly problematic. Everything inside the request object is to be
> taken over things outside the request object. We have the exact same
> semantics and process with dynamic registration, where the software
> statement is carried alongside plain JSON claims, and the two are mixed
> with a very simple algorithm:
> >
> > Can someone please point out a concrete security issue with this
> algorithm? This is the extent of the “merge” semantics that we need here,
> and it would solve not only the ability to use this for use cases that call
> for a more static request object (perhaps signed by a third party and not
> the client) along side the plain parameters that can vary, but also the
> backwards compatibility issue that’s been discussed. With this algorithm in
> place, you could have OIDC clients actually be compliant with the spec,
> since OIDC requires replication of the values inside the request object on
> the outside with exact matches. An OIDC server wouldn’t be fully compliant
> with the new spec since it would reject some compliant JAR requests that
> are missing the external parameters, but that’s fairly easy logic to add on
> the OIDC side. And in that case you get a matrix of compatibility like:
>
> > Breaking one out of the four possible combinations in a very predictable
> way is, I think, the best way to handle backwards compatibility here.
> >
> > But between this issue and JAR’s problematic call for the value of a
> request_uri to always be a JWT and be fetchable by the AS (neither of which
> are true in the case of PAR) makes me think we need to pull this back and
> rework those things, in a push back to the IESG’s comments.
> >
> >  — Justin
> >
> >
> > > I agree with this, particularly the security concerns of merging. If
> we merge, we can much guarantee there will eventually be a security issue
> where an attacker is able to gain an advantage by adding a parameter to the
> url query (which the server would then happily process if that parameter
> isn’t found inside the request object). Ruling out that case makes security
> analysis (particularly when creating new OAuth2 parameters) significantly
> simpler.
> > >
> > > Putting the iss in the JWE header and having the client_id duplicated
> outside the request object seem to address all the concerns I’ve seen
> raised.
> > >
> > > (It seems like it may be unnecessary to have the client_id duplicated
> outside if the request_uri is a PAR one though.)
> > >
> > > Joseph
> > >
> > >
> > >
> useful
> insist