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

[Giuseppe De Marco]

# 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230907/f5e554f7/attachment.html>