[Openid-specs-digital-credentials-protocols] OIDF DCP WG meeting notes for 2024-07-25

[Giuseppe De Marco]

Hi,

than kyou for the notes. Regarding the removal of client_id_scheme

 OID4VP/Issue 124: client_id_scheme security considerations
     ...
    Torsten highlights the change is needed to OpenID Federation wrt the
entity identifier. That change is either an extra param (client_id_scheme)
or namespaced entity identifier
    John: should be discussed with people who already use Federation (e.g.
Italian Wallet)
    Torsten: Agrees
    Daniel: This is a problem for every server that uses client_ids from
multiple sources, so more universal than OpenID Federation

I agree with Daniel, it is more universal than OpenID Federation.

Regarding the removal of client_id_scheme, I don't see any problem with the
current OpenID federation wallet implementation, therefore client_id_Scheme
can be removed without compromising current implementations (that uses
client_id in the form of https url).

Regarding the use of namespaces: This was not considered before, so at this
stage, it needs to be addressed and defined within the specifications.
Technically, handling namespaces is feasible. However, I want to emphasize
that using namespaces seems to address a problem in an unconventional way
by inflating the client ID value.

A client ID is meant to be a client identifier, while the purpose of a
namespace is to provide guidance on how to resolve the client identifier.
These are two different concepts. Using unique client identifiers can scale
across multiple trust evaluation mechanisms, whereas embedding a trust
resolution method within a unique client ID forces an entity to not join
multiple infrastructures of trust. This approach does not scale well.
I would prefer to leave client_id as it is, without namespaces. I will
follow the discussion to share further feedback.

I hope this helps, thank you for sharing

thx!

Il giorno lun 29 lug 2024 alle ore 14:35 Jan Vereecken via
Openid-specs-digital-credentials-protocols <
openid-specs-digital-credentials-protocols at lists.openid.net> ha scritto:

> Hello All,
>
> Please find the notes below of the DCP WG call of July 25th.
>
> Rgs,
> Jan
>
>    - Participants
>       - Torsten Loddersted
>       - Joseph Heenan
>       - Marijn Haring
>       - Kristina Yusuda
>       - Andreea Prian
>       - Lukasz Jaromin
>       - Steve Venema
>       - Paul Bastian
>       - Andy Lim
>       - Juba Saadi
>       - Oliver Terbu
>       - Andreea Prian
>       - Brian Campbell
>       - Hicham Lozi
>       - Ryan Galluzzo
>       - John Bradley
>       - Rajvardhan Deshmukh
>       - Bjorn Helm
>       - Gareth Oliver
>       - Jian Liu
>    - Agenda
>       - Wallet Attestations / Key Attestations
>       - Removal CWT proof type
>       - OID4VCI/PR 220: Introduce Query Language
>       - Client id scheme security
>       - Adding transaction data
>    - External Events
>       - Some events around IIW, see mailing list for more details
>    - OID4VCI/Issue 355: Wallet Attestations / Key Attestations
>       - Kristina: Recap of what was discussed in previous call. Details
>       in the issue
>       - Torsten: Has two questions. First one: highlights comment from
>       Andrea regarding issuer metadata needed for wallet to understand which
>       attestation is needed for a key
>       - Andrea highlights here last comment in the ticket talking about
>       PoP and context that can be useful for the issuer as well as its importance
>       for authentication (e.g. PID provider might have more strict requirements).
>       - Torsten: party sending the requests is who decides what is
>       allowed. Suggests to extend the metadata to convey the requirements
>       regarding keys
>       - Andrea: Issuer cannot always specify what means of authn is
>       supports as it can also depend on the WSCD supported by the device the user
>       has. Shou
>       - Torsten: Of the opinion that issuer should provide as much
>       information to wallet as possible
>       - Paul: Agrees with Torsten. Avoid that after providing key
>       attestation the issuer says that it can't continue.
>       - Agree to wait for Paul's PR to discuss this further
>       - Torsten: goes to second question brings up the topic of wallet
>       authentication
>       - Andrea highlight that each member state has a different
>       interpretation of LoA high for example.
>       - Torsten agrees
>       - John: Wallet to decide which trust mark to provide based on the
>       information the issuer provides. Potentially also useful for "Wallet
>       Selector" to lead the user to a wallet that is likely to support it.
>       - Agree to wait for Paul's PR
>    - OID4VCI/Issue 320: Remove CWT proof type
>       - Kristina introduces the issue. Email to mailing list asking for
>       objections to remove it. Asks the working group. No objections.
>       - Brian will create a PR to remove it.
>    - OID4VP/Issue 124: client_id_scheme security considerations
>       - Daniel introduces the issue. The summary is that client_id_scheme
>       must be present whenever client_id scheme is present as the client_id
>       - Kristina asks WG if anyone is opposed to prefixing the client_id
>       with the client_id_scheme
>       - Oliver is opposed to namespacing, but has no concrete counter
>       proposal
>       - Torsten and Kristina bring up that it is waiting for Tobias to
>       make a suggestion and the ticket is already open for more than 3 months
>       - Oliver wants to circle back and suggest a proposal on Aug 6th
>       - Torsten highlights the change is needed to OpenID Federation wrt
>       the entity identifier. That change is either an extra param
>       (client_id_scheme) or namespaced entity identifier
>       - John: should be discussed with people who already use Federation
>       (e.g. Italian Wallet)
>       - Torsten: Agrees
>       - Daniel: This is a problem for every server that uses client_ids
>       from multiple sources, so more universal than OpenID Federation
>       - Joseph: If it only applies to wallets, this should be stated
>       clearly
>       - Kristina: This is more universal problem
>       - Lukasz: How can we avoid conflicts with other potential
>       interpretations of client_id
>       - John: We can't. Difficult to understand
>       - Kristina: Asks for remarks raised during the meeting to be
>       documented in the issue
>    - OID4VP/PR220: Introduce new query language
>       - Daniel introduces the PR. Ready for reviews.
>    - OID4VP/PR197: Add transaction_data
>       - Kristina introduces the PR. Ready for reviews.
>       - LSPs in EU are actively asking for this as they rely on this
>       mechanism.
>    - Actions
>       - Oliver will propose alternative solution than the one proposed
>       currently in OID4VP/Issue 124 by Aug 6th
>
>
> --
> Openid-specs-digital-credentials-protocols mailing list
> Openid-specs-digital-credentials-protocols at lists.openid.net
>
> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240729/383c5fa6/attachment.html>