Re: Results of VCWG rechartering/prioritization poll

📿 could zcap-spec <https://w3c-ccg.github.io/zcap-spec/> be on the
priority list?

On the whole, I think it is very good and has been stable for a long time.
But some of the prose and the interjected 'TODO's make it seem a bit scary
to implement (imho).

It would also be good to be more explicit on the syntax of invoking via
http (dave agrees), and probably to ensure conformance with the newish RFC
9421 HTTP Message Signatures <https://www.rfc-editor.org/rfc/rfc9421.html>
(which should not take long because Manu is editor of that too).
Developers should have guidance on whether to use http headers like
`Signature:` or `Authorization: Signature ...`. I believe the latter is
what is common in zcap impls today, but the RFC encourages the former.

I'm happy to support where possible on ZCAP, which I've also been
implementing as https://wallet.storage/spec#was-authorization-profile-v0-1

It could also be valuable to liaise with the new DIF Trusted AI Agents WG
<https://identity.foundation/working-groups/trusted-agents.html> as it
spins up, which mentions ZCAP-LD in its charter
<https://github.com/decentralized-identity/org/blob/main/Org%20documents/WG%20documents/DIF_Trusted_AI_Agents_WG_charter_v1.pdf>



On Sun, Sep 21, 2025 at 10:25 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> 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/
>
>

-- 
Benjamin Goering, Software Producer
bengo.is
@bengo <https://twitter.com/bengo> - github.com/gobengo -
linkedin.com/in/benjamingoering
<https://www.linkedin.com/in/benjamingoering>