Re: [OAUTH-WG] swapping a jwsreq/JAR JWT for a client authentication JWT

[Brian Campbell <[e-mail]>]

I also suspect the Jwsreq authors won't respond to this and the
request/suggestion will be ignored. Which is discouraging. I realize it's
late in the process for this document but it's been in IESG Evaluation
since early 2017. And the recent ballot comments
https://mailarchive.ietf.org/arch/msg/oauth/FMljWETMEkGTI4pUluqIqtAJ_9A/
suggests changes to the draft should still be forthcoming. So also adding a
brief statement to the security considerations doesn't seem inconceivable.

On Thu, Jul 23, 2020 at 2:29 PM Brian Campbell <[e-mail]>
wrote:

> In hindsight, yeah, having explicit JWT typing everywhere would be nice..
> But retrofitting would be a very major undertaking, which I don't think
> could reasonably be justified considering cost–benefit.
>
> I can't speak directly for the Jwsreq authors but I suspect considerations
> around backward/forward compatibility with OIDC's JWT request and even
> existing implementations of the Jwsreq draft that has been in draft forever
> came into play.
>
> On Wed, Jul 22, 2020 at 11:38 PM Dominick Baier <[e-mail]>
> wrote:
>
>> Even more. Jwsreq should have it. But the authors decided against it.
>>
>> ———
>> Dominick Baier
>>
>> On 23. July 2020 at 07:38:04, Dominick Baier ([e-mail])
>> wrote:
>>
>> Good point. Thanks, Brian.
>>
>> We should retrofit typs everywhere..in hindsight.
>>
>> ———
>> Dominick Baier
>>
>> On 22. July 2020 at 23:55:20, Brian Campbell ([e-mail])
>> wrote:
>>
>> Because it wouldn't actually prevent it in this case due to JWT assertion
>> client authentication (a.k.a. private_key_jwt) having come about well
>> before the JWT BCP and the established concept of using the 'typ' header to
>> prevent cross-JWT confusion. Thus there's no validation rule regarding the
>> 'typ' header defined in RFC 7523 for JWT client authentication. Explicitly
>> typing the request object JWT doesn't do anything to prevent it from being
>> used in the context of previously existing JWT applications like client
>> auth.
>>
>> On Wed, Jul 22, 2020 at 10:32 AM Dominick Baier <
>> [e-mail]> wrote:
>>
>>> Why not use a typ header as suggested by the JWT BCP?
>>>
>>> ———
>>> Dominick Baier
>>>
>>> On 22. July 2020 at 17:37:41, Brian Campbell (
>>> bcampbell=[e-mail]) wrote:
>>>
>>> The TL;DR here is a somewhat tentative suggestion that a brief security
>>> consideration be added to
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>>> <https://datatracker..ietf.org/doc/draft-ietf-oauth-jwsreq/> that
>>> prohibits the inclusion of a 'sub' claim containing the client id value in
>>> the request object JWT so as to prevent the request object JWT (which is
>>> exposed to the user agent) from being erroneously accepted as a valid JWT
>>> for client authentication.
>>>
>>> Some more details and the discussion that led to this here email can be
>>> found at https://github.com/oauthstuff/draft-oauth-par/issues/41
>>>
>>> *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
>>>
>>>
>> *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._