[Openid-specs-digital-credentials-protocols] OIDF DCP WG meeting notes for 2024-07-25
Kristina Yasuda
yasudakristina at gmail.com
Mon Jul 29 19:07:40 UTC 2024
Thank you for the feedback, Giuseppe.
The proposal of removing client_id_scheme comes hand-in-hand
with namespacing client_id for security/resolving the client_id purposes.
I do not see the benefit of just removing client_id_scheme, without
namespacing client_id.
Best,
Kristina
On Mon, Jul 29, 2024 at 6:41 AM Giuseppe De Marco via
Openid-specs-digital-credentials-protocols <
openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
> 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
>>
> --
> 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/d6e546c1/attachment-0001.html>
More information about the Openid-specs-digital-credentials-protocols
mailing list