<div dir="ltr"><div><div><div><div># Attendees<br>
<br>
Brian Campbell<br>
Giuseppe De Marco<br>
Joseph Heenan<br>Andrii Deinega<br>
Michael Jones<br></div>Roland Hedberg<br></div>Tom Jones<br></div>George Fletcher<br></div>(sorry I missed some, I don't remember the name ... my bad, please add anyone I miss)<br><br>Mike: Agenda of two days ago for the proposed topics<br><br>Events:<br><br> - reports from OAS WS in london:<br>   - Roland's impressions:<br>     - many presentations on security evaluation of the OAuth2 and its extensions<br>     - many discussion about OIDC Federation 1.0<br>   - Mike:<br>     - they didn't have trust anchors but several trust chains without knowing how to validate these<br>   - Roland:<br>     - Other uses cases using Proxies that handles registrations and trust evaluation for its registered entities<br><br>Mike: Federation is mature enough but it is important to make it a standard for promoting implementations and adoptions<br><br> - Actionable things for IIW:<br>   - Andrii: pleased to be there and meet people<br><br>Mike: New WG started last week, Digital Credentials Protocols WG, with the scope to continuing working on the OpenID4VC specs and the ecosystem around it. We will share the SIOP Special Call timeslot with DCP for the time being.<br><br>We did the github migrations for these specs at <a href="https://github.com/openid/">https://github.com/openid/</a>, the migrations of the issues was automatic and really impressive. However the PR required to be migrated by hands.<br><br>Federation specs:<br><br>We can migrate oidc federation as well to github when we'll merge the pending three PRs we still have in bitbucket.<br><br>- agreement for the implmentors draft, to be published very soon<br><br>- we should discuss what PR we want to be in the impl draft looking for getting these merged today<br>- PR <a href="https://bitbucket.org/openid/connect/pull-requests/609">https://bitbucket.org/openid/connect/pull-requests/609</a>:<br>  - it reworks the explicit registration text, to be able to address issues and simplify then implementations<br>  - 4 approvals, then MERGED.<br><br>- PR <a href="https://bitbucket.org/openid/connect/pull-requests/613">https://bitbucket.org/openid/connect/pull-requests/613</a><br>  - it largely better specifies the federation endpoints urls, saying what can be included within the urls<br>  - merely editorial that clarifies things that are already true and implictly known<br>  - MERGED<br><br>- PR <a href="https://bitbucket.org/openid/connect/pull-requests/607">https://bitbucket.org/openid/connect/pull-requests/607</a><br>  - it gives more description about how the policies interacts each other<br>  - in particular the language about the operator parameter `one_of`<br>  - to be merged later since it has merge conflicts to be resolved by Vladimir<br><br>- PR <a href="https://bitbucket.org/openid/connect/pull-requests/589">https://bitbucket.org/openid/connect/pull-requests/589</a><br>  - Metadata coming from locations that are not Entity Statements<br>  - Torsten and Kristina called for review in response to their claims about the discussion on the trust and security models<br>  - there's a division within our community on this PR since there are ppl in favor of that and others not<br>  - George Fletcher:<br>    - is there any way to allow in federation to fetch metadata from external locations, I heard ppl that arguing on that, it seems that the agreement is not explicit yet<br>    - Mike: it would be a mess if several entities gives the metadata in a place and other of the same type and for the same purpose in another place.<br>    - George: the Federation approach is quite clear<br>    - Roland: explains the rationale about the requirement of fetching verifiable metadata<br>    - Mike: we have text in the PR about how this is addressed that's an implementation choice<br>    - George: concerns about the possibility to give a way to publish metadata in multiple ways. <br>    - Mike: this help the infrastructure to be migrated from legacy trust models to federation<br>    - Roland: to be part of a federation all the entities must publish their entity configurations to be attestable under one or more Trust Anchors.<br>    - Tom Jones: There seems to be some assumption that federation spec only works for on-line cases.  Is that the case?<br>    - Giuseppe: Federation can work with static trust_chain in carried within the JWS header parameter, this allows the offline flows<br>    - Tom: concerns about how to apply the trust model with federation with wallet 2 wallet intaractions, we need to talk about on that when the flow is wallet 2 wallet flows.<br><div>    - Giuseppe: the Trust Model for these kind of interaction relies on the Wallet Instance Attestation, where the trust chain related to the Wallet Provider attests the reliability of the wallet instance</div><div>   - Tom: more discussion is required to get all the required clarifications<br></div><div>   - Giuseppe: Agreed<br></div><div><br></div>Issues:<br> - <a href="https://bitbucket.org/openid/connect/issues/2060/federation-515-applying-policies-specify">https://bitbucket.org/openid/connect/issues/2060/federation-515-applying-policies-specify</a><br>   - assinged to Vladimir<br> - <a href="https://bitbucket.org/openid/connect/issues/2002/federation-please-add-a-visual-diagram">https://bitbucket.org/openid/connect/issues/2002/federation-please-add-a-visual-diagram</a><br>   - Kristina comments will be committed, assigned to Giuseppe</div>