[Openid-specs-ab] OpenID AB/C WG Call Meeting Notes 2023-Sep-07

[Naohiro Fujie]

It was me. I started to catch up with the OIDC Federation spec for my
customer in Japan.

> (sorry I missed some, I don't remember the name ... my bad, please add
anyone I miss)

Naohiro

2023年9月8日(金) 1:16 Giuseppe De Marco via Openid-specs-ab <
openid-specs-ab at lists.openid.net>:

> # Attendees
>
> Brian Campbell
> Giuseppe De Marco
> Joseph Heenan
> Andrii Deinega
> Michael Jones
> Roland Hedberg
> Tom Jones
> George Fletcher
> (sorry I missed some, I don't remember the name ... my bad, please add
> anyone I miss)
>
> Mike: Agenda of two days ago for the proposed topics
>
> Events:
>
>  - reports from OAS WS in london:
>    - Roland's impressions:
>      - many presentations on security evaluation of the OAuth2 and its
> extensions
>      - many discussion about OIDC Federation 1.0
>    - Mike:
>      - they didn't have trust anchors but several trust chains without
> knowing how to validate these
>    - Roland:
>      - Other uses cases using Proxies that handles registrations and trust
> evaluation for its registered entities
>
> Mike: Federation is mature enough but it is important to make it a
> standard for promoting implementations and adoptions
>
>  - Actionable things for IIW:
>    - Andrii: pleased to be there and meet people
>
> 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.
>
> We did the github migrations for these specs at https://github.com/openid/,
> the migrations of the issues was automatic and really impressive. However
> the PR required to be migrated by hands.
>
> Federation specs:
>
> We can migrate oidc federation as well to github when we'll merge the
> pending three PRs we still have in bitbucket.
>
> - agreement for the implmentors draft, to be published very soon
>
> - we should discuss what PR we want to be in the impl draft looking for
> getting these merged today
> - PR https://bitbucket.org/openid/connect/pull-requests/609:
>   - it reworks the explicit registration text, to be able to address
> issues and simplify then implementations
>   - 4 approvals, then MERGED.
>
> - PR https://bitbucket.org/openid/connect/pull-requests/613
>   - it largely better specifies the federation endpoints urls, saying what
> can be included within the urls
>   - merely editorial that clarifies things that are already true and
> implictly known
>   - MERGED
>
> - PR https://bitbucket.org/openid/connect/pull-requests/607
>   - it gives more description about how the policies interacts each other
>   - in particular the language about the operator parameter `one_of`
>   - to be merged later since it has merge conflicts to be resolved by
> Vladimir
>
> - PR https://bitbucket.org/openid/connect/pull-requests/589
>   - Metadata coming from locations that are not Entity Statements
>   - Torsten and Kristina called for review in response to their claims
> about the discussion on the trust and security models
>   - there's a division within our community on this PR since there are ppl
> in favor of that and others not
>   - George Fletcher:
>     - 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
>     - 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.
>     - George: the Federation approach is quite clear
>     - Roland: explains the rationale about the requirement of fetching
> verifiable metadata
>     - Mike: we have text in the PR about how this is addressed that's an
> implementation choice
>     - George: concerns about the possibility to give a way to publish
> metadata in multiple ways.
>     - Mike: this help the infrastructure to be migrated from legacy trust
> models to federation
>     - Roland: to be part of a federation all the entities must publish
> their entity configurations to be attestable under one or more Trust
> Anchors.
>     - Tom Jones: There seems to be some assumption that federation spec
> only works for on-line cases.  Is that the case?
>     - Giuseppe: Federation can work with static trust_chain in carried
> within the JWS header parameter, this allows the offline flows
>     - 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.
>     - 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
>    - Tom: more discussion is required to get all the required
> clarifications
>    - Giuseppe: Agreed
>
> Issues:
>  -
> https://bitbucket.org/openid/connect/issues/2060/federation-515-applying-policies-specify
>    - assinged to Vladimir
>  -
> https://bitbucket.org/openid/connect/issues/2002/federation-please-add-a-visual-diagram
>    - Kristina comments will be committed, assigned to Giuseppe
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230908/7d795f7f/attachment.html>