[Openid-specs-ab] Issue #1164: insecure front-channel use of private_key_jwt client authentication (openid/connect)

Roland Hedberg roland at catalogix.se
Tue Apr 21 13:52:16 UTC 2020

It’s not specified.

And I don’t think there is any difference if client_assertion/client_assertion_type or signed requests are used.

Myself I’m on the side of Joseph; if your library can do it why not do it always.
I guess the downside is that it is costly, both for the OP and the RP.

So are there any security reason for always doing it ?

As an implementer it would make my life easier to have the behaviour be the same all the time. 
Instead of switching between 2 variants.

> On 21 Apr 2020, at 15:10, Brian Campbell <bcampbell at pingidentity.com> wrote:
> How did/does that work when client_assertion/client_assertion_type were being tacked onto the authz request? Without reevaluating the bigger approach, it sure seemed like client_assertion was trying to be used like a signed request and so it seems like an actual signed request object should just be a more appropriate replacement.  
> On Tue, Apr 21, 2020 at 12:57 AM Roland Hedberg <roland at catalogix.se <mailto:roland at catalogix.se>> wrote:
> If we use signed request objects, do we mandate it for all authorization requests or just for the first one.
> 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.

— Roland
Can anything be sadder than work left unfinished? Yes, work never begun. -Christina Rossetti, poet (5 Dec 1830-1894) 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200421/6bd1b4ba/attachment.html>

More information about the Openid-specs-ab mailing list