Re: Call for Consensus: FPWD of Digital Credentials API spec

Hi everyone,

I believe that providing an official document to other standards bodies who
may be waiting on this group to publish something to finalize their work is
important for the digital credential ecosystem in the very short term.
Especially knowing that they mostly only need a document to point to, and
that the contents of said document can slightly change for them without too
much impact, publishing a FPWG is beneficial at this point in time.

For these reasons, I support publishing a FPWG of the DC API now.

René Léveillé
Senior Developer, Security Development
rene.leveille@1password.com

More than 100,000 businesses trust 1Password to secure their most important
information. Try it free. <https://1password.com/teams/pricing/>


On Thu, Jun 26, 2025 at 8:25 AM Matthew Miller (mattmil3) <
mattmil3@cisco.com> wrote:

> Hello everyone,
>
> The digital credential ecosystem involves building many interlocking
> pieces across multiple standards bodies. As one of those pieces, our
> cutting a FPWD now will offer immediate benefits to other groups working
> towards finalizing their pieces.
>
> We in the FedID WG have plenty of work ahead of us, true, but nothing
> about cutting a FPWD now diminishes or restrains our ongoing efforts to
> pursue a proper v1 of the DC API spec. Therefore, I support publishing
> a FPWD now.
>
> -Matthew
>
> ------------------------------
> *From:* Tobias Looker <tobias.looker@mattr.global>
> *Sent:* Wednesday, June 25, 2025 8:46:32 PM
> *To:* public-fedid-wg@w3.org <public-fedid-wg@w3.org>
> *Cc:* Rick Byers <rbyers@google.com>; Johann Hofmann <johannhof@google.com>;
> Mike Jones <michael_b_jones@hotmail.com>; Simone Onofri <simone@w3.org>;
> Heather Flanagan <hlf@sphericalcowconsulting.com>; Wendy Seltzer <
> wendy@seltzer.org>; Joseph Heenan <joseph@authlete.com>
> *Subject:* Re: Call for Consensus: FPWD of Digital Credentials API spec
>
>
> Hi all,
>
>
>
> Just want to express support for the first public working group draft,
> thanks everyone for the work to date on this important capability.
>
>
>
> Thanks,
>
> [image: MATTR website] <https://mattr.global/>
>
>
>
> *Tobias Looker*
>
> MATTR
>
> +64 273 780 461
> tobias.looker@mattr.global <first.last@mattr.global>
>
> [image: MATTR website] <https://mattr.global/>
>
> [image: MATTR on LinkedIn] <https://www.linkedin.com/company/mattrglobal>
>
> [image: MATTR on Twitter] <https://twitter.com/mattrglobal>
>
> [image: MATTR on Github] <https://github.com/mattrglobal>
>
>
> This communication, including any attachments, is confidential. If you are
> not the intended recipient, you should not read it – please contact me
> immediately, destroy it, and do not copy or use any part of this
> communication or disclose anything about it. Thank you. Please note that
> this communication does not designate an information system for the
> purposes of the Electronic Transactions Act 2002.
>
>
>
> *From: *Joseph Heenan <joseph@authlete.com>
> *Date: *Saturday, 21 June 2025 at 9:50 PM
> *To: *Mike Jones <michael_b_jones@hotmail.com>
> *Cc: *Rick Byers <rbyers@google.com>, Johann Hofmann <johannhof@google.com>,
> Simone Onofri <simone@w3.org>, Heather Flanagan <
> hlf@sphericalcowconsulting.com>, public-fedid-wg@w3.org <
> public-fedid-wg@w3.org>, Wendy Seltzer <wendy@seltzer.org>
> *Subject: *Re: Call for Consensus: FPWD of Digital Credentials API spec
>
> EXTERNAL EMAIL: This email originated outside of our organisation. Do not
> click links or open attachments unless you recognise the sender and know
> the content is safe.
>
>
>
> Hi all
>
>
>
> I also support publishing a first public working draft now - thanks
> everyone who did the quick work to address the issues!
>
>
>
> Joseph
>
>
>
>
>
> On 19 Jun 2025, at 16:39, Michael Jones <michael_b_jones@hotmail.com>
> wrote:
>
>
>
> I also support publishing FPWD now.  It’s just that – a **first** public
> working draft.  There’s no presumption that it will remain as-is in any
> particulars.  Working groups can and do revise drafts to incorporate
> feedback received – especially from implementers.
>
>
>
> Let’s start this process with a public working group draft.
>
>
>
>                                                                 Thank you,
>
>                                                                 -- Mike
>
>
>
> *From:* Rick Byers <rbyers@google.com>
> *Sent:* Thursday, June 19, 2025 7:05 AM
> *To:* Johann Hofmann <johannhof@google.com>
> *Cc:* Simone Onofri <simone@w3.org>; Heather Flanagan <
> hlf@sphericalcowconsulting.com>; public-fedid-wg@w3.org; Wendy Seltzer <
> wendy@seltzer.org>
> *Subject:* Re: Call for Consensus: FPWD of Digital Credentials API spec
>
>
>
> Thank you for this great summary Johann and for all your hard work getting
> these issues captured in the spec. I also believe we should publish a FPWD
> immediately. Wendy / Heather, can we do a new CfC?
>
>
>
> As a reminder we are down to only about a week (after the US holiday)
> before the deadline we've been told would likely mean the EUDI ecosystem
> will likely be locked in (by law) to custom schemes. Verifiers will not
> choose to invoke the DC API if they believe some important government
> wallets will not support it but will support the openid4vp:// custom
> schemes. We are dangerously close to throwing the baby out with the
> bathwater in our attempt to improve the properties of this existing
> ecosystem which we cannot control.
>
>
>
> Cheers,
>
>    Rick
>
>
>
> On Thu, Jun 19, 2025 at 8:00 AM Johann Hofmann <johannhof@google.com>
> wrote:
>
> Hi everyone,
>
>
>
> I wanted to send another update on this effort. To ensure that identified
> issues and outstanding discussions related to Privacy are represented in
> the FPWD, I’ve gone through the list of open issues and summarized /
> categorized them based on broader themes, and figured the list might be
> interesting to this group.
>
>
>
> I believe that most of these themes, and related issues, are now
> referenced either in the privacy considerations, or in open spec PRs. I'll
> make sure that the few themes we haven't covered yet make it into the spec
> as soon as possible. Thank you to all who have contributed so far, and
> please file a new issue if there's something missing from this list.
>
>
>
> I want to say that while some PRs are still open, I'd personally be
> comfortable with going for FPWD now, as I think we've made significant
> progress in documenting and discussing these issues (and I expect us to
> merge the remaining PRs within the next few days, and iterate from there)..
>
>
>
> Here's the list:
>
>
>
> *Unnecessary use (#262
> <https://github.com/w3c-fedid/digital-credentials/pull/262>)*
>
>
>
> Jevon’s paradox and resulting exclusion risks - #35
> <https://github.com/w3c-fedid/digital-credentials/issues/35> and #123
> <https://github.com/w3c-fedid/digital-credentials/issues/123> call out
> the potentially negative consequences of easier access to real world
> identity on freedom of expression on the web.
>
>
>
> #281 <https://github.com/w3c-fedid/digital-credentials/issues/281> discusses
> closer user agent integration with verifier authorization - a potential
> mitigation for Jevon’s paradox.
>
>
>
> #267 <https://github.com/w3c-fedid/digital-credentials/issues/267> proposes
> introducing a reporting system for abusive credential requests
>
>
>
> *Transparency, permission and consent (#253
> <https://github.com/w3c-fedid/digital-credentials/pull/253>)*
>
>
>
> Various issues (#44
> <https://github.com/w3c-fedid/digital-credentials/issues/44>, #136
> <https://github.com/w3c-fedid/digital-credentials/issues/136>, #209
> <https://github.com/w3c-fedid/digital-credentials/issues/209>, #266
> <https://github.com/w3c-fedid/digital-credentials/issues/266>) advocate
> for the introduction of some system that allows verifiers to declare values
> that improve transparency and auditability, such as purpose of use,
> retention and verifier authorization.
>
>
>
> #252 <https://github.com/w3c-fedid/digital-credentials/issues/252> and
> #268 <https://github.com/w3c-fedid/digital-credentials/issues/268> ask
> whether the specification could normatively define aspects of the
> permission experience, such as user friction or permission disclosure.
>
>
>
> #134 <https://github.com/w3c-fedid/digital-credentials/issues/134> and
> #208 <https://github.com/w3c-fedid/digital-credentials/issues/208> propose
> integration with PEPC or a similar DOM element to ensure verifier-provided
> context as a prerequisite for a credential exchange.
>
>
>
> #85 <https://github.com/w3c-fedid/digital-credentials/issues/85> and #117
> <https://github.com/w3c-fedid/digital-credentials/issues/117> explore
> introducing registries for credential and/or request types that could help
> user agents improve the permission experience and protect against abuse.
>
>
>
> #100 <https://github.com/w3c-fedid/digital-credentials/issues/100> contrasts
> these efforts to better understand requests with a desire for open
> ecosystem evolution, especially for non-government credentials.
>
>
>
> #166 <https://github.com/w3c-fedid/digital-credentials/issues/166>, #246
> <https://github.com/w3c-fedid/digital-credentials/issues/246>, #263
> <https://github.com/w3c-fedid/digital-credentials/issues/263> and #269
> <https://github.com/w3c-fedid/digital-credentials/issues/269> call out
> that we’re lacking a clearly defined trust model between the involved
> parties, including different cooperating user agents (though we’ve made
> some progress with this).
>
>
>
> #286 <https://github.com/w3c-fedid/digital-credentials/issues/286> proposes
> to define privacy considerations for when verifiers request multiple
> credentials.
>
>
>
> *Protocol Requirements (#260
> <https://github.com/w3c-fedid/digital-credentials/pull/260>)*
>
> #226 <https://github.com/w3c-fedid/digital-credentials/issues/226> and
> #255 <https://github.com/w3c-fedid/digital-credentials/issues/255> call
> out that a completed privacy review for protocols should involve addressing
> raised issues.
>
>
>
> #122 <https://github.com/w3c-fedid/digital-credentials/issues/122>, #139
> <https://github.com/w3c-fedid/digital-credentials/issues/139> and #279
> <https://github.com/w3c-fedid/digital-credentials/issues/279> discuss the
> conflicted goals of the API with regards to unlinkability, whether it makes
> sense to consider information shared by the API inherently identifiable and
> whether protocols can be required to support verifier-issuer unlinkability
> (and what that means for discouraging “phoning home”). #280
> <https://github.com/w3c-fedid/digital-credentials/issues/280> asks
> whether unlinkable revocation is even feasible.
>
>
>
> #109 <https://github.com/w3c-fedid/digital-credentials/issues/109> asks
> whether response encryption should be required - the spec currently says
> “yes”, but the issue remains open.
>
>
>
> *Fingerprinting and information leakage (#283
> <https://github.com/w3c-fedid/digital-credentials/pull/283>)*
>
>
>
> #105 <https://github.com/w3c-fedid/digital-credentials/issues/105> and
> #265 <https://github.com/w3c-fedid/digital-credentials/issues/265> reinforce
> the need to avoid leaking credential availability information to websites
> while #104 <https://github.com/w3c-fedid/digital-credentials/issues/104> explores
> possible alternatives.
>
>
>
> #168 <https://github.com/w3c-fedid/digital-credentials/issues/168> and
> #200 <https://github.com/w3c-fedid/digital-credentials/issues/200> propose
> feature / protocol detection methods and discuss their impact on privacy.
>
>
>
>
>
> Hope everyone has a great weekend!
>
>
>
> Thanks,
>
>
>
> Johann
>
>
>
>
>
> On Fri, Jun 13, 2025 at 8:08 PM Rick Byers <rbyers@google.com> wrote:
>
> Thank you Johann. This plan sounds great to me.
>
>
>
> On Fri, Jun 13, 2025 at 8:01 PM Johann Hofmann <johannhof@google.com>
> wrote:
>
> Hi folks,
>
>
>
> I’ve been working on documenting privacy considerations for the Digital
> Credentials API to resolve the lack of consensus for FPWD. Simone Onofri is
> also making progress working on the security considerations.
>
>
>
> Given the time pressure that the group is operating under to align with
> publication deadlines for the EUDI ARF, I met with Nick Doty to discuss a
> pragmatic path to consensus within the month that nonetheless sets the API
> up for constructive privacy reviews and improvements going forward.
>
>
>
> First off, we see various mid- to long-term investigation areas for the
> API, particularly in Privacy, including:
>
>
>
>    - Informed explanations - How can we ensure verifiers / wallets / user
>    agents can and will show the right disclosures to users?
>    - Use case limitations
>
>
>    - Better addressing use case limits for government credentials
>       - Explore how this applies to non-government credentials
>       - Work on a .well-known declaration file proposal
>       - Integration of EUDI style access certificates
>
>
>    - Abuse reporting
>
>
>
> … and, while it’s important to recognize they are not addressable in the
> short term, we would like to see the group start addressing these questions
> in the near future.
>
>
>
> For FPWD, we believe that our main objective should be that the
> publication includes enough context for group-external reviewers to
> understand identified risks, issues and design tradeoffs made. To ensure
> this, we’d like to propose three small scoped final deliverables:
>
>
>
>    1. Crucially - the design of the API as a “thin layer” seems to
>    originate from a desire to compete with the flexibility offered by, and
>    prevent immediate adoption of, worse solutions
>    <https://github.com/w3c-fedid/digital-credentials/blob/main/custom-schemes.md>.
>    This context is important as it justifies some of the fundamental design
>    choices that result in inherent privacy tradeoffs, and as such we should
>    make sure it gets properly documented in the specification. Between Rick’s
>    and Simone’s documents
>    <https://docs.google.com/document/d/1Ppaz_EnhzHqPOz5UusRJvbSunh-RXPWgJ3Np_TM2EE0/edit?tab=t.0>
>    I believe there is good material that we can quickly adapt for the spec (
>    #275 <https://github.com/w3c-fedid/digital-credentials/issues/275>).
>    2. Existing privacy & security concerns that were flagged in GitHub
>    issues should be called out inline in the spec. This involves reviewing
>    both existing text and the PRs that are currently in flight, and making
>    sure they refer back to the right GitHub issues.
>    3. In our June 16th call, we would like to discuss an unresolved
>    question of permission vs. consent
>    <https://github.com/w3c-fedid/digital-credentials/pull/253#discussion_r2132917483>
>    and whether the group considers it appropriate and enough to codify a
>    requirement for protocols that verifiers and wallets must be able to share
>    relevant information for consent.
>
>
>
> While I’m not in charge of consensus calls, my recommendation to the
> chairs would be to start another CfC once these things have happened, which
> could be next week if we crunch a bit. :)
>
>
>
> I’m happy to discuss this at our WG call on Monday, and I’m very happy to
> get thoughts from y’all on this proposed plan.
>
>
>
> Thanks,
>
>
>
> Johann
>
>
>
>
>
> On Tue, May 27, 2025 at 7:15 PM Simone Onofri <simone@w3.org> wrote:
>
>
>
> > Le 27 mai 2025 à 15:44, Heather Flanagan <hlf@sphericalcowconsulting.com>
> a écrit :
> >
> > Hearing strong objections to publication of the FPWD at this stage, this
> call does not have consensus. Thanks to both of you for documenting your
> concerns and helping the group to work through them. We also recognize the
> interest in timely publication. Addressing the Formal Objection introduces
> additional complexity to the DC API spec. However, given the importance of
> resolving this and the urgency of progressing the specification, we are
> proposing the following approach:
> >   We will reach out to Johann and Nick, who have volunteered to work on
> text for the privacy considerations section, to determine what they
> consider a reasonable timeframe for drafting proposed text to address the
> concerns raised, ideally within the next four weeks. Once the draft text is
> available, we will ask the editors to review and respond within one week.
> > Provided there are no outstanding concerns at that point, we will
> re-issue a Call for Consensus (CfC) to publish the First Public Working
> Draft (FPWD), incorporating the updated material.
> >   In the meantime, there is still plenty of work to do. If you ware
> interested in working on the security and privacy sections, please dive in!
>
> Hi Heather, all,
>
> With the Security Interest Group, we are actively working on the security
> aspect so that we can discuss it with the group. If anyone would like to
> join us, please feel free to contact me.
>
> We’re synching with Johann about it.
>
> Thank you,
>
> Simone
>
> >
> > Heather Flanagan (she/hers)
> > Principal, Spherical Cow Consulting
> >  hlf@sphericalcowconsulting.com
> >  sphericalcowconsulting.com
> >
> > On May 12, 2025 at 1:15 PM -0700, Wendy Seltzer <wendy@seltzer.org>,
> wrote:
> >> Hi FedID WG,
> >>
> >> Following our WG hybrid meeting[1] and further issue resolution, we're
> >> calling for a consensus to publish the editor's draft dated 5 May [2],
> >> https://w3c-fedid.github.io/digital-credentials/
> >> as First Public Working Draft of the Digital Credentials API. FPWD does
> >> not mean all issues are resolved, but gives us a stable reference from
> >> which to engage with outside groups for horizontal review.
> >>
> >> If we hear no objections by 19 May, one week from today, we will take
> >> that as consensus to publish the FPWD.
> >>
> >> We also propose that once the FPWD is published, we will enable
> >> auto-publication of Editors' Drafts.
> >>
> >> Please raise any questions or comments on this CfC by 19 May.
> >>
> >> Thank you,
> >> --Wendy, FedID co-chair
> >>
> >> [1]
> >>
> https://github.com/w3c-fedid/meetings/blob/main/2025/2025-04-11-hybrid-notes.md
> >>
> >> [2]
> >>
> https://github.com/w3c-fedid/digital-credentials/blob/1544b64f0f7231373bfa6991dab3806f5e3cec36/index.html
> >>
> >>
> >> --
> >> Wendy Seltzer -- wendy@seltzer.org +1 617.863.0613 <(617)%20863-0613>
> >> https://wendy.seltzer.org/
> >>
> >>
>
>
>