<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 gmail_quote_container"><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">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><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>