[Openid-specs-digital-credentials-protocols] WGLC for OpenID for Verifiable Presentations Final
steffen schwalm
schwalm.steffen at googlemail.com
Thu Apr 24 14:59:51 UTC 2025
Hi Mirko,
if you make clear in the draft, that the option on EAA is not in scope of
eIDAS Ecosystem I`m fine as this option is acc. to the current regulation
illegal..
I also agree to Tom that claiming no trust responsibility whatsoever for
the OID4VP protocol is not possible.
I upheld my opposition until a clarification. I remain at your disposal for
short alignment.
Best
Steffen
On Thu, Apr 24, 2025 at 9:13 AM Mirko Mollik <mirko.mollik at eudi.sprind.org>
wrote:
> Hey Steffen,
>
> Thanks for your insights. It seems we both have another understanding of
> what should be included in the certificates or what needs to be attached
> (either putting the „doctor" claim in the x509 or an EAA). Luckily for us
> OID4VP is supporting both :)
>
> Now I am sure we can both agree (and hopefully also Tom) that OID4VP in
> its current state is giving the full capability for passing the information
> the one way or the other to support strong RP authentication and
> authorization. So this problem of „trust and authorization“ can be handled
> on another channel and should not block the public review process.
>
> Cheers
> -
> Mirko Mollik
>
> Identity Architect (EUDI-Wallet-Projekt) mirko.mollik at eudi.sprind.org
>
> SPRIND GmbH
>
> BUNDESAGENTUR FÜR SPRUNGINNOVATIONEN
> FEDERAL AGENCY FOR DISRUPTIVE INNOVATION
> Lagerhofstraße 4, 04103 Leipzig
>
> www.sprind.org
>
> Geschäftsführung: Berit Dannenberg, Rafael Laguna de la Vera
> Vorsitzender des Aufsichtsrats: Dr.-Ing. E. h. Peter Leibinger
> Amtsgericht Leipzig – HRB 36977
> USt-ID DE328253854
> Disclaimer
>
> Am 23.04.2025 um 21:16 schrieb steffen schwalm <
> schwalm.steffen at googlemail.com>:
>
> And as the access certificate needs to be one used for Electronic
> signatures ach to law the good old ETSI EN 319 411 already applcable as a)
> not exclusively bound to TSP and useable worldwide & b) already contains
> option to put authorization as "vank", "doctor" in certificate.
>
> No need for additional attestation.
>
> Beside this Mirko; Your idea would mean that RP goes to ecosystem Party
> e.g. medical Association to get attestation "doctor", something the
> registrar proofs without need of EAA.
> Practically this means any ecosystems authority issueing such an
> attestation becomes TSP acc Art. 3 Nr. 16 eIDAS.
>
> So as consultant I have to state: Thanks for the great sales idea. As
> standardization expert I have to state: reuse ETSI EN 319 411, put value in
> access certificate - ready.
>
> And be legally compliant.
>
> My Boss would like you
>
> Best
> Steffen
>
> steffen schwalm <schwalm.steffen at googlemail.com> schrieb am Mi., 23. Apr.
> 2025, 19:10:
>
>> HI Mirko,
>>
>> additionally explicitly for your the legal sources:
>>
>>
>> - Art 5 "A wallet-relying party shall provide to the relevant
>> register of the Member State where it is established at least the
>> information set out in Annex I. The wallet-relying party shall ensure that
>> all information provided is accurate at the time of registration and when
>> the information is update"
>> - Annex 1 The name of the wallet-relying party as stated in an
>> official record together with identification data of that official record.
>> 2. Where applicable, one or more identifiers of the wallet-relying
>> party, as stated in an official record together with identification data of
>> that official record, expressed as:
>> (a) an Economic Operators Registration and Identification (EORI)
>> number as referred to in Commission Implementing Regulation (EU) No
>> 1352/20131;
>> (b) the registration number as registered in a national business
>> register;
>> (c) a Legal Entity Identifier (LEI) as referred to in Commission
>> Implementing Regulation (EU) No 2022/18602;
>> (d) a VAT registration number;
>> (e) an excise number as specified in Article 2(12) of Council
>> Regulation (EC) No 389/20123;
>> (f) a tax reference number;
>> (g) a European Unique Identifier (EUID) as referred to in
>> Commission Implementing Regulation (EU) 2020/22
>> - Art. 6 requries that only Art. 5 fulfilled registration RP can start
>> - REgistration essential for Access Certificate see Art. 7
>>
>> your claim "Also your second argument „the registrar knows this“ is
>> legally wrong - as the Registrar has to know if the bank is bank otherwise
>> no registration, no access certificate. As this property is exactly the one
>> needed to proof if certain RP authorized to get certain PID/(Q)EAA - the
>> registrar can add it to the access certificate so that the Root of Trust
>> Approach easily works.
>>
>> Strongly recommend you proof your approach against the law through a
>> second dedicated lawyer. If it´s possible fine. Best solution would be to
>> aim for change of IA on Art. 5b so that requirement that access certificate
>> is x509 will be changed that it could be also EAA. Would avoid the
>> technical issue of your approach that access certficate = x509 while the
>> evidence for authorization (bank) is attestation.
>>
>> Give you the legal session also for free as the legal education of
>> SPRIND is close to my heart. if you don`t aim for eIDAS please mention it
>> in scope.
>>
>> Best
>> Steffen
>>
>>
>>
>>
>> On Wed, Apr 23, 2025 at 6:34 PM steffen schwalm <
>> schwalm.steffen at googlemail.com> wrote:
>>
>>> Dear Mirko,
>>>
>>> thanks a lot for your mail,. You seemingly forget the information spread
>>> by the chairs so especially Torsten & Kristina but also by you that OIDF
>>> works on standards to be used within the eiDAS ecosystem and with this aim
>>> is according to its own statements (see chairs) in close collaboration with
>>> the European Commission.
>>>
>>> Regarding ETSI: You may forget that its working worldwide as you can see
>>> on the website: https://www.etsi.org/about. Especially the ETSI EN on
>>> signatures and certificates are used worldwide.
>>>
>>> Please do not mix up standardization organizations and regulation. The
>>> regulation is exactly what we focus on here in the discussion.
>>>
>>> legally and practically you are wrong:
>>>
>>> 1. the IA on Art. 5b eIDAS defines that only following options for
>>> disclosur policies on RP Access certificates possible: no one, allow list,
>>> Root of Trust
>>>
>>>
>>> - As it´s a final list, there`s no option for your attestation based
>>> approach in Europe
>>> - So great that you checked your idea with technical experts - but
>>> strongly recommend that you proof it legally in case your idea shall work
>>> in Europ
>>>
>>> 2. According to Art. 5b eIDAS as well as its IA the Relying Party needs
>>> to identify at Registrar. means the Registrar knows if it´s a bank, doctor
>>> or SPRIND. So you are legally wrong again. As the Registrar knows and gets
>>> the information about kind of Relying Party, the registrar can out this
>>> information in the RP Access Certificate. As IA on Art. 5b does not forbid
>>> this (in comparison to your idea) - it´s no issue
>>> As the RP already needs to use the Access Certificate your approach only
>>> creates additional complexity within the EUDI/eIDAS ecosystem as RP needs
>>> Access Certificate (which has to be x509 by law!) + attestations
>>>
>>> However, if OID4VP and your preferred approach on Relying Party
>>> Authorization is not aimed for eIDAS ecosystem I strongly recommend to
>>> mention this explicitly in the scope of the standard - this would help
>>> users & implementers to assess its applicability for the EUDI Wallet.
>>>
>>> 3. Your claim "And this is also not the way the European Commission
>>> wants to go via forcing QTSPs for everything! Member States that want to
>>> use QTSPs can do so, others can avoid it" is misleading. Nobody spoke about
>>> using QTSP for this . only to reuse a European Standard for the Access
>>> certificate. Maybe you read my mail again
>>>
>>> Recommend you go deeper in the subject how values like "Bank", "doctor"
>>> or similar can be added to x509 and easily proven. We already do this with
>>> x509 worldwide without the need of an attestation.
>>>
>>> So you are technically wrong again and mix up the subject.
>>>
>>> ;Long story short: Within the eIDAS Ecosystem your approach only leads
>>> to additional effort and is legally impossible - better unlawful or
>>> illegal. If OIDF aims to use OID4VP in its current version for eiDAS
>>> Ecosystem strongly recommend to go the step to proof the legal
>>> applicability to eIDAS 2.0.
>>>
>>> I offer to explain it to you in personal meeting.
>>>
>>> BTW: I never mentioned that you agreed to my claims but that we
>>> discussed it ;-)
>>>
>>> As the approach is illegal I hold up my opposition to move current draft
>>> to public review.
>>>
>>> PS: Recommend you read and understand first before you argue and assume
>>> about subjects which were not mentioned by anybody in the discussion - or
>>> are you the Donald Trump of SPRIND?
>>>
>>> Best
>>> Steffen
>>>
>>>
>>>
>>> On Wed, Apr 23, 2025 at 1:00 PM Mirko Mollik <
>>> mirko.mollik at eudi.sprind.org> wrote:
>>>
>>>> Dear Steffen,
>>>>
>>>> Please do not mix up different topics here. You seem to forget that
>>>> OIDF is building standards that are focused to be used world wide, not with
>>>> the primary focus like it’s done with ETSI and CEN. I already explained on
>>>> Tom’s Issue on GitHub that from a European perspective the latest changes
>>>> in spec are fine to be aligned with the requirements from eIDAS and GDPR.
>>>> We can implement all requirements for Authentication and Authorization. The
>>>> approach was already challenged multiple times with security and privacy
>>>> experts across Europe, and they like the approach.
>>>>
>>>> Also your second argument „the registrar knows this“, is wrong. It’s
>>>> not enforced by the implementing acts to handle this and it’s up to the
>>>> member states how to do this. And this is also not the way the European
>>>> Commission wants to go via forcing QTSPs for everything! Member States that
>>>> want to use QTSPs can do so, others can avoid it.
>>>>
>>>> Long story short: I never agreed with Steffen on his claim and I am
>>>> open to discuss with others about potential gaps in the protocol that we
>>>> need to fix in the future.
>>>>
>>>> #rough consensus
>>>>
>>>> Cheers
>>>>
>>>> P.S. don’t argue like the person on your mentioned slide pls
>>>>
>>>> -
>>>> Mirko Mollik
>>>>
>>>> Identity Architect (EUDI-Wallet-Projekt) mirko.mollik at eudi.sprind.org
>>>>
>>>> SPRIND GmbH
>>>>
>>>> BUNDESAGENTUR FÜR SPRUNGINNOVATIONEN
>>>> FEDERAL AGENCY FOR DISRUPTIVE INNOVATION
>>>> Lagerhofstraße 4, 04103 Leipzig
>>>>
>>>> www.sprind.org
>>>>
>>>> Geschäftsführung: Berit Dannenberg, Rafael Laguna de la Vera
>>>> Vorsitzender des Aufsichtsrats: Dr.-Ing. E. h. Peter Leibinger
>>>> Amtsgericht Leipzig – HRB 36977
>>>> USt-ID DE328253854
>>>> Disclaimer
>>>>
>>>> Am 23.04.2025 um 11:45 schrieb steffen schwalm via
>>>> Openid-specs-digital-credentials-protocols <
>>>> openid-specs-digital-credentials-protocols at lists.openid.net>:
>>>>
>>>> Dear all,
>>>>
>>>> as briefly discussed with Mirko: The following approach defined in Slid
>>>> 12 fpr the document
>>>> https://docs.google.com/presentation/d/1s-MM27j4ZxACf0ecuVBGbuj8o4C5kr9g62jXeby0wso/edit?pli=1#slide=id.g3105e024338_0_7
>>>> is IMHO legally wrong acc. to the Implementing Act. The IA defines: no
>>>> policy, allow list or root of trust not an Attribute based access control.
>>>>
>>>> With the background that embedded policies well-known (see signature
>>>> validation policy), any RP must be listed and identified by Registrar
>>>> anyway. Means the Registrar already has the identity and the property
>>>> "bank", "doctor", "Municipality Buxtehude". If this property is written in
>>>> the Access Certificate it can be proven by the wallet when RP requests
>>>> PID/EAA data. If the correct property e.g. "Bank" given that request is
>>>> proven correctly. The Root of Trust would be (QTSP--> QEAA) --> Access
>>>> Certificate --> Registrar. As those lists already exist e.g.banking
>>>> supervision authority, Medical Association etc. it seems not comprehensible
>>>> to create new complexitites especially as the access certificate is already
>>>> x509.
>>>> This is already possible with existing x509 and reusing the standards
>>>> like ETSI EN 319 411 family,.
>>>>
>>>> And before the discussions comes: The issue here is not similar to
>>>> W3CVCDM that there might be no standard for authorization of RP - we
>>>> already have them.
>>>>
>>>> Long Story short: I support Tom and also oppose to move OID4VP to
>>>> public review.
>>>>
>>>> Best
>>>> Steffen
>>>>
>>>>
>>>> On Wed, Apr 23, 2025 at 10:26 AM steffen schwalm <
>>>> schwalm.steffen at googlemail.com> wrote:
>>>>
>>>>> Joseph:
>>>>>
>>>>> As OIDF according to its own statements aims to define specifications
>>>>> in support of EUDI Wallet your statement " given many things are out
>>>>> of scope for OID4VP and defined by local ecosystem requirements/laws" is
>>>>> highly dangerous. If OID4VP aims for EUDI any risk of legal breach as Tom
>>>>> assumes shall be avoided.
>>>>>
>>>>> means: if you believe that "OID4VP can also be used in a way that is
>>>>> compliant with such laws" --> exactly this way shall be defined as the only
>>>>> possible one to be in compliance with GDPR, eIDAS etc. Would be typical
>>>>> approach we know from ETSI, CEN, ISO.
>>>>>
>>>>> Currently looking at the mails I support Tom in his doubts.
>>>>>
>>>>> Beside this I oppose against to bring OID4VP in current version in
>>>>> next step: DCQL only requires to write query per credential format which is
>>>>> weird - in comparison to presentation exchange. Recommend to open the door
>>>>> for presentation exchange as optional possibility.
>>>>>
>>>>> Best
>>>>> Steffen
>>>>>
>>>>>
>>>>> On Wed, Apr 23, 2025 at 12:39 AM Joseph Heenan via
>>>>> Openid-specs-digital-credentials-protocols <
>>>>> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>>>>>
>>>>>> Hi Tom
>>>>>>
>>>>>> To repeat what I added to on the issue a few days ago,
>>>>>> https://github.com/openid/OpenID4VP/issues/333#issuecomment-2816774542
>>>>>> :
>>>>>>
>>>>>> I've read back through this issue. There seem to be a number of
>>>>>> questions I've asked Tom that I've not obviously got answers to, such as
>>>>>> "To try and clarify: you agree that user consent is happening, your doubt
>>>>>> is to whether the consent is sufficiently informed?". Being unable to
>>>>>> narrow down exactly what Tom believes the problem is or isn't is
>>>>>> significantly hampering figuring out if there's a problem that needs to be
>>>>>> solve in the specification or not.
>>>>>>
>>>>>>
>>>>>> I think we've replied to every point Tom has raised, with the
>>>>>> possible exception of not fully replying to this one:
>>>>>>
>>>>>>
>>>>>> Digital identity wallets must ascertain the identity of Verifiers and
>>>>>> determine whether these Verifiers possess the necessary authorisation or
>>>>>> obligation to request Verifiable Credentials (VCs) or claims.
>>>>>> I don't see how OID4VP provides that - all i see is a URL that the
>>>>>> user must decide whether to trust.
>>>>>>
>>>>>>
>>>>>> I already explained that OID4VP provides for this via
>>>>>> https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#name-client-identifier-prefix-an (for
>>>>>> example, x509_san_dns defined there does not require the user to declare
>>>>>> whether they trust a URL or not, it can be PKI certs that assert a trusted
>>>>>> name for the verifier etc) but it's perhaps also worth sharing that the
>>>>>> "possess the necessary authorisation or obligation to request Verifiable
>>>>>> Credentials (VCs) or claims." part is being solved in an EU specific way,
>>>>>> there was a presentation about this at the recent IIW:
>>>>>>
>>>>>>
>>>>>> https://docs.google.com/presentation/d/1s-MM27j4ZxACf0ecuVBGbuj8o4C5kr9g62jXeby0wso/edit#slide=id.g34994030800_0_349
>>>>>>
>>>>>>
>>>>>> My understanding of the current situation:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 1. Tom believes that OID4VP can be used in ways that are not
>>>>>> compliant with laws such as EU GDPR / EUDI wallet regulations (a point that
>>>>>> I believe there is agreement on, given many things are out of scope for
>>>>>> OID4VP and defined by local ecosystem requirements/laws)
>>>>>> 2. Tom doesn't like the way verifier authentication was done at
>>>>>> the California hackathon.
>>>>>> 3. Everyone (except for Tom?) seems to believes OID4VP can also
>>>>>> be used in a way that is compliant with such laws
>>>>>>
>>>>>>
>>>>>> Is this a correct summary?
>>>>>>
>>>>>> (Mirko also added a comment with more detail on how this would work
>>>>>> in
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Joseph
>>>>>>
>>>>>>
>>>>>> On 18 Apr 2025, at 11:35, Tom Jones <thomasclinganjones at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> i do not believe the spec is ready.
>>>>>> see https://github.com/openid/OpenID4VP/issues/333
>>>>>>
>>>>>> Peace ..tom jones
>>>>>>
>>>>>>
>>>>>> On Sat, Apr 12, 2025 at 2:12 PM Joseph Heenan via
>>>>>> Openid-specs-digital-credentials-protocols <
>>>>>> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>>>>>>
>>>>>>> Dear DCP Working Group Members,
>>>>>>>
>>>>>>> As discussed on the Friday working group call we would like to get
>>>>>>> WG consensus that the OpenID4VP draft is ready to start the final
>>>>>>> specification approval process.
>>>>>>>
>>>>>>> Please respond to this email within the next 7 days, by end of
>>>>>>> Sunday 20th April, whether you believe the draft should proceed to the
>>>>>>> public review or not.
>>>>>>>
>>>>>>> The OpenID4VP document to be reviewed can be found here:
>>>>>>> https://openid.net/specs/openid-4-verifiable-presentations-1_0-26.html
>>>>>>>
>>>>>>> There are a couple of normative changes that we discussed during the
>>>>>>> working group meeting on Friday to work on during working group last call:
>>>>>>>
>>>>>>> 1. revamp vp formats: https://github.com/openid/OpenID4VP/pull/500
>>>>>>>
>>>>>>> 2. Specifies value matching for mdocs via a reference to
>>>>>>> cbor-to-json: https://github.com/openid/OpenID4VP/pull/538
>>>>>>>
>>>>>>> 3. Remove references to ISO 18013-7 to avoid confusion due to it
>>>>>>> using OID4VP ID2: https://github.com/openid/OpenID4VP/issues/519
>>>>>>>
>>>>>>> 4. Remove anoncreds for now (hoping to add it back in 1.1) due to
>>>>>>> lack of implementation experience with DCQL etc:
>>>>>>> https://github.com/openid/OpenID4VP/pull/539
>>>>>>>
>>>>>>> We’d also expect some editorial/non-normative changes during WGLC.
>>>>>>>
>>>>>>> We also discussed scheduling a meeting to talk about the sd-jwt vcld
>>>>>>> pr: https://github.com/openid/OpenID4VP/pull/459 (a separate email
>>>>>>> about this will follow shortly.)
>>>>>>>
>>>>>>> If there are other topics working group members think need to be
>>>>>>> handled before the specification moves to final please reply to this email
>>>>>>> with details.
>>>>>>>
>>>>>>> This is very much just a step on the journey, and it is likely that
>>>>>>> comments will arrive during the 60 day review period that the working group
>>>>>>> chooses to fix before the voting period starts.
>>>>>>>
>>>>>>> The details of the specification approval process can be found here:
>>>>>>> https://openid.net/wg/resources/approving-specifications/.
>>>>>>>
>>>>>>> This email is about the first bullet point on this list "Obtain
>>>>>>> working group consensus to propose foundation-wide approval of the draft
>>>>>>> specification", which is often called Working Group Last Call (WGLC).
>>>>>>> The following steps are to start a 60-day Foundation-wide review,
>>>>>>> followed by the 7 day voting period (the poll itself will open 7 days
>>>>>>> before the end of the Foundation-wide review ends).
>>>>>>>
>>>>>>> Kindest Regards,
>>>>>>> Editors & Chairs
>>>>>>>
>>>>>>> --
>>>>>>> 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/20250424/ae9766fb/attachment-0001.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list