Re: Results of VCWG rechartering/prioritization poll

On Sat, Sep 20, 2025 at 3:47 PM Christopher Allen
<ChristopherA@lifewithalacrity.com> wrote:
> I don't quite get the results — victim of participation bias I suspect (i.e. people who participated before feel a commitment to participate again, even if they don't have time).
> All seem to be roughly equally important within some standard deviation. So what did you learn?

Yes, well, this is why I mentioned that the results are open to
interpretation :). I, personally, found the results very useful; they
clarified a number of open questions I had and addressed some concerns
around echo chamber effects that most every WG falls victim to. Here
are some of my take-aways, though I expect others might bring a
different perspective when analyzing the results. Apologies in
advance, this is going to be long...

Number of responses: Keep in mind that when W3C sends these sorts of
polls out to members, you're lucky to get between 10-20 responses and
we received around 40 responses. So, solid turn out from people that
understand what the technologies can do for the ecosystem, from a
variety of market verticals; the results are statistically sound.

Deference to the VCWG: I was a bit disappointed by organizations that
have VCs in production, or nearing production, that couldn't find the
time to directly answer the poll. I expect they're busy or just
presume the right thing will happen without their involvement. "You
guys (the VCWG) seem to have it under control, keep going!" <-- got
more than a few of those sorts of responses to my request to have them
fill out the poll, which doesn't help us prioritize anything, or
demonstrate (to W3C Membership and Management) that there is a bigger
ecosystem that cares about building on this stuff. People just assume
the right thing is going to happen without their input, or the
organization is so secretive about their plans that they don't even
want to be seen answering a poll. It's a bit silly, but I do
understand that some of these folks have a C-Suite that they have to
consider when responding to polls.

Participation: There were far more people that have said they want to
participate in the rechartered VCWG than I expected. Now, do I believe
that all of them will? No... but there is enough repeat interest in
the global standardization work around VCs that we have a strong case
that the rechartered WG will have enough participation from industry
and implementers.

Editors: We also had more firm commitments to be Editors, by people
that know what the role entails and have demonstrated contributions
over the last two years, for us to NOT be starved of Editors this time
around (like we were during the last VCWG). Even if only half of them
contribute, we're going to be in good shape.

Implementations: There was also enough commitments to implement or use
the specifications where we are on solid ground with every incubated
specification, though some clearly have more support than others. More
on that below.

Wireless: This was the work that had the weakest support, which is not
surprising because most people expect to have a network connection
when exchanging digital credentials. The folks that needed this stuff
were the folks that expected to have to operate in an offline capacity
-- for example, the first responder work... and that is a very small
part of the VC ecosystem. There was still enough support to do the
work, but I expect this to be among the lower priorities. The fact
that Apple still prevents NFC usage on iPhone and Safari also isn't
giving people much hope in this feature working on Apple devices.
There's a good article about how this came to be from one of the chief
standards architects at Google and now Microsoft here:
https://infrequently.org/2025/09/apples-crimes-against-the-internet-community/

VC API for Lifecycle Management: This was the work that had the
strongest support (though there were others that came close), with no
one saying it was not important or weakly not important, and more than
half of the people rating it as strongly important work. This was the
result I was most surprised by as I didn't think the market understood
the lock-in implications with existing digital credential delivery
solutions... but it seems that people do understand, which would show
a deeper understanding of potential vendor-lock dangers than I had
expected.

Render Methods: There was strong support for this, mixed with a decent
chunk of people that thought the work unimportant. My expectation is
that those that don't think Render Method is important might not have
had to deal with rendering a broad spectrum of VCs. People creating
wallets and people trying to bridge VCs to traditional PDF-based
delivery mechanisms were the ones most likely to prioritize this work.

Confidence, Barcodes, Refresh, Verifiable Issuers/Verifiers: Each of
these had roughly the same level of support, people participating to
be Editors, and people commiting to implement. Whether they get done
or not will be largely driven by people that show up to do the work.

Quantum-Safe Data Integrity: This had very strong support, and
absolutely zero people that volunteered to be Editors on the
specification. The current Editors of the specification didn't fill
out the poll, nor has there been adequate progress made on the
specification. So, the community feels very strongly that this work
needs to be done, and there is no one to do the work. In reality, this
is not a difficult specification to do, and I expect it'll get done in
time, but this was another result that was surprising to me.

Everything else: There were a number of comments on other work that
the group should focus on that were interesting -- pushing wallet
attached storage / EDVs and ZCAPs forward is important. Claim 169 and
vc-barcodes have significant use case overlap. Trust chains and
Verifiable Issuers/Verifiers have significant use case overlap.
Figuring out a way to do scalable proof of non-revocation is really
important. VCs/ZCAPs use in AI Agents is an interesting area that we
should explore. The SPARQL and SPARQL-ZK stuff provides a really
interesting LongfellowZK-like approach to querying VCs... and of
course, MOSIP is involved in a lot of work that the community needs to
get more involved in because of the sheer number of people that MOSIP
reaches around the world. There is no shortage of work to be done or
interesting areas to explore. We suffer from not enough Editors and
others pushing the work forward in parallel (but that's just about
every standards initiative on the planet, so we're not alone in this
particular challenge).

> I am more interested in knowing which truly are the most important, or have the greatest chance of completion given sufficient commitment.

I think most of the specs have a very good chance of completion of a
minimal viable specification given barely adequate commitments. This
is because most of these specs have been over-incubated, with a fair
number of them deployed to production already. We are no longer
leading production deployments of incubated technologies, we're
trailing production deployments... sometimes by years.

Some would argue that this is exactly where you want to be when you go
to standardize something (though, I don't share that opinion). I think
we're behind the curve, partly due to standards politics, but mostly
due to a lack of people processing PRs at a rapid enough clip. I'll
also note that we haven't felt the need to rush half-baked solutions
to market like some of the other standards activities in the space.

The specifications that are most at risk now are:

VC Wireless because of other higher priorities in the ecosystem and
Apple's malicious compliance related to NFC and Bluetooth support in
Safari and their OS platforms.

Quantum-Safe Data Integrity Cryptosuites because of a lack of Editors,
and more importantly, because it can't do unlinkable disclosure yet
(which is a much bigger problem).

The specifications that are at a medium risk are:

Verifiable Issuers and Verifiers because there seems to be fundamental
disagreements on centralization / decentralization and how trust
should be established in ecosystems that contain tens to thousands of
issuers. We're actively working through those problems now, though,
and I don't expect it to drag out for more than a few months at most.
We wouldn't promote the work until we get to a cohesive architecture,
and once we do this, the spec will be at a low risk.

VC Barcodes because of the dependency on CBOR-LD happening in a different WG.

The specifications that are least at risk are:

Render Method, Confidence Method, and VC Refresh, because there really
isn't much to them. Never underestimate our propensity to spend months
on esoteric corner-cases, though. :)

VC API for Lifecycle Management because we've been incubating it for
3+ years, have had variations of it in production for years, have
enough independent implementations, have a cohesive group building the
spec, and are hitting a Candidate Recommendation level of stability
before even entering the WG.

If I had to guess at what the prioritization could be to maximize
chances of success, it would be in this order:

1. VC Confidence Method
2. VC Render Method
3. VC API for Lifecycle Management
4. VC Refresh
5. VC Barcodes
6. Verifiable Issuers/Verifiers
7. Quantum-safe Data Integrity
8. VC Wireless

In any case, that's my interpretation of the poll results. I'm sure
there are other valid ones given differing perspectives.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/

Received on Sunday, 21 September 2025 17:22:25 UTC