[Openid-specs-digital-credentials-protocols] OIDF DCP WG meeting notes for 2024-07-25
Giuseppe De Marco
demarcog83 at gmail.com
Tue Jul 30 05:06:30 UTC 2024
Federation Wallet alone doesn't mean nothing to me
The specification name is openid federation wallet architectures 1.0
It contains all about the use of openid federation in the wallet ecosystem
with further metadata enforcements as well
Il mar 30 lug 2024, 01:52 Tom Jones via
Openid-specs-digital-credentials-protocols <
openid-specs-digital-credentials-protocols at lists.openid.net> ha scritto:
> Giuseppe - could i ask for clarification about what a "federation wallet"
> means?
> Thanks
> ..tom
>
>
> 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
>>
> --
> 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/20240730/137d23b1/attachment-0001.html>
More information about the Openid-specs-digital-credentials-protocols
mailing list