- From: Patrick St-Louis <patrick.st-louis@opsecid.ca>
- Date: Mon, 15 Dec 2025 12:30:33 -0500
- To: Filip K <filip26@gmail.com>
- Cc: Otto Mora <omora@privado.id>, Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <CAMmwNB-0rdDKgUEP_Xuu7wyhoxEiJKNCB5tpUWtr0yA12L3fwQ@mail.gmail.com>
I didn't want to side track the conversation towards webvh, only pointing out some inaccuracies in the comparisons. Myself and I'm sure other webvh folks would be more than happy to clarify some points during a call. This being said I'll try to keep this response brief so we can focus the conversation around did:cel. I'd be happy to provide numbers for production deployments but what I think is most relevant is the governance models that were able to be met through technical webvh features. The lessons learned and decision making through implementations are more valuable IMO. I'm not sure where the notion that webvh isn't compatible with did:web is coming from. Webvh is a mechanism which can be used to add a verifiable history to a web did (pre-existing or new) by publishing a log file in a location adjacent to the did document, hence the term parallel. Updates to this document will then need to be captured through a new log entry, and no longer exist in a vacuum. If this feature isn't clear from the specification (which I believe it to be), it will need to be addressed because this is core to webvh. We would need more information about the "more unified path" you envisioned, and where this is diverging with the current spec. For the portability concerns, Brian has answered this. Portability can be disabled at creation. This leaves the watchers, which I see as similar to cel storage services. While it's true that a watcher is an additional infrastructure requirement, so are CEL storage services. I think a pre-rotation commitment would be an interesting feature for did:cel. Something else I would like for did:cel is to lean in IPv6 usage for storage services. IPv6 has fantastic promise and this is a great use case. Most examples of storage services given are reliant on DNS (such as the gh pages). I'm not opposed to DNS, but if non reliance on DNS is one of the core benefits of did:cel, examples should follow suit. An additional question: Does did:cel do anything different that the current cel spec? Meaning is there additional stuff that needs to compliment the cel spec to enable this or was the current cel spec sufficient? Discovery is another topic that is currently elusive IMO. Overall I think the cel spec is valuable and having this as a first tangible use case is great. Regards, Patrick On Mon, Dec 15, 2025 at 10:21 AM Filip K <filip26@gmail.com> wrote: > On Sat, Dec 13, 2025 at 11:23 PM Otto Mora <omora@privado.id> wrote: > >> *...* >> Could you suggest what would be the economical or other type of >> incentives that would motivate an organization make a witness server >> available? >> > > Hi, > that is the question I am trying to answer as well: who would be motivated > to run witness services, ideally at little or no direct cost? > > The combination of the heartbeat mechanism and witness services is the > core innovation. For this model to work, there must be a sufficient number > of independent witness services available to support a reasonable > threshold, e.g. 3-to-10, and diversity. > > Totally blind witness services should be inexpensive to operate and carry > minimal risk. Identity managers and wallet operators are likely to be the > most motivated participants. e.g. “Use our identity manager to gain access > to a large and diverse set of witness services (and, on top of that, use > our "AI" to select the right set for you ;).” > > Verifiers and infrastructure providers may be less directly motivated, but > their participation adds diversity to the ecosystem and makes it function > effectively. > > Just loud thoughts, > Filip > https://www.linkedin.com/in/filipkolarik/ > > I have often wondered how proponents of did:keri and similar methods like >> to claim that they do not need to use a blockchain VDR, but instead they >> swap out the blockchain VDR with a network of witnesses that need to exist >> and it's not always clear what would motivate entities or organizations to >> make such infrastructure available. In public blockchains it is a bit more >> clear to me, because there is an associated transaction fee that you pay >> for submitting transactions to the VDR such that they are recorded. >> >> Thank you, >> >> Otto Mora >> >> >> On Mon, Dec 8, 2025 at 9:57 AM Manu Sporny <msporny@digitalbazaar.com> >> wrote: >> >>> Hi all, >>> >>> The DID Methods WG Charter is going up for a W3C Member vote soon and >>> one of the DID Method types it contemplates standardizing is a fully >>> decentralized DID Method. The Cryptographic Event Log[1] was adopted >>> as a Credentials CG work item earlier this year, is listed in the new >>> DID Methods WG charter, and hinted at a DID Method that was powered by >>> the technology. >>> >>> This email is to introduce did:cel, a fully decentralized, >>> cryptographic event log-based DID Method: >>> >>> https://digitalbazaar.github.io/did-cel-spec/ >>> >>> The goals of this DID Method are: >>> >>> Minimal Infrastructure - A single individual with a file hosting >>> location can create and control multiple DIDs in a way that the >>> identifiers are highly-available and globally recognized. >>> >>> Near-zero Cost - The cost to create and control multiple DIDs is not >>> burdensome to at least 70% of the world's population, which are the >>> number of people that have access to the Internet as of 2025. >>> >>> Censorship and Coercion Resistant - The oblivious witness and file >>> storage services used to manage a DID cannot censor or coerce an >>> individual or organization to any significant degree. >>> >>> No Centralization - Witness and file storage services are abundant, >>> easy to operate at scale, and are easily interchangeable if they >>> become non-responsive or compromised. >>> >>> Over the years, there are many of us that have invested in DLT-based >>> DID Methods and have not seen their usage grow at the rate we would >>> wish. There are a number of reasons for this, but many of them boil >>> down to implementation and operational complexity as well as >>> significant infrastructure and transaction costs. The did:cel DID >>> method focuses on reducing each of those costs as much as possible. >>> >>> Please take a look at the spec and let us know what you think. Raise >>> issues here if you find anything of concern: >>> >>> https://github.com/digitalbazaar/did-cel-spec/issues >>> >>> We are currently looking for support and co-editors for this work item >>> in the W3C CCG and will raise an issue to call for adoption once we >>> have a week or two of discussion on this mailing list. If you are >>> supportive of this work, please let us know via the mailing list. >>> Happy to answer questions and concerns in the meantime. :) >>> >>> -- manu >>> >>> [1] https://w3c-ccg.github.io/cel-spec/ >>> >>> -- >>> Manu Sporny - https://www.linkedin.com/in/manusporny/ >>> Founder/CEO - Digital Bazaar, Inc. >>> https://www.digitalbazaar.com/ >>> >>>
Received on Monday, 15 December 2025 17:30:49 UTC