<div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(59,59,59);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;line-height:18px;white-space:pre"><div><span style="color:rgb(128,0,0);font-weight:bold"># OpenID Connect 2024-03-07</span></div><br><div><span style="color:rgb(128,0,0);font-weight:bold">## Agenda</span></div><br><div><span style="color:rgb(4,81,165)">-</span> IETF 119</div><div><span style="color:rgb(4,81,165)">-</span> PRs and Issues</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">## Attendees</span></div><br><div><span style="color:rgb(4,81,165)">-</span> Mike Jones</div><div><span style="color:rgb(4,81,165)">-</span> George Fletcher</div><div><span style="color:rgb(4,81,165)">-</span> Tom Jones</div><div><span style="color:rgb(4,81,165)">-</span> Tim Cappalli</div><div><span style="color:rgb(4,81,165)">-</span> Filip Skokan</div><div><span style="color:rgb(4,81,165)">-</span> Bjorn Hjelm</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">## Notes</span></div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### IETF 119</span></div><br><div>{Mike} IETF in a few weeks. Anyone going?</div><br><div>{George} I'll be there</div><br><div>{Mike} fully specified algos draft in JOSE, issue with 25519 and ?</div><div>    question around ECDH key agreement: reason: ephemeral key passed as a param which has an algo</div><div>    welcome anyone to weigh in on the email thread before IETF</div><div>    any other specs to pay attention to?</div><br><div>{Joseph} goal to get agreement on the client attestation spec</div><br><div>{Mike} Tobias posted new drafts of status list</div><br><div>{George}</div><div>    transaction tokens: bunch of updates to align with token exchange, added some capabilities for pathing(?)</div><div>    first party apps: few tweaks, will ask for WG adoption and take temp of room</div><div>    identity chaining: some updates, removed "don't use requested token type".</div><div>        what does it do? allows you to cross authorization trust domains. similar to native SSO spec, provide a more structured way for things that everyone is already doing</div><div>        new name: Cross-Domain Authorization or something similar</div><div>        draft: <<span style="text-decoration-line:underline"><a href="https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/">https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/</a></span>></div><br><div>(later in meeting)</div><div>{Tom} Sounds like "Token Translation" in ADFS. Is there something different here?</div><br><div>{George} Native SSO provides a way to give a device instance a token (device secret) that allows you to transfer auth state between native apps on the same device. No cookie equivalent across native apps.</div><br><div>{Tom} Worried about user experience if it looks differently across devices</div><br><div>{George} Don't know if that's true as the apps need to be written by the same company</div><br><div>{Tom} Won't help with wallets that want to share the same request</div><br><div>{George} Could use Joseph's work on app to app</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">### PRs & Issues</span></div><br><div><span style="color:rgb(128,0,0);font-weight:bold">#### Connect: PR 702</span></div><br><div><<span style="text-decoration-line:underline"><a href="https://bitbucket.org/openid/connect/pull-requests/702">https://bitbucket.org/openid/connect/pull-requests/702</a></span>></div><br><div>{Mike} plenty of reviews and approvals. Good to merge?</div><br><div>No other feedback. Merged.</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">#### Federation: Issue 2120</span></div><br><div><<span style="text-decoration-line:underline"><a href="https://bitbucket.org/openid/connect/issues/2120/federation-editorial-make-distinction">https://bitbucket.org/openid/connect/issues/2120/federation-editorial-make-distinction</a></span>></div><br><div>{Mike} Backstory: in federation spec, terms <span style="color:rgb(128,0,0)">`subordinate`</span> and <span style="color:rgb(128,0,0)">`superior`</span> entry are used, referring to stuff above or below you in a trust heirarchy</div><div>    Problem is sometimes you're referring to the thing immediately below you and other times anything below you.</div><div>    spec not currently precise about what is meant</div><div>    Please review the 4 proposed definitions</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">#### Federation: Issue 2127</span></div><br><div><<span style="text-decoration-line:underline"><a href="https://bitbucket.org/openid/connect/issues/2127/federation-editorial-improve-51-entity">https://bitbucket.org/openid/connect/issues/2127/federation-editorial-improve-51-entity</a></span>></div><br><div>{Mike} doesn't change the meaning of the spec, just a clarification. reviews requested.</div><br><div><span style="color:rgb(128,0,0);font-weight:bold">#### Other</span></div><br><div><<span style="text-decoration-line:underline"><a href="https://openid.net/specs/openid-connect-native-sso-1_0-ID1.html">https://openid.net/specs/openid-connect-native-sso-1_0-ID1.html</a></span>></div><br><div>{George} added metadata for native SSO supported, could publish 06 or 07. will ask the list.</div><br></div></div></div></div></div>