<div dir="ltr">As described we have following issue:<div><ul><li style="margin-left:15px">DCQL requires writing query per credential format and send 1-n queries to the wallet --> unnecessary increasing of complexity</li><li style="margin-left:15px">PE: sending exactly 1 query also if RP accept credential in different format</li></ul><div>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:</div></div><div><br></div><div><ul><li>Relying party requires that Holder provides a Digital Product Passport for certain product</li><li>RP accepts SD-JWT VC and JWT VC (W3CVCDM) as RP cannot limit the formats by law</li><li>means:</li><ul><li>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)</li><li>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</li></ul></ul><div>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.</div></div><div><br></div><div>Same as for Mirko: Remain at your disposal for short call to solve possible issue </div><div><br></div><div>Best</div><div>steffen </div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Apr 25, 2025 at 11:46 AM Daniel Fett via Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net">openid-specs-digital-credentials-protocols@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>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.<br>
</p>
<p>-Daniel<br>
</p>
<div>Am 24.04.25 um 16:56 schrieb steffen
schwalm via Openid-specs-digital-credentials-protocols:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Daniel,
<div><br>
</div>
<div>the issue on PE was raised several times by experts but
ignored as always. So let´s focus on the facts:<br>
<br>
<ul>
<li>As PE is already in place you create the
Interoperability issue per definition</li>
<li>the incomplete implementations can`t really be confirmed
and your experience is only one example, questions: What
was the issue of the "incomplete" implementations?</li>
<li>DCQLcreates additional effort and so risks on
implementation:</li>
<ul>
<li>DCQL requires writing query per credential format and
send 1-n queries to the wallet --> unnecessary
increasing of complexity</li>
<li>PE: sending exactly 1 query also if RP accept
credential in different formats</li>
</ul>
<li>means you increase complexity and risk of failures</li>
</ul>
<div>Regarding your arguments: </div>
<div><br>
</div>
<div>
<ol>
<li>A single query for multiple credential formats was not
a requirement. <br>
--> 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? </li>
<li>The differences are really as minimal as they can be.<br>
--> No DCQL only increase complexity see above</li>
<li>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.<br>
--> yes but complexity as mentioned above in DCQL in
comparison to PE remains</li>
<li>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..<br>
--> might be, but complexity as mentioned above in
DCQL in comparison to PE remains
</li>
<li>Implementers have given us <i>very</i> 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</li>
</ol>
<div><br>
</div>
</div>
</div>
<div>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.</div>
<div><br>
</div>
<div>I upheld my opposition! </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 24, 2025 at
12:21 PM Daniel Fett via
Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>Am 23.04.25 um 10:26 schrieb steffen schwalm via
Openid-specs-digital-credentials-protocols:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div><br>
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.<br>
</div>
</div>
</blockquote>
<p>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.</p>
<p>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:<br>
</p>
<p>- A single query for multiple credential formats was not
a requirement.</p>
<p>- The differences are really as minimal as they can be.<br>
</p>
<p>- 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.</p>
<p>- 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..</p>
<p>- Implementers have given us <i>very</i> positive
feedback on DCQL and voiced support for removing PE due to
its complexity. There are also potential security issues.<br>
</p>
<p>- We have seen many incomplete implementations of PE,
leading to interoperability issues.</p>
<p>- Keeping PE as an optional feature introduces
interoperability issues.</p>
<p><br>
</p>
<p>-Daniel<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div><br>
Best<br>
Steffen</div>
<div><span style="color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><br>
</span></div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Apr 23, 2025
at 12:39 AM Joseph Heenan via
Openid-specs-digital-credentials-protocols <<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>Hi Tom
<div><br>
</div>
<div>To repeat what I added to on the issue a few
days ago, <a href="https://github.com/openid/OpenID4VP/issues/333#issuecomment-2816774542" target="_blank">https://github.com/openid/OpenID4VP/issues/333#issuecomment-2816774542</a> :</div>
<div><br>
</div>
<div>
<p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">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.</p>
<p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><br>
</p>
<p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">I
think we've replied to every point Tom has
raised, with the possible exception of not fully
replying to this one:</p>
<p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><br>
</p>
<blockquote style="box-sizing:border-box;margin-top:0px;margin-right:0px;margin-left:0px;padding:0px 1em;font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">
<p dir="auto" style="box-sizing:border-box;margin-top:0px">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.</p>
<p dir="auto" style="box-sizing:border-box;margin-top:0px;margin-bottom:0px">I don't
see how OID4VP provides that - all i see is a
URL that the user must decide whether to
trust.</p>
</blockquote>
<p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><br>
</p>
<p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">I
already explained that OID4VP provides for this
via <a href="https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#name-client-identifier-prefix-an" rel="nofollow" style="box-sizing:border-box;color:rgb(31,35,40)" target="_blank">https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#name-client-identifier-prefix-an</a> (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:</p>
<p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><a href="https://docs.google.com/presentation/d/1s-MM27j4ZxACf0ecuVBGbuj8o4C5kr9g62jXeby0wso/edit#slide=id.g34994030800_0_349" rel="nofollow" style="box-sizing:border-box;color:rgb(31,35,40)" target="_blank">https://docs.google.com/presentation/d/1s-MM27j4ZxACf0ecuVBGbuj8o4C5kr9g62jXeby0wso/edit#slide=id.g34994030800_0_349</a></p>
<p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><br>
</p>
<p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">My
understanding of the current situation:</p>
<p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><br>
</p>
<ol dir="auto" style="box-sizing:border-box;padding-left:2em;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">
<li style="box-sizing:border-box">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)</li>
<li style="box-sizing:border-box;margin-top:0.25em">Tom doesn't like the way
verifier authentication was done at the
California hackathon.</li>
<li style="box-sizing:border-box;margin-top:0.25em">Everyone (except for
Tom?) seems to believes OID4VP can also be
used in a way that is compliant with such laws</li>
</ol>
<p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px;margin-bottom:0px"><br>
</p>
<p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px;margin-bottom:0px">Is
this a correct summary?</p>
<div><br>
</div>
<div>(Mirko also added a comment with more detail
on how this would work in </div>
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div>Joseph</div>
<div><br>
</div>
<div><br>
<blockquote type="cite">
<div>On 18 Apr 2025, at 11:35, Tom Jones <<a href="mailto:thomasclinganjones@gmail.com" target="_blank">thomasclinganjones@gmail.com</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div>i do not believe the spec is ready.</div>
<div>see <a href="https://github.com/openid/OpenID4VP/issues/333" target="_blank">https://github.com/openid/OpenID4VP/issues/333</a></div>
<div><br>
</div>
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr"><font face="-apple-system, system-ui, system-ui, Segoe UI, Roboto, Helvetica Neue, Fira Sans, Ubuntu, Oxygen, Oxygen Sans, Cantarell, Droid Sans, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol, Lucida Grande, Helvetica, Arial, sans-serif" color="#38761d"><span style="font-size:14px;background-color:rgb(242,242,242)">Peace ..tom
jones</span></font></div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat,
Apr 12, 2025 at 2:12 PM Joseph Heenan
via
Openid-specs-digital-credentials-protocols
<<a href="mailto:openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">openid-specs-digital-credentials-protocols@lists.openid.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>
<div>Dear DCP Working Group Members,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div> </div>
<div>The OpenID4VP document to be
reviewed can be found here: <a href="https://openid.net/specs/openid-4-verifiable-presentations-1_0-26.html" target="_blank">https://openid.net/specs/openid-4-verifiable-presentations-1_0-26.html</a></div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>1. revamp vp formats: <a href="https://github.com/openid/OpenID4VP/pull/500" target="_blank">https://github.com/openid/OpenID4VP/pull/500</a></div>
<div><br>
</div>
<div>2. Specifies value matching for
mdocs via a reference to
cbor-to-json: <a href="https://github.com/openid/OpenID4VP/pull/538" target="_blank">https://github.com/openid/OpenID4VP/pull/538</a></div>
<div><br>
</div>
<div>3. Remove references to ISO
18013-7 to avoid confusion due to
it using OID4VP ID2: <a href="https://github.com/openid/OpenID4VP/issues/519" target="_blank">https://github.com/openid/OpenID4VP/issues/519</a></div>
<div><br>
</div>
<div>4. Remove anoncreds for now
(hoping to add it back in 1.1) due
to lack of implementation
experience with DCQL etc: <a href="https://github.com/openid/OpenID4VP/pull/539" target="_blank">https://github.com/openid/OpenID4VP/pull/539</a></div>
<div><br>
</div>
<div>We’d also expect some
editorial/non-normative changes
during WGLC.</div>
<div><br>
</div>
<div>We also discussed scheduling a
meeting to talk about the sd-jwt
vcld pr: <a href="https://github.com/openid/OpenID4VP/pull/459" target="_blank">https://github.com/openid/OpenID4VP/pull/459</a> (a
separate email about this will
follow shortly.)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>The details of the
specification approval process can
be found here: <a href="https://openid.net/wg/resources/approving-specifications/" target="_blank">https://openid.net/wg/resources/approving-specifications/</a>.</div>
<div><br>
</div>
<div>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).</div>
<div>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).</div>
<div><br>
</div>
<div>Kindest Regards,</div>
<div>Editors & Chairs</div>
<div><br>
</div>
</div>
</div>
-- <br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
-- <br>
Openid-specs-digital-credentials-protocols mailing
list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
</blockquote>
</div>
-- <br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
</blockquote>
<pre cols="72">--
Please use my new email address: <a href="mailto:mail@danielfett.de" target="_blank">mail@danielfett.de</a></pre>
</div>
-- <br>
Openid-specs-digital-credentials-protocols mailing list<br>
<a href="mailto:Openid-specs-digital-credentials-protocols@lists.openid.net" target="_blank">Openid-specs-digital-credentials-protocols@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols</a><br>
</blockquote></div>