
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 17 Apr 2020, at 23:48, Brian Campbell via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">New issue 1164: insecure front-channel use of private_key_jwt client authentication<br class=""><a href="https://bitbucket.org/openid/connect/issues/1164/insecure-front-channel-use-of" class="">https://bitbucket.org/openid/connect/issues/1164/insecure-front-channel-use-of</a><br class=""><br class="">Brian Campbell:<br class=""><br class="">“At a minimum openid-connect-federation needs to acknowledge that it's misusing private\_key\_jwt and do something to mitigate the security problem.” <br class=""><br class="">Please see [https://github.com/oauthstuff/draft-oauth-par/issues/41](https://github.com/oauthstuff/draft-oauth-par/issues/41) but particularly the comments at [https://github.com/oauthstuff/draft-oauth-par/issues/41#issuecomment-615081283](https://github.com/oauthstuff/draft-oauth-par/issues/41#issuecomment-615081283) and [https://github.com/oauthstuff/draft-oauth-par/issues/41#issuecomment-615475230](https://github.com/oauthstuff/draft-oauth-par/issues/41#issuecomment-615475230) <br class=""><br class=""></div></blockquote><br class=""></div><div><div class="">First, I’m glad we’re having this discussion.</div><div class=""><br class=""></div><div class="">Second, the specification says we want to use the private_key_jwt method of authentication not private_key_jwt </div><div class="">exactly as described in OIDC Core.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Now, if this isn’t enough let’s take a step back and look at the issue we’re trying to solve.</div><div class=""><br class=""></div><div class="">OIDC federation is built on dynamic discovery and registration. We want to avoid doing static registration since it scales very badly.</div><div class=""><br class=""></div><div class="">To begin with we had only one type of dynamic client registration, one that looks very much like what’s described in </div><div class=""><a href="https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata" class="">https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata</a></div><div class="">in that the client sends a client registration request.</div><div class=""><br class=""></div><div class="">Now, when the OIDC federation draft was voted on to become an implementers draft (now soon 2 years ago) Andreas Solberg</div><div class="">came up with the idea to not have the client do an explicit client registration but to connect the registration to the authorization request in </div><div class="">such a way that the OP would ‘automatically’ do the registration when it got a request from an RP it had never seen before.</div><div class=""><br class=""></div><div class="">For this to work we needed a way to securely bind an authorization request to the RP metadata.</div><div class="">Looking at what was available in the OIDC arsenal, private_key_jwt jumped out. Using this method</div><div class="">we could see that the RP was in control of the private key of the key pair where the public would reside in the metadata.</div><div class=""><br class=""></div><div class="">This is the problem we need to solve. If we can’t use a client authentication method like the one private_key_jwt represents</div><div class="">what other alternatives are there ?</div><div class=""><br class=""></div><div class="">I’ve been pointed to one alternative and that is using pushed authorization with MTLS.</div><div class="">To me it seems like that could work though it adds another layer of complexity.</div><div class=""><br class=""></div></div><div class="">

<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">— Roland</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">Scratch a pessimist and you find often a defender of privilege. -William Beveridge, economist and reformer (5 Mar 1879-1963) </div>

</div>

<br class=""></body></html>