2026 AnonCreds MidYear report, update to 2026 Annual Report

[swcurran]

Primary purpose of this PR is the submission of the AnonCreds Project MidYear report for 2026. The tl;dr is "maintenance mode project continues".

Also did some retrofitting of the AnonCreds 2026 Annual report that had not been done previously:

• Added the "TAC feedback" about the report to the end of the report, as had been planned.
• Added the link to TAC Meeting recording where the Annual report was discussed.
• Removed "Hyperledger" from the name of the project -- as has been the approach of the maintainers. It's just "AnonCreds", in hopes of reducing the perception that AnonCreds requires Hyperledger Indy.
  • Included in that change is changing the Annual Report file name to remove "hyperledger" from it.

Note that this PR DOES NOT include an update to the mkdocs.yml file, as such a change would likely lead to merge conflicts on this and other PRs.

I would also note that the mkdocs.yml file is out of date and missing reports -- including the AnonCreds Annual report that was approved in March. I would suggest that the mkdocs.yml updates not be the responsibility of the report submitters, but either taken on the by the TAC or better -- a GHAction that generates the file on merging for the gh-pages branch.

Let us know if the practice is for project maintainers to join a TAC meeting where the report is discussed. As I recall, that is not needed for mid-year reports.

[git-vote]

Only repository collaborators can create a vote @swcurran.

For organization-owned repositories, the list of collaborators includes outside collaborators, organization members that are direct collaborators, organization members with access through team memberships, organization members with access through default organization permissions, and organization owners.

[dmueller2001]

Thanks @swcurran . I’m comfortable with the report, but the description of AnonCreds v1 as mature, stable and now largely in maintenance mode raises a lifecycle question for me.

My understanding is that AnonCreds v1 remains a well-established and meaningfully adopted privacy-preserving credential solution. Given the current state of the broader ZKP credential market, I don't see maintenance mode itself as evidence that AnonCreds has become obsolete or dormant. If anything, it seems to reflect the maturity of v1.

Given that LFDT Graduation is intended to reflect the maturity and sustainability of the project rather than continued development of new functionality, what specifically prevents AnonCreds from meeting the Graduation criteria today?

Is there an unmet Graduation criterion associated with AnonCreds v1 itself, or are we effectively keeping the project in Incubation because AnonCreds v2 has not progressed?

I also wonder whether Graduation could itself be beneficial to the project. Recognizing AnonCreds v1 as a mature LFDT project could provide a stronger signal to potential adopters, help bring existing production use cases to light, and potentially attract additional contributors and integrations. If adoption is happening but is difficult to measure, a Graduation review could also be an opportunity to document that ecosystem more systematically.

If v1 meets the criteria, perhaps the maintainers should consider requesting a Graduation review based on the maturity and sustainability of v1, independently of the outcome of the v2 effort.

Separately, given the report’s conclusion that AnonCreds v2 is no longer expected to provide the intended path to a modern ZKP solution, perhaps we should clarify whether v2 remains an active project objective rather than allowing its lack of progress to influence the lifecycle assessment of v1.

[swcurran]

Hi @dmueller2001 -- thanks for you review.

The reason I have not proposed a move to Graduation status is the lack of a community around the effort. The only people working on AnonCreds are those that are dependent on it for their Frameworks (e.g., ACA-Py Plugins, Credo Modules) -- which is two levels distant from those deploying the technology, and three levels from users of the capability. We do get entities that use the spec and libraries to create a plugin to work in their ecosystem -- such as the brand new did:cid/Archon implementation -- but those are not contributors to AnonCreds. For all we know there could be many other such efforts. The only contributors are those that must do so as they evolve their own higher level framework. There are no meeting participants or PRs/Issues being raised.

While privacy is a talked about as important in the credentials world, it is largely just talk. There are few that are actually trying to achieve it -- and none (AFAIK) in anything but a siloed manner. The Google Longfellow effort is likely the best chance because it is from Google and builds on mDL (and there was a recent announcement of "Longfellow for SD-JWTs"...), but that doesn't get general purpose ZKPs (and the resultant privacy) into other ecosystems.

It's a challenge.

[dmueller2001]

@swcurran It sounds like the issue isn't the maturity or stability of AnonCreds v1 itself, but whether there is enough of an independent community around the project to consider it sustainable in the sense we expect of a Graduated LFDT project.

I do wonder, though, whether there is a bit of a chicken-and-egg problem here.

If the technology is mature and stable, and the people maintaining it are primarily downstream framework maintainers because they depend upon it, I'm not sure that necessarily indicates an unhealthy community. It may instead be characteristic of mature infrastructure where much of the innovation and user interaction has naturally moved higher in the stack.

Your point that there may be implementations and deployments that the AnonCreds maintainers simply don't know about is particularly interesting. That suggests the problem may be visibility into adoption rather than an absence of adoption.

That's why I continue to wonder whether Graduation might actually be appropriate. It would recognize AnonCreds v1 for what it has become: mature, stable infrastructure that continues to be depended upon and maintained, even though it no longer generates the level of direct project activity we might expect from an earlier-stage project.

Graduation could also provide a useful signal to the market that AnonCreds is mature and production-ready, potentially bringing some of those otherwise invisible implementations and use cases to light. For instance, a graduation announcement might include a 'call' to share your stories/case studies as part of the 'celebration' of graduating as well as a call to action to give feedback, become a contributor or give some form of financial/engineering resource to help maintain the project.

I wouldn't want us to leave a mature and useful technology indefinitely in Incubation simply because successful maturation has shifted most of the activity into the frameworks and implementations that consume it. To me, that seems worth considering as part of the lifecycle discussion.

[swcurran]

Thanks @dmueller2001 -- a good perspective. I'll look into the graduation requirements and consider a submitting. I'd welcome help from others interested in this!