[Openid-specs-digital-credentials-protocols] WGLC for OpenID for Verifiable Presentations Final
Daniel Fett
fett at danielfett.de
Fri Apr 25 09:36:46 UTC 2025
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:
> o DCQL requires writing query per credential format and send 1-n
> queries to the wallet --> unnecessary increasing of complexity
> o 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20250425/e411413d/attachment-0001.htm>
More information about the Openid-specs-digital-credentials-protocols
mailing list