[Openid-specs-digital-credentials-protocols] WGLC for OpenID for Verifiable Presentations Final

Thu Apr 24 14:56:01 UTC 2025

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250424/13092ff9/attachment-0001.htm>