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

[Rob Otto]

I agree with this as well.

Rob

On Tue, 17 Mar 2020 at 12:40, Vladimir Dzhuvinov 
wrote:

> +1
>
> Thanks!
>
> Vladimir
> On 12/03/2020 17:31, Brian Campbell wrote:
>
> +1 (again) that `client_id` should be allowed/required as a query
> parameter outside the request object JWT or URI and that its value has to
> be the same as within the request object.
>
> On Thu, Mar 12, 2020 at 8:20 AM Joseph Heenan  wrote:
>
>> I agree with that too.
>>
>> Joseph
>>
>> On 12 Mar 2020, at 14:18, Mike Jones <
>> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>>
>> I agree that we should restore the client_id functionality.  Thanks for
>> moving this forward!
>>
>>-- Mike
>>
>> *From:* OAuth  *On Behalf Of *Nat Sakimura
>> *Sent:* Monday, February 24, 2020 6:18 PM
>> *To:* John Bradley 
>> *Cc:* oauth 
>> *Subject:* Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization
>> Request (JAR) vs OIDC request object
>>
>> So, where should we take it to?
>> Just add back client_id as it used to be?
>>
>> On Fri, Jan 24, 2020 at 6:55 AM John Bradley  wrote:
>>
>>
>> -- Forwarded message -
>> From: *John Bradley* 
>> 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 
>>
>>
>> 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  wrote:
>>
>> On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:
>> > 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:
>>
>> 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
>>
>> >
>> >   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 

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

[Vladimir Dzhuvinov]

+1

Thanks!

Vladimir

On 12/03/2020 17:31, Brian Campbell wrote:
> +1 (again) that `client_id` should be allowed/required as a query
> parameter outside the request object JWT or URI and that its value has
> to be the same as within the request object.
>
> On Thu, Mar 12, 2020 at 8:20 AM Joseph Heenan  > wrote:
>
> I agree with that too.
>
> Joseph
>
>> On 12 Mar 2020, at 14:18, Mike Jones
>> > > wrote:
>>
>> I agree that we should restore the client_id functionality. 
>> Thanks for moving this forward!
>>  
>>    -- Mike
>>  
>> *From:* OAuth > > *On Behalf Of *Nat Sakimura
>> *Sent:* Monday, February 24, 2020 6:18 PM
>> *To:* John Bradley mailto:ve7...@ve7jtb.com>>
>> *Cc:* oauth mailto:oauth@ietf.org>>
>> *Subject:* Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured
>> Authorization Request (JAR) vs OIDC request object
>>  
>> So, where should we take it to? 
>> Just add back client_id as it used to be?
>>  
>> On Fri, Jan 24, 2020 at 6:55 AM John Bradley > > wrote:
>>
>>  
>> -- Forwarded message -
>> From: *John Bradley* > >
>> 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 mailto:ka...@mit.edu>>
>>
>>  
>>
>> 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
>> mailto:ka...@mit.edu>> wrote:
>>
>> On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer
>> wrote:
>> > 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:
>>
>> 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
>>  

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

[Nat Sakimura]

So, I am getting overwhelming approval on getting client_id back.
In the next few days, I will create another draft that has it back.

Best,

Nat Sakimura

On Fri, Mar 13, 2020 at 1:25 AM George Fletcher  wrote:

> I'm a +1 for adding client_id back as well
>
> On 3/12/20 11:31 AM, Brian Campbell wrote:
>
> +1 (again) that `client_id` should be allowed/required as a query parameter
> outside the request object JWT or URI and that its value has to be the same
> as within the request object.
>
> On Thu, Mar 12, 2020 at 8:20 AM Joseph Heenan  
>  wrote:
>
>
> I agree with that too.
>
> Joseph
>
> On 12 Mar 2020, at 14:18, Mike Jones 
>  wrote:
>
> I agree that we should restore the client_id functionality.  Thanks for
> moving this forward!
>
>-- Mike
>
> *From:* OAuth   *On Behalf Of 
> *Nat Sakimura
> *Sent:* Monday, February 24, 2020 6:18 PM
> *To:* John Bradley  
> *Cc:* oauth  
> *Subject:* Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization
> Request (JAR) vs OIDC request object
>
> So, where should we take it to?
> Just add back client_id as it used to be?
>
> On Fri, Jan 24, 2020 at 6:55 AM John Bradley  
>  wrote:
>
>
> -- Forwarded message -
> From: *John Bradley*  
> 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  
>
>
> 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  
>  wrote:
>
> On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:
>
> 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:
>
> 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
>
>
>   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.

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

[George Fletcher]

I'm a +1 for adding client_id back as well

On 3/12/20 11:31 AM, Brian Campbell wrote:

+1 (again) that `client_id` should be allowed/required as a query parameter
outside the request object JWT or URI and that its value has to be the same
as within the request object.

On Thu, Mar 12, 2020 at 8:20 AM Joseph Heenan  wrote:


I agree with that too.

Joseph

On 12 Mar 2020, at 14:18, Mike Jones <
Michael.Jones=40microsoft@dmarc.ietf.org> wrote:

I agree that we should restore the client_id functionality.  Thanks for
moving this forward!

-- Mike

*From:* OAuth  *On Behalf Of *Nat Sakimura
*Sent:* Monday, February 24, 2020 6:18 PM
*To:* John Bradley 
*Cc:* oauth 
*Subject:* Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization
Request (JAR) vs OIDC request object

So, where should we take it to?
Just add back client_id as it used to be?

On Fri, Jan 24, 2020 at 6:55 AM John Bradley  wrote:


-- Forwarded message -
From: *John Bradley* 
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 


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  wrote:

On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:

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:

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


   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 

wrote:

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 

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

[Brian Campbell]

+1 (again) that `client_id` should be allowed/required as a query parameter
outside the request object JWT or URI and that its value has to be the same
as within the request object.

On Thu, Mar 12, 2020 at 8:20 AM Joseph Heenan  wrote:

> I agree with that too.
>
> Joseph
>
> On 12 Mar 2020, at 14:18, Mike Jones <
> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>
> I agree that we should restore the client_id functionality.  Thanks for
> moving this forward!
>
>-- Mike
>
> *From:* OAuth  *On Behalf Of *Nat Sakimura
> *Sent:* Monday, February 24, 2020 6:18 PM
> *To:* John Bradley 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization
> Request (JAR) vs OIDC request object
>
> So, where should we take it to?
> Just add back client_id as it used to be?
>
> On Fri, Jan 24, 2020 at 6:55 AM John Bradley  wrote:
>
>
> -- Forwarded message -
> From: *John Bradley* 
> 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 
>
>
> 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  wrote:
>
> On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:
> > 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:
>
> 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
>
> >
> >   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 
> wrote:
> > >
> > > 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 

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

[Joseph Heenan]

I agree with that too.

Joseph

> On 12 Mar 2020, at 14:18, Mike Jones 
>  wrote:
> 
> I agree that we should restore the client_id functionality.  Thanks for 
> moving this forward!
>  
>-- Mike
>  
> From: OAuth mailto:oauth-boun...@ietf.org>> On 
> Behalf Of Nat Sakimura
> Sent: Monday, February 24, 2020 6:18 PM
> To: John Bradley mailto:ve7...@ve7jtb.com>>
> Cc: oauth mailto:oauth@ietf.org>>
> Subject: Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization Request 
> (JAR) vs OIDC request object
>  
> So, where should we take it to? 
> Just add back client_id as it used to be?
>  
> On Fri, Jan 24, 2020 at 6:55 AM John Bradley  > wrote:
>  
> -- Forwarded message -
> From: John Bradley mailto:ve7...@ve7jtb.com>>
> 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 mailto:ka...@mit.edu>>
>  
> 
> 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  > wrote:
> On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:
> > 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:
> 
> 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
> 
> > 
> >   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  > > > wrote:
> > > 
> > > I agree with this, particularly the security concerns of merging. If we 
> > > merge, we can much guarantee there will eventually be a security issue 
> > > 

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

[Mike Jones]

I agree that we should restore the client_id functionality.  Thanks for moving 
this forward!

   -- Mike

From: OAuth  On Behalf Of Nat Sakimura
Sent: Monday, February 24, 2020 6:18 PM
To: John Bradley 
Cc: oauth 
Subject: Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization Request 
(JAR) vs OIDC request object

So, where should we take it to?
Just add back client_id as it used to be?

On Fri, Jan 24, 2020 at 6:55 AM John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:

-- Forwarded message -
From: John Bradley mailto:ve7...@ve7jtb.com>>
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 mailto:ka...@mit.edu>>

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 
mailto:ka...@mit.edu>> wrote:
On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:
> 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:

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

>
>   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 
> > mailto:jos...@authlete.com>> wrote:
> >
> > 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 

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

[John Bradley]

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 
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.
>
> 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
>
>
> On 10/01/2020 22:39, Filip Skokan wrote:
> > 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 :
> >>
> >> 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
> >>
> >>
> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
> >>>
> > Am 10.01.2020 um 16:53 schrieb John Bradley :
>  I think Torsten is speculating that is not a feature people use.
> >>> 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.
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Vladimir Dzhuvinov]

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


On 10/01/2020 22:39, Filip Skokan wrote:
> 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 :
>>
>> 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
>>
>>
>>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>>>
> Am 10.01.2020 um 16:53 schrieb John Bradley :
 I think Torsten is speculating that is not a feature people use.   
>>> 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.




smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Filip Skokan]

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 :
> 
> 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
> 
> 
>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>> 
 Am 10.01.2020 um 16:53 schrieb John Bradley :
>>> 
>>> I think Torsten is speculating that is not a feature people use.   
>> 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.
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Vladimir Dzhuvinov]

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


On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>
>> Am 10.01.2020 um 16:53 schrieb John Bradley :
>>
>> I think Torsten is speculating that is not a feature people use.   
> 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.




smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[John Bradley]

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  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.
>
> 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  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.
>
> 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 
> wrote:
>
>>
>>
>> Am 06.01.2020 um 23:50 schrieb John Bradley :
>>
>> 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.
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

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  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. 
> 
> 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  > wrote:
> 
> 
>> Am 06.01.2020 um 23:50 schrieb John Bradley > >:
>> 
>> 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.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[John Bradley]

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 
wrote:

>
>
> Am 06.01.2020 um 23:50 schrieb John Bradley :
>
> 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.
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

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  wrote:
> 
> 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:
>> 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 MUST only use the parameters in the Request Object even if the
>>same parameter is provided in the query parameter.  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: n-sakim...@nri.co.jp <mailto:n-sakim...@nri.co.jp>
>> 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  <mailto:oauth-boun...@ietf.org> On 
>> Behalf Of Justin Richer
>> Sent: Friday, January 3, 2020 2:35 AM
>> To: Takahiko Kawasaki  <mailto:t...@authlete.com>
>> Cc: Brian Campbell  
>> <mailto:bcampbell=40pingidentity@dmarc.ietf.org>; oauth  
>> <mailto:oauth@ietf.org>; Nat Sakimura  
>> <mailto:nat.sakim...@oidf.org>
>> 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.
>>  
>> 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

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

[Torsten Lodderstedt]

> Am 06.01.2020 um 23:50 schrieb John Bradley :
> 
> 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.

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Takahiko Kawasaki]

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  wrote:

> 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  wrote:
>
>> 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 MUST only use the parameters in the Request Object even if the
>>
>>same parameter is provided in the query parameter.  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: n-sakim...@nri.co.jp
>>
>> 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  *On Behalf Of *Justin Richer
>> *Sent:* Friday, January 3, 2020 2:35 AM
>> *To:* Takahiko Kawasaki 
>> *Cc:* Brian Campbell ;
>> oauth ; Nat Sakimura 
>> *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.
&g

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

[Filip Skokan]

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  wrote:

> 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 MUST only use the parameters in the Request Object even if the
>
>same parameter is provided in the query parameter.  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: n-sakim...@nri.co.jp
>
> 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  *On Behalf Of *Justin Richer
> *Sent:* Friday, January 3, 2020 2:35 AM
> *To:* Takahiko Kawasaki 
> *Cc:* Brian Campbell ; oauth
> ; Nat Sakimura 
> *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.
>
>
>
> 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 Cli

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

[n-sakimura]

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 MUST only use the parameters in the Request Object even if the

   same parameter is provided in the query parameter.  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: n-sakim...@nri.co.jp
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  On Behalf Of Justin Richer
Sent: Friday, January 3, 2020 2:35 AM
To: Takahiko Kawasaki 
Cc: Brian Campbell ; oauth 
; Nat Sakimura 
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.

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 
mailto:t...@authlete.com>> 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 optiona

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

[Vladimir Dzhuvinov]

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

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

[Justin Richer]

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  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 
> ,
>  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 

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

[Takahiko Kawasaki]

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
,
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  wrote:

> I think the nature of the backwards incompatibility is important here. The
> way that things are now, using merge-with-precedence, you have the
> following matrix of compatibility:
>
>
>  New Server  |  Old Server  |
> ---+-+--+
> New Client |  YES|  NO  |
> Old Client |  YES| YES  |
>
>
> If you ask me, this is the right balance for a breaking change. Old
> clients, where the vast majority of the code is, don’t have to change. New
> clients can only talk to servers with the new features, which is the
> ability to drop parameters from the external request. This would apply to
> both OIDC and plain OAuth.
>
> I think we should follow this kind of pattern in the discussions on OAuth
> 2.1, which I think JAR should be a part of/
>
>  — Justin
>
>
>
> On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki  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  wrote:
>
>> So, no change is OK?
>>
>> On Wed, Dec 11, 2019 at 10:01 PM John Bradley  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
>>> 

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

[Justin Richer]

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  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  > wrote:
> So, no change is OK? 
> 
> On Wed, Dec 11, 2019 at 10:01 PM John Bradley  > 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  > 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 
>  >:
> 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  > 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  > 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  > 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 
> 

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

[Takahiko Kawasaki]

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  wrote:

> So, no change is OK?
>
> On Wed, Dec 11, 2019 at 10:01 PM John Bradley  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  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 >> 40pingidentity.@dmarc.ietf.org <40pingidentity@dmarc.ietf.org>>:
>>>
 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 
 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 <
> bcampb...@pingidentity.com> 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 
>> 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 

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

[John Bradley]

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  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  40pingidentity.@dmarc.ietf.org <40pingidentity@dmarc.ietf.org>>:
>
>> 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  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 
>>> 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 
 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
> 

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

[Dominick Baier]

My preference would be that if a request object is used, all parameters
must go in there

a) makes the AS implementation easier
b) there is really no point (IMO) to have a mixture of signed and unsigned
parameters
c) certain parameters should go into the RO - e.g. the code_challenge to
prevent the “chosen code challenge attack” (at least that’s how I
understood it) - again enforcing that makes the AS logic more complicated
d) it’s a clear statement

cheers
———
Dominick Baier

On 11. December 2019 at 03:29:14, Nat Sakimura (sakim...@gmail.com) 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 >:

> 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  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 
>> 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  wrote:
>>>
 Hello everyone,

 in an earlier thread I've posed the following question that might have
 gotten missed, this might have consequences for the existing
 implementations of Request Objects in OIDC implementations - its making
 pure JAR requests incompatible with OIDC Core implementations.

 draft 14 of jwsreq (JAR) introduced this language

 The client MAY send the parameters included in the request object
> duplicated in the query parameters as well for the backward
> compatibility etc.
>
> *However, the authorization server supporting this specification MUST
> only use the parameters included in the request object. *


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


 The client MAY send the parameters included in the request object
> duplicated in the query parameters as well for the backward
> compatibility etc.
>
> *However, the authorization server supporting this specification MUST
> only use the parameters included in the request object. *


 Nat, John, everyone - *does this mean a JAR compliant AS ignores
 everything outside of the request object while OIDC Request Object one
 merges the two with the ones in the request object being used over ones
 that are sent in clear?* The OIDC language also includes sections
 which make sure that some required arguments are still passed outside of
 the request object with the same value to make sure the request is "valid"
 OAuth 2.0 request (client_id, response_type), something which an example in
 the JAR spec does not do. Not having this language means that existing
 authorization request pipelines can't simply be extended with e.g. a
 middleware, they need to branch their codepaths.

 Is an AS required to choose which of the two it follows?

 Thank you for 

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

[Nat Sakimura]

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 :

> 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  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 
>> 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  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
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth

>>>
>>> 

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

[Takahiko Kawasaki]

I'm sorry for this late response, but I'm also afraid that the requirement
"the authorization server supporting this specification MUST only use the
parameters included in the request object." in Section 6 of the draft 20
 is problematic.

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


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


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

I haven't found any convincing reasons yet that can justify introducing the
requirement that dares to break the backward compatibility. For me, the
following requirement in FAPI Part 2
, 5.2.2.
,
10. seems a good compromise.

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



Best Regards,
Takahiko Kawasaki
Authlete, Inc.



On Thu, Aug 29, 2019 at 5:04 PM Torsten Lodderstedt 
wrote:

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

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

[Torsten Lodderstedt]

> Am 28.08.2019 um 23:23 schrieb Filip Skokan :
> 
> - allows merging request object and regular parameters with request object 
> taking precedence since it is a very useful feature when having pre-signed 
> request object that's not one time use and clients using it wish to vary 
> state/nonce per-request.

+1

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

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  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 
> 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  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
>>> OAuth@ietf.org
>>> 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 

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

[Filip Skokan]

It would be fine not allowing that across the board but rather through a 
language like so

‘Authorization Servers MAY allow per-transaction parameters such as “state” and 
“nonce” to be sent outside of the Request Object using regular OAuth 2.0 
parameter syntax, the specific parameters are at the implementer’s discretion’

Odesláno z iPhonu

28. 8. 2019 v 23:23, Filip Skokan :

> 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  
>> 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  wrote:
>>> Hello everyone,
>>> 
>>> in an earlier thread I've posed the following question that might have 
>>> gotten missed, this might have consequences for the existing 
>>> implementations of Request Objects in OIDC implementations - its making 
>>> pure JAR requests incompatible with OIDC Core implementations.
>>> 
>>> draft 14 of jwsreq (JAR) introduced this language
>>> 
 The client MAY send the parameters included in the request object
 duplicated in the query parameters as well for the backward
 compatibility etc.  However, the authorization server supporting this
 specification MUST only use the parameters included in the request
 object. 
>>> 
 Server MUST only use the parameters in the Request Object even if the
 same parameter is provided in the query parameter.  The Authorization
>>> 
 The client MAY send the parameters included in the request object
 duplicated in the query parameters as well for the backward
 compatibility etc.  However, the authorization server supporting this
 specification MUST only use the parameters included in the request
 object. 
>>> 
>>> Nat, John, everyone - does this mean a JAR compliant AS ignores everything 
>>> outside of the request object while OIDC Request Object one merges the two 
>>> with the ones in the request object being used over ones that are sent in 
>>> clear? The OIDC language also includes sections which make sure that some 
>>> required arguments are still passed outside of the request object with the 
>>> same value to make sure the request is "valid" OAuth 2.0 request 
>>> (client_id, response_type), something which an example in the JAR spec does 
>>> not do. Not having this language means that existing authorization request 
>>> pipelines can't simply be extended with e.g. a middleware, they need to 
>>> branch their codepaths.
>>> 
>>> Is an AS required to choose which of the two it follows?
>>> 
>>> Thank you for clarifying this in advance. I think if either the behaviour 
>>> is the same as in OIDC or different this should be called out in the 
>>> language to avoid confusion, especially since this already exists in OIDC 
>>> and likely isn't going to be read in isolation, especially because the 
>>> Request Object is even called out to be already in place in OIDC in the JAR 
>>> draft.
>>> 
>>> Best,
>>> Filip
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> 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.
___
OAuth mailing list

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

[Filip Skokan]

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 
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  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
>> OAuth@ietf.org
>> 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.*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

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  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
> OAuth@ietf.org
> 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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Filip Skokan]

I can get by not having to have the minimum oauth request parameters, but the 
current language does not imply that one can use the parameters if they’re not 
present in the Request Object. 

That derails JAR from its OIDC variant. 

Odesláno z iPhonu

28. 8. 2019 v 10:48, Torsten Lodderstedt :

> Hi Filip,
> 
> In my understanding, duplication of request parameters outside of the request 
> object was necessary in the OIDC variant in order to retain OAuth compliance. 
> JAR as an OAuth extension will not require the client to duplicate OAuth 
> request parameters outside of the request object.  
> 
> There might potentially be reasons for merging (different) URI request 
> parameters with parameters passed in the request object in cases where long 
> living request objects are used.  
> 
> kind regards,
> Torsten. 
> 
>> On 27. Aug 2019, at 13:46, Filip Skokan  wrote:
>> 
>> Hello everyone,
>> 
>> in an earlier thread I've posed the following question that might have 
>> gotten missed, this might have consequences for the existing implementations 
>> of Request Objects in OIDC implementations - its making pure JAR requests 
>> incompatible with OIDC Core implementations.
>> 
>> draft 14 of jwsreq (JAR) introduced this language
>> 
>> The client MAY send the parameters included in the request object
>> duplicated in the query parameters as well for the backward
>> compatibility etc.  However, the authorization server supporting this
>> specification MUST only use the parameters included in the request
>> object. 
>> 
>> Server MUST only use the parameters in the Request Object even if the
>> same parameter is provided in the query parameter.  The Authorization
>> 
>> The client MAY send the parameters included in the request object
>> duplicated in the query parameters as well for the backward
>> compatibility etc.  However, the authorization server supporting this
>> specification MUST only use the parameters included in the request
>> object. 
>> 
>> Nat, John, everyone - does this mean a JAR compliant AS ignores everything 
>> outside of the request object while OIDC Request Object one merges the two 
>> with the ones in the request object being used over ones that are sent in 
>> clear? The OIDC language also includes sections which make sure that some 
>> required arguments are still passed outside of the request object with the 
>> same value to make sure the request is "valid" OAuth 2.0 request (client_id, 
>> response_type), something which an example in the JAR spec does not do. Not 
>> having this language means that existing authorization request pipelines 
>> can't simply be extended with e.g. a middleware, they need to branch their 
>> codepaths.
>> 
>> Is an AS required to choose which of the two it follows?
>> 
>> Thank you for clarifying this in advance. I think if either the behaviour is 
>> the same as in OIDC or different this should be called out in the language 
>> to avoid confusion, especially since this already exists in OIDC and likely 
>> isn't going to be read in isolation, especially because the Request Object 
>> is even called out to be already in place in OIDC in the JAR draft.
>> 
>> Best,
>> Filip
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

Hi Filip,

In my understanding, duplication of request parameters outside of the request 
object was necessary in the OIDC variant in order to retain OAuth compliance. 
JAR as an OAuth extension will not require the client to duplicate OAuth 
request parameters outside of the request object.  

There might potentially be reasons for merging (different) URI request 
parameters with parameters passed in the request object in cases where long 
living request objects are used.  

kind regards,
Torsten. 

> On 27. Aug 2019, at 13:46, Filip Skokan  wrote:
> 
> Hello everyone,
> 
> in an earlier thread I've posed the following question that might have gotten 
> missed, this might have consequences for the existing implementations of 
> Request Objects in OIDC implementations - its making pure JAR requests 
> incompatible with OIDC Core implementations.
> 
> draft 14 of jwsreq (JAR) introduced this language
> 
> The client MAY send the parameters included in the request object
> duplicated in the query parameters as well for the backward
> compatibility etc.  However, the authorization server supporting this
> specification MUST only use the parameters included in the request
> object. 
> 
> Server MUST only use the parameters in the Request Object even if the
> same parameter is provided in the query parameter.  The Authorization
> 
> The client MAY send the parameters included in the request object
> duplicated in the query parameters as well for the backward
> compatibility etc.  However, the authorization server supporting this
> specification MUST only use the parameters included in the request
> object. 
> 
> Nat, John, everyone - does this mean a JAR compliant AS ignores everything 
> outside of the request object while OIDC Request Object one merges the two 
> with the ones in the request object being used over ones that are sent in 
> clear? The OIDC language also includes sections which make sure that some 
> required arguments are still passed outside of the request object with the 
> same value to make sure the request is "valid" OAuth 2.0 request (client_id, 
> response_type), something which an example in the JAR spec does not do. Not 
> having this language means that existing authorization request pipelines 
> can't simply be extended with e.g. a middleware, they need to branch their 
> codepaths.
> 
> Is an AS required to choose which of the two it follows?
> 
> Thank you for clarifying this in advance. I think if either the behaviour is 
> the same as in OIDC or different this should be called out in the language to 
> avoid confusion, especially since this already exists in OIDC and likely 
> isn't going to be read in isolation, especially because the Request Object is 
> even called out to be already in place in OIDC in the JAR draft.
> 
> Best,
> Filip
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Filip Skokan]

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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth