[Openid-specs-digital-credentials-protocols] WGLC for OpenID for Verifiable Presentations Final
steffen schwalm
schwalm.steffen at googlemail.com
Mon Apr 28 14:58:09 UTC 2025
Hi Timo,
thanks a lot for your insights and experiences. Within the EBSI ecosystem
we can´t share those experiences so would be great to understand your
experiences better. As EBSI used in several projects and implementations
with > 100 participants (Companies, Authorities, Universities, incl. LSP on
EUDIW) in Europe, same with the GAIA.-X Space and some industry projects it
would be quite important I guess to understand your experiences further.
Within the mentioned projects DCQL creates exactly the concerns I mentioned
e.g. additional effort as mentioned as well as migration and change effort
in case of change from PE.
As written in separate mail it would be good to understand your experiences
further as they are contrary opposite to the ones in the mentioned large
ecosystems.
Best
steffen
On Sun, Apr 27, 2025 at 4:03 PM Timo Glastra <timo at animo.id> wrote:
> > Exactly the fact that in DCQL more queries needed increase complexity
> and possibility of failures.
>
> As having implemented and worked on a technical level with both DCQL and
> PE, the model of PE didn’t work in practice. Since the same credentials
> have different structures, claim names, and types (like string, array,
> etc..) in different credential types. Also the credential type
> matching is underspecified in PEv2 (PEv1 was better on this IMO) as well
> and thus means you can’t have a single input descriptor both matching mdoc
> and sd-jwt.
>
> This resulted in a lot of complexity in the spec, but the practice was
> still that each input descriptor was format specific (at least in our
> case). If you want to match e.g. both w3c types and vct you’d have to write
> very complex json path queries which most implementations would not support
> (since vct is string and type in w3c is array). Same that a lot of
> implementations only implemented very limited set of filter types
> (basically type + const, not even enum). We have done a lot of interop
> testing with PE, in potential, in the dutch ecosystem, within openid
> foundation. And it’s a mess. We haven’t done as much interop testing with
> DCQL, so only time can tell how it compares, but the first interop test
> results within OpenID foundation across a range of wallets and verifiers
> looks promising.
>
> With DCQL the matching logic became significantly simpler, resulting in us
> understanding the query better and actually providing more useful feedback
> to the user, such as “this credential is requested, which you have, but the
> following property is missing”. With pex this is basically impossible.
>
> There’s still some features missing in DCQL (most importantly for us as
> Animo, for which an issue is already available, is the did based trusted
> authority querying) but otherwise we’ve been able to translate all our PEX
> queries to DCQL and have had much less interop issues as it’s quite easy to
> implement the whole DCQL spec.
>
> Best regards,
>
> *Timo Glastra*
>
> *Co-Founder | **Animo Solutions*
> https://animo.id
>
>
>
> On Sun, 27 Apr 2025 at 15:26 steffen schwalm via
> Openid-specs-digital-credentials-protocols <
> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>
>> As described we have following issue:
>>
>> - DCQL requires writing query per credential format and send 1-n
>> queries to the wallet --> unnecessary increasing of complexity
>> - PE: sending exactly 1 query also if RP accept credential in
>> different format
>>
>> As we have a Zoo of credential formats in practice which will remain
>> anyway (as EUDIW is voluntary and EAA will contain more than 1 format) we
>> may have following use case:
>>
>>
>> - Relying party requires that Holder provides a Digital Product
>> Passport for certain product
>> - RP accepts SD-JWT VC and JWT VC (W3CVCDM) as RP cannot limit the
>> formats by law
>> - means:
>> - DCQL you need to write 2 queries - one for each formats -->
>> increase exponentially in case of complex credentials like DPP (which
>> contain > 1 single credential or value)
>> - PE your write exactly 1 query and send it to wallet asking for
>> credential/value and telling that response format can be SD-JWT VC or JWT-V
>>
>> Exactly the fact that in DCQL more queries needed increase complexity and
>> possibility of failures. Means issue will IMHO occur especially in case of
>> (Q)EAA but this will be foreseeably the majority of use cases - not the PID.
>>
>> Same as for Mirko: Remain at your disposal for short call to solve
>> possible issue
>>
>> Best
>> steffen
>>
>> On Fri, Apr 25, 2025 at 11:46 AM Daniel Fett via
>> Openid-specs-digital-credentials-protocols <
>> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>>
>>> Give me a concrete example for a query in PE and DCQL (e.g., requesting
>>> a PID allowing for SD-JWT VC and mdoc format) that shows the problem you
>>> raised, to ensure we're talking about the same thing.
>>>
>>> -Daniel
>>> Am 24.04.25 um 16:56 schrieb steffen schwalm via
>>> Openid-specs-digital-credentials-protocols:
>>>
>>> Hi Daniel,
>>>
>>> the issue on PE was raised several times by experts but ignored as
>>> always. So let´s focus on the facts:
>>>
>>>
>>> - As PE is already in place you create the Interoperability issue
>>> per definition
>>> - the incomplete implementations can`t really be confirmed and your
>>> experience is only one example, questions: What was the issue of the
>>> "incomplete" implementations?
>>> - DCQLcreates additional effort and so risks on implementation:
>>> - DCQL requires writing query per credential format and send 1-n
>>> queries to the wallet --> unnecessary increasing of complexity
>>> - PE: sending exactly 1 query also if RP accept credential in
>>> different formats
>>> - means you increase complexity and risk of failures
>>>
>>> Regarding your arguments:
>>>
>>>
>>> 1. A single query for multiple credential formats was not a
>>> requirement.
>>> --> Does this mean tht requirement was not to create something for
>>> the actual practice as we have a Zoo of credential formats for same
>>> kind/semantics of credential in place?
>>> 2. The differences are really as minimal as they can be.
>>> --> No DCQL only increase complexity see above
>>> 3. There will always be differences in how credentials are requested
>>> depending on the format - in particular, for matching types (W3C) vs VCTs
>>> (SD-JWT VC) vs doctypes vs ...; these differences also exist when you use
>>> PE.
>>> --> yes but complexity as mentioned above in DCQL in comparison to
>>> PE remains
>>> 4. If you don't request a specific type/VCT/doctype, just querying
>>> for claims (which you can do in a largely format-independent way) is not
>>> considered useful, as the claims don't have a meaning without the
>>> type/VCT/doctype etc..
>>> --> might be, but complexity as mentioned above in DCQL in
>>> comparison to PE remains
>>> 5. Implementers have given us *very* positive feedback on DCQL and
>>> voiced support for removing PE due to its complexity. There are also
>>> potential security issues. --> Which security issues? Which implementers?
>>> Note that LSP would be wrong answer as they have to implement the ARF by
>>> definition of their Grant Agreement, so they have no real choice
>>>
>>>
>>> Long Story short: As you don`t bring any argument concerning the clear
>>> increasing of complexity with DCQL and the Specification OID4VP does not
>>> contain anything on interoperability with or migration of existing
>>> implementionats on PE (especially in Europe see e.g. GAIA-X, Industry,
>>> Education etc,) it seems not really comprehensible to keep DCQL only.
>>>
>>> I upheld my opposition!
>>>
>>> On Thu, Apr 24, 2025 at 12:21 PM Daniel Fett via
>>> Openid-specs-digital-credentials-protocols <
>>> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>>>
>>>>
>>>> Am 23.04.25 um 10:26 schrieb steffen schwalm via
>>>> Openid-specs-digital-credentials-protocols:
>>>>
>>>>
>>>> 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.
>>>>
>>>> We had lengthy discussions on how to design DCQL and whether it should
>>>> replace PE or not. I find it surprising that you raise that point now
>>>> without having voiced your concerns about DCQL being "weird" in any of the
>>>> earlier discussions.
>>>>
>>>> As a summary for you, here are the main reasons why we designed DCQL
>>>> the way it is and why the WG chose to remove PE:
>>>>
>>>> - A single query for multiple credential formats was not a requirement.
>>>>
>>>> - The differences are really as minimal as they can be.
>>>>
>>>> - There will always be differences in how credentials are requested
>>>> depending on the format - in particular, for matching types (W3C) vs VCTs
>>>> (SD-JWT VC) vs doctypes vs ...; these differences also exist when you use
>>>> PE.
>>>>
>>>> - If you don't request a specific type/VCT/doctype, just querying for
>>>> claims (which you can do in a largely format-independent way) is not
>>>> considered useful, as the claims don't have a meaning without the
>>>> type/VCT/doctype etc..
>>>>
>>>> - Implementers have given us *very* positive feedback on DCQL and
>>>> voiced support for removing PE due to its complexity. There are also
>>>> potential security issues.
>>>>
>>>> - We have seen many incomplete implementations of PE, leading to
>>>> interoperability issues.
>>>>
>>>> - Keeping PE as an optional feature introduces interoperability issues.
>>>>
>>>>
>>>> -Daniel
>>>>
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>>
>>> --
>>> Please use my new email address: mail at danielfett.de
>>>
>>> --
>>> 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/20250428/9302d638/attachment-0001.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list