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

[Nat Sakimura <[e-mail]>]

So, no change is OK?

On Wed, Dec 11, 2019 at 10:01 PM John Bradley <[e-mail]> wrote:

> I also slightly prefer the merge approach.
>
> There are plusses and minuses to both.
>
> Changing again now that it is past ISEG review and backing out a Discuss
> will add another three to six months at this point, if we can get them to
> agree to the change.
>
> John B.
>
> On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura <[e-mail]> wrote:
>
>> Correct. The WG supported the precedence approach and even merge just
>> like OIDC as it is very useful from the implementation point of view and
>> helps with a bunch of deployment patter.
>>
>> The push back came in from the Ben Campbell’s DISCUSS.
>> See
>>
>> https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actually-specifies-the
>>
>> I am willing to go either way as long as people agree. My slight
>> preference is to the original approach.
>>
>> Best,
>>
>> Nat Sakimura
>>
>> 2019年8月29日(木) 6:56 Brian Campbell <bcampbell=
>> [e-mail] <[e-mail]>>:
>>
>>> FWIW, as best I can remember the change in question came as I result of directorate/IESG
>>> review rather than a WG decision/discussion. Which is likely why you can't
>>> find the "why" anywhere in the mailing list archive.
>>>
>>> On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan <[e-mail]> wrote:
>>>
>>>> Well it kind of blows, doesn't it? I wasn't able to find the "why"
>>>> anywhere in the mailing list archive around the time this was changed.
>>>>
>>>> My take on satisfying both worlds looks like this
>>>>
>>>> - allow just JAR - no other params when possible.
>>>>     (which btw isn't possible to do with request_uri when enforcing
>>>> client based uri whitelist and the jwsreq 5.2.2 shows as much)
>>>> - enforce the "dupe behaviours" defined in OIDC (if response_type or
>>>> client_id is in request object it must either be missing or the same in
>>>> regular request).
>>>> - allows merging request object and regular parameters with request
>>>> object taking precedence since it is a very useful feature when having
>>>> pre-signed request object that's not one time use and clients using it wish
>>>> to vary state/nonce per-request.
>>>>
>>>> I wish the group reconsidered making this breaking change from OIDC's
>>>> take on request objects - allow combination of parameters from the request
>>>> object with ones from regular parameters (if not present in request object).
>>>>
>>>> S pozdravem,
>>>> *Filip Skokan*
>>>>
>>>>
>>>> On Wed, 28 Aug 2019 at 23:02, Brian Campbell <
>>>> [e-mail]> wrote:
>>>>
>>> Filip, for better or worse, I believe your assessment of the situation
>>>>> is correct. I know of one AS that didn't choose which of the two to follow
>>>>> but rather implemented a bit of a hybrid where it basically ignores
>>>>> everything outside of the request object per JAR but also checks for and
>>>>> enforces the presence and value of the few regular parameters (client_id,
>>>>> response_type) that OIDC mandates.
>>>>>
>>>>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan <[e-mail]>
>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>
>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>>> privileged material for the sole use of the intended recipient(s). Any
>>>>> review, use, distribution or disclosure by others is strictly prohibited.
>>>>> If you have received this communication in error, please notify the sender
>>>>> immediately by e-mail and delete the message and any file attachments from
>>>>> your computer. Thank you.*
>>>>
>>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited..
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.*
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en