Re: Results of VCWG rechartering/prioritization poll

On Sat, Sep 20, 2025 at 1:25 PM Manu Sporny <msporny@digitalbazaar.com> wrote:
> I've also attached the raw data with PII removed from each entry.

There was also a section for people to offer suggestions for other
things to standardize. I am including that input below (with as much
PII removed as I could w/o invalidating the comment). Every paragraph
is a comment by a separate individual:

I think we should remove all mechanisms that could be used to
implement phone home, especially the credentialStatus property. The
specification should be updated to ensure that wallets can get proofs
of non-revocation for distribution along with the unrevoked
credential, rather than communicating a service endpoint to the
verifier and expecting the verifier to go perform that check. This
particular fix will address both phone home problems and the long term
surveillance enabled by empowering every verifier to monitor the
credentials' status long after the initial disclosure by the holder.

https://cyberphone.github.io/sd-experimental/doc/

Trust chains. Similar in intent to IETF ACDC but more tailored to
VCDM. A formalised way to follow a series of cryptographically linked
claims in different credentials. For example did:web:123 is issuer of
an invoice. But did:web:123 is also the subject of a business
registration VC issued by a national authority that attests to the
fact that did:web:123 is also registered business ABC. Trust “lists”
don’t work for this as they would be too big and change too fast

Wallet Attached Storage is becoming a necessity for advancing EDU

Claim 169 – QR Code Specification - a) Reference: MOSIP Claim 169
Specification (https://docs.mosip.io/1.2.0/readme/standards-and-specifications/mosip-standards/169-qr-code-specification)b)
This specification has already been authored by MOSIP. It defines how
QR codes can be used for encoding and sharing verifiable credentials.
We consider this important for the VC ecosystem as QR codes are a
widely adopted, user-friendly, and offline-capable mechanism for
credential exchange. Other Potential Areas: a) Attenuated Delegation
via VCs – This would allow a credential holder to delegate limited
rights or claims to another party, which could have significant
real-world applications (e.g., caregivers, guardianship, enterprise
workflows). b) Authorization for Posthumous Credential
Management(Credential Management After Death) – This addresses
scenarios where a user has passed away, and their credentials may need
to be revoked, archived, or securely transitioned. This is still
exploratory, but it highlights an important trust and governance
challenge for the VC ecosystem. Our organization (MOSIP) is prepared
to implement this above potential areas specification, and if there is
no other active effort within the ecosystem, we are willing to
volunteer as editors as well. At the same time, we welcome inputs and
collaboration from other stakeholders.

Just putting it out there as a Hail Mary 😅: ZCAPs! I would give this
a 4/5 on the importance scale and I plan to integrate ZCAPs into my VC
API technology soon. On that note, I would volunteer to be an editor
on this spec, ideally with support. In the meantime, I am looking to
understand what are the main roadblocks that are causing friction at
the moment.

https://agentnetworkprotocol.com/en/docs/

(SPARQL) Query Interface for Verifiable Credentials. This is maturing
research (https://www.overleaf.com/read/xnfbbfntntmf#902299 - and
circuit implementations now exist). This is not yet a CCG incubated
specification. I am volunteering to be an editor.

VC for agentics, LLM/RAG for DIDs and VCs - this is my primary
interest these days.

Received on Sunday, 21 September 2025 16:22:07 UTC