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

Brian Campbell bcampbell at pingidentity.com
Mon Apr 20 17:09:24 UTC 2020


On Mon, Apr 20, 2020 at 10:27 AM Joseph Heenan via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi all,
>
> On 20 Apr 2020, at 16:13, Roland Hedberg via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
> To distinguish our variant from the OIDC Core one in the specification we
> demand that aud is set to be the authorisation endpoint of the OP. We also
> ask for the iss and sub claims to be the entity ID of the RP. Furthermore
> we expect jti to be used to prevent reuse.
>
>
> I can’t see any of those requirements mentioned when describing the
> authentication endpoint authentication at
> https://bitbucket.org/openid/connect/src/default/openid-connect-federation-1_0.xml#lines-2085
> - is that mentioned somewhere else?
>

I was going to ask/say the same thing because I couldn't find it either.



This is the problem we need to solve. If we can’t use a client
> authentication method like the one private_key_jwt represents
>
> what other alternatives are there ?
>
>
> A signed request object, passed by value, would achieve the same goal of
> showing control of the private key I think?
>

A signed request object seems much more appropriate.

-- 
_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._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200420/3e4fe531/attachment-0001.html>


More information about the Openid-specs-ab mailing list