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

People will choose to use the custom URI scheme no matter what we can't control ecosystem that as you said. there's always use cases that never thought of the API will be used for but I think it's our job to make sure that privacy and security considerations are in place or at least have placeholders for the use cases that we have defined in scope. I don't think we should hurry the call for consensus based upon a European Union deadline. I do believe we are close in documenting the issues but I think we are still somewhat distanced from the solutions I'm not saying we need solutions before we do a first public working draft but we do need to make sure everybody agrees that we've got the correct issues logged.


Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Rick Byers <rbyers@google.com>
Sent: Thursday, June 19, 2025 7:05:25 AM
To: Johann Hofmann <johannhof@google.com>
Cc: 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

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<mailto: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<mailto: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<mailto: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<mailto:simone@w3.org>> wrote:


> Le 27 mai 2025 à 15:44, Heather Flanagan <hlf@sphericalcowconsulting.com<mailto: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<mailto:hlf@sphericalcowconsulting.com>
>  sphericalcowconsulting.com<http://sphericalcowconsulting.com>
>
> On May 12, 2025 at 1:15 PM -0700, Wendy Seltzer <wendy@seltzer.org<mailto: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<mailto:wendy@seltzer.org> +1 617.863.0613<tel:(617)%20863-0613>
>> https://wendy.seltzer.org/

>>
>>