[Openid-specs-ab] Meeting notes: May 18, 2023

Thu May 18 17:29:59 UTC 2023

Hi George,

I'd like to enrigh the details regarding the element below:

> GAIN POC pilots are using Federation spec but getting the entity metadata
via other methods

I confirm that in the current GAIN PoC network, the metadata is taken from
the Federation Trust Chain, published in the leaf Entity Configuration, and
derived using the metadata policy available in the Entity Statements along
the chain.
Then I can change my Leaf Entity Configuration and request an Authz to
another GAIN PoC participant and this latter refresh the metadata during
the update of the trust chain related to my entity.

So the current behaviour for fetching reliable metadata in GAIN PoC is the
one currently specified in OpenID Connect Federation 1.0, the PR has
aligned the normative language in relation to the PR below, without
introducing any breaking changes, since OpenID Connect Federation allows to
attests keys and trust marks even if no metadata is suitable for the
participants or the metadata are taken with different ways and out of the
rules defined in the specs, if required by a specific implementation
profile.
https://bitbucket.org/openid/connect/pull-requests/448

thank you for the notes and for having asked me to add any further details
as the one here,
best

Il giorno gio 18 mag 2023 alle ore 17:20 George Fletcher via
Openid-specs-ab <openid-specs-ab at lists.openid.net> ha scritto:

> Attendees:
> - Mike Jones
> - Brian Campbell
> - Joseph Heenan
> - Sudesha Shetty
> - Takahiko Kawasaki
> - Giuseppe De Marco
> - Bjorn Hjelm
> - David Luna
>
> Introductions
> * Sudesha - first time, working on implementing OIDC4VCI, OIDC4VP
>
> Agenda (in no particular order:)
>
>    - Verifiable Presentations over BLE
>    - DID method - Giuseppe
>    - PRs for OpenID Connect
>    - Native SSO for Mobile Apps
>    - MODERNA - Mobile Operator Space [CIBA]
>
>
> Verifiable Presentations over BLE - update
>
>    - The draft has been adopted by the working group
>    - Mike will publish the initial draft today and add it to the list of
>    working documents
>
>
> Security analysis of OpenID 4 Verifiable Credentials specifications
>
>    - Work by Daniel Fett (PR 468)
>    - Not yet adopted by the working group
>    - Requesting review of the PR
>    - After addressing the review comments will request a call for adoption
>
>
> Verifiable Credentials working group
>
>    - Still under consideration
>    - Similar to what eKYC did a few years ago
>    - Need to get the drafts approved as an implementers draft to make IPR
>    issues simpler
>    - To support the creation of the new working group, this working group
>    needs to move all the related drafts to implementers draft
>
>
> DID Method - Giuseppe
>
>    - Looking at how allow OpenID Connect Federation and DID method
>    resolution to work together well
>    - Issue:
>    https://github.com/vcstuff/draft-terbu-sd-jwt-vc/issues/41#issuecomment-1546743042
>       - did:openid-trustchain:...
>       - did:openid:example.it:oidc:rp[...]
>    - Should the DID methods be registered with W3C?
>    - Should the descriptions be added to the OpenID Connect Federation
>    spec?
>    - Who would use it?
>    - Issue is that the federation spec currently requires an HTTPS URL
>       - this doesn't allow for how to determine the trust chain
>       - other issues?
>    - The DID method resolution makes the trust determination explicit
>    - Request raised by a community of developers more involved in the
>    issuer-holder-verifier model wanting a DID mechanism for federation
>    - Who would use it and why?
>       - offline flows - put the full trust chain in the DID [static]
>       - what to do about revocation of the "static" trust chain?
>          - in Italy the trust chain expires in 24hrs
>          - expiry time included in the trust-chain object within the DID
>       - Why does the developer community want a DID?
>          - It fits the model in which the developers are working
>          - It hints at the trust resolution method. Not an issue for the
>          Italy implementation.
>          - In other contexts, the trust resolution is less defined and
>          the DID method provides that clarity
>       - Not a critical item for today - Giuseppe
>    - DIDs are about proving possession of a key - Mike
>       - in this context what key is being attested to and provable?
>       - to prove control of the DID you prove control of a specific key?
>       - Mike
>          - could identify the "kid" and then prove control of that key -
>          Giuseppe
>          - for the did:openid:... the key-value is after the #
>       - DIDs need to resolve to a DID Method document - Takahiko
>       - There are some other DID methods that don't today require
>       resolution to a DID method -- did:jwk, did:x509, did:key - Giuseppe
>    - DID method 'openid' is a bit too generic - Takahiko
>       - yes, this is probably too generic - Giuseppe
>       - could add a suffix to help with determining resolution
>       - openid configuration, jot issuer, could also be areas that could
>       be involved in the resolution discussion - Takahiko
>          - Not sure of the value of a new .well-known for jot-issuer
>       - DID trust-chain may be more interesting for the offline use case
>    - Giuseppe
>       - Trust chain header parameter will work in the same way - Takahiko
>       - The trust chain header only works in HTTPS bases solutions and
>       the DID method could potentially work in other use cases - Giuseppe
>    - Additional related document:
>    https://docs.google.com/document/d/1Dk_8UmytCI4VhCx5VMnXmEzdXRvgJozGeq1GNHZOQik/edit
>
>
> Pull Requests
>
>    - 510 - [Federation] introductory text, metadata section, editorials
>       - a couple of normative changes
>       - there is an appendix describing other ways to define entity
>       metadata
>          - this requires a change from MUST to SHOULD
>          - the appendix text is still in it's own PR
>       - GAIN POC pilots are using Federation spec but getting the entity
>       metadata via other methods
>       - Other use case where the System of Record is in a DB but the
>       publishing mechanisms still puts the entity metadata into the published
>       documents
>       - impacts to interop by moving from MUST to SHOULD - however, this
>       choice has already been deployed in the real world
>       - merge of PR approved - Giuseppe
>    - 518 - Please review!!
>       - Takahiko has reviewed and approves the merge
>
> Agenda items not discussed:
>
>    - Native SSO for Mobile Apps
>    - MODERNA - Mobile Operator Space [CIBA]
>
>
> ------------------------------
>
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.
>
>
>
>
> _______________________________________________
> 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/20230518/35af5903/attachment.html>