[Openid-specs-digital-credentials-protocols] WGLC for OpenID for Verifiable Presentations Final
Daniel Fett
mail at danielfett.de
Thu Apr 24 10:21:15 UTC 2025
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250424/e1d410dc/attachment-0001.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list