<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="">Hi all,<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 20 Apr 2020, at 16:13, Roland Hedberg via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</div><div class=""><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><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></div></blockquote><div><br class=""></div><div>I can’t see any of those requirements mentioned when describing the authentication endpoint authentication at <a href="https://bitbucket.org/openid/connect/src/default/openid-connect-federation-1_0.xml#lines-2085" class="">https://bitbucket.org/openid/connect/src/default/openid-connect-federation-1_0.xml#lines-2085</a> - is that mentioned somewhere else?</div><div><br class=""></div><div><br class=""></div><…><br class=""><blockquote type="cite" class=""><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><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></blockquote><div><br class=""></div><div>A signed request object, passed by value, would achieve the same goal of showing control of the private key I think?</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><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></div></blockquote></div><br class=""><div class="">I’m not sure why MTLS given the current federation draft doesn’t mention MTLS that I see? But PAR (with an unsigned request object) with private_key_jwt (or MTLS) sounds like it’d solve the problem too.</div><div class=""><br class=""></div><div class="">Joseph</div><div class=""><br class=""></div></body></html>