<div dir="ltr"><div><p>Date: 14/08/2025</p>
<p>Attendees: Ethan Heilman, Mike Jones, Frederik Krogsdal Jacobsen, Dick Hardt, Andy Barlow, George Fletcher, Lukasz Jaromin, Aaron Parecki, Chris Phillips, Filip Skokan, Andrii Deinega</p>
<p>Ethan is a cryptographer at Cloudflare. He had a now acquired company which provided a technology to put public keys into ID tokens (OpenPubKey, see <a href="https://eprint.iacr.org/2023/296">https://eprint.iacr.org/2023/296</a>). This can be used for software supply chain security, SSH connections, proxy connections and other applications. This is related to the spec proposal we will discuss later in the meeting.</p>
<p>Events:</p>
<ul>
<li>IIW dates have changed. See <a href="https://internetidentityworkshop.com/">https://internetidentityworkshop.com/</a>.</li>
<li>Does anyone know if DICE will happen this year? It was postponed to November, but no date has been set so far. See <a href="https://diceurope.org/">https://diceurope.org/</a>. Frederik will ask in the OIDF Slack.</li>
</ul>
<p>Connect PRs:</p>
<ul>
<li>FedCM binding of OIDC: <a href="https://bitbucket.org/openid/connect/issues/2179/fedcm-binding-of-oidc">https://bitbucket.org/openid/connect/issues/2179/fedcm-binding-of-oidc</a>
<ul>
<li>Some people have volunteered to work on this.</li>
<li>Mozilla announced in the W3C call yesterday that they are no longer actively working on FedCM support. Apple has not publicly done any work on FedCM. This leaves Chrome as the only active implementation.</li>
</ul>
</li>
<li>Clarification on additional metadata: <a href="https://bitbucket.org/openid/connect/pull-requests/750">https://bitbucket.org/openid/connect/pull-requests/750</a>
<ul>
<li>This will be merged.</li>
</ul>
</li>
<li>id token claims should not be null: <a href="https://bitbucket.org/openid/connect/pull-requests/751">https://bitbucket.org/openid/connect/pull-requests/751</a>
<ul>
<li>Remaining issues were resolved at the meeting and this will be merged.</li>
</ul>
</li>
<li>All open PRs have been resolved.</li>
</ul>
<p>Discussion of OpenID Connect Enterprise Extensions:</p>
<ul>
<li>The claim <code>aud_sub</code> represents the identifier that the RP uses for an account.</li>
<li>In OpenID Provider Commands, the <code>aud_sub</code> can be sent from the RP to the OP to “transfer” an account from the RP to the OP using the <code>manage</code> command (and the other way around).</li>
<li>Use case: user initially created a “standalone” account without SSO, and later this needs to be transferred into the SSO system.</li>
<li>In OpenID Provider Commands, the RP can use the <code>managed_by</code> claim to tell the OP who manages an account.</li>
<li>Question: does <code>managed_by</code> mean identity lifecycle management or session management or both? This should be aligned with IPSIE terms.</li>
<li>The RP can state <code>aud_sub_required</code> in its metadata to state that they require support for <code>aud_sub</code>.</li>
<li>Question: is this similar for SCIM? Yes, one way to think about Provider Commands is SCIM for OIDC.</li>
<li>Question: how do you establish trust that the IdP is authoritative for the user account? This is part of the OpenID Provider Commands setup. The trust should be specific to a tenant within the OP.</li>
<li>Question: how is the scope of authorization for account transfers handled? This is out of scope for the spec and must be handled between the RP and the user. Guidance around this should be put into the security and/or privacy considerations in the spec.</li>
<li>No decisions were made for now.</li>
<li>Dick will make some changes to the draft to make it easier to get an overview.</li>
</ul>
<p>Discussion of new proposed spec OpenID Connect Key Binding:</p>
<ul>
<li>Mechanism to bind a key to an ID token.</li>
<li>Builds on DPoP by adding a new scope <code>dpop</code> and including the <code>dpop_jkt</code> in the auth request. Then in the token request, add DPoP header with <code>code</code> as the nonce for DPoP. Token response then contains <code>cnf</code> claim with the public key from the DPoP header.</li>
<li>The new element is putting the <code>dpop</code> public key in the ID token.</li>
<li>Use case: for SSH, look at claims in the ID token to determine access. Binding the token to a key prevents session replay.</li>
<li>Variations on this idea are already in use for many use cases.</li>
<li>Comment: there is ongoing work on an extension to WebAuthn to allow signing of arbitrary data, and this may be relevant. See <a href="https://github.com/w3c/webauthn/pull/2078">https://github.com/w3c/webauthn/pull/2078</a></li>
<li>Comment: you could put <code>c_hash</code> into the token to bind the key instead of using DPoP nonce.</li>
<li>Comment: should ID tokens be used for “just anything”? Or should we be careful about what we use them for? Ethan’s point of view: the cat is already out of the box.</li>
<li>We will make more time for further discussion of this topic next week since the meeting is running over time.</li>
</ul></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br></div></div></div></div>