- From: Markus Sabadello <markus@danubetech.com>
- Date: Sat, 3 Jan 2026 10:39:57 +0400
- To: public-credentials@w3.org
- Message-ID: <82236d8f-54fb-4126-9b8a-987470cd73bc@danubetech.com>
Yes, did:scid should be mentioned in this context.. We have done a demonstration where did:scid can use different verifiable history formats (webvh, webs) and different ways of finding the log (via HTTPS, or DID URL, or Hedera URL, etc.). There is a DID parameter called "src", which seems to be pretty much the equivalent of "storage" in the did:cel specification. Here are some examples and a working demo: https://github.com/danubetech/uni-resolver-driver-did-scid?tab=readme-ov-file#example-dids-and-did-urls And a video with some explanation: https://www.youtube.com/watch?v=bO5CbSPAS-k Not sure what to do about the apparent situation that there exist now these various different formats for verifiable history logs (webvh, webs/KERI, CEL), needs more discussion I guess to see if alignment is possible at this stage... Markus On 12/23/25 2:01 AM, Stephen Curran wrote: > It's a reasonable idea. Since the log defines the verifiable history, > independent of discovery, the log can be stored in different places > and processed consistently. > > The folks at Affinidi/First Person Project that have implemented the > did:scid:vh spec have been able to show exactly that is possible -- > although it becomes a bit "meta-meta". "did:scid" itself is a called a > meta model. > > Boiled down, that implementation uses the did:webvh log format for > DIDs published in different places -- web servers, databases, > blockchains, etc. The DID itself has no discover data in it (just the > prefix and the SCID), and the location is determined in other ways > that enable retrieval of the Log (e.g. query parameter, known > registries, etc.). Once the Log is retrieved, the same did:webvh > rules for the processing of the verifiable history are executed to > verify/resolve the DID Doc. > > On Sat, Dec 20, 2025 at 6:52 PM Michael Herman (Trusted Digital Web) > <mwherman@parallelspace.net> wrote: > > Stephen, I'm wondering if this conversation is beginning to > suggest that did:webvh become a DID metamethod? Some of Manu's > comments steered me this direction. did:webvh becomes the metaspec > for an entire family of methof features. > > Then stakeholders can carve out the specific did:webvh DID method > *profile* that meets their specific requirements e.g. the > did:webvh CEL DID method profile. > > Food for thought, > Michael Herman > Decentralized Systems Architect > Web 7.0 / TDW AgenticOS™ > > > > Get Outlook for Android <https://aka.ms/AAb9ysg> > > ------------------------------------------------------------------------ > *From:* Stephen Curran <swcurran@cloudcompass.ca> > *Sent:* Wednesday, December 17, 2025 5:50:48 PM > *To:* Patrick St-Louis <patrick.st-louis@opsecid.ca> > *Cc:* Filip K <filip26@gmail.com>; Otto Mora <omora@privado.id>; > Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG > <public-credentials@w3.org> > *Subject:* Re: did:cel - a cryptographic event log-based DID Method > > Hi all, > > I wanted to add my perspective as an editor of the did:webvh spec > on the recent did:cel announcement and this discussion. Given how > close the two methods are in design and intent, I’m concerned > about the risk of unnecessary fragmentation, and I’d like to share > a few technical observations—especially where did:webvh can > readily incorporate ideas introduced by did:cel and its perceived > shortcomings. > > I've taken a look at the did:cel spec and this email chain and > have these thoughts on the differences, focusing on the new > features and the "did:webvh" shortcomings from Manu's emails on > this chain. > > On the "new" features of did:cel and their relevance to did:webvh > > * The "heartbeat" idea is useful and an easy addition to > did:webvh because of the existing "parameters" concept, > allowing the DID Controller to commit to a maximum time > between Log Entries and defining what a resolver should do it > that commitment is not followed. It does require a spec change > for the next version but very easy to both spec and implement. > I don't think that there are "differing philosophies in play". > We just didn't think of that feature, we like it, we'll likely > add it. > * Making the DNS part of a did:webvh DID optional is a topic we > have discussed several times in the did:webvh Working Group > and are already considering for the next version. As the > verifiability of a did:webvh starts with the SCID, the DNS > portion is not so much a "hard requirement" (as Manu puts it) > as for ease of discovery. We also think that a DID without > discovery information is "not as clean as we would like" > (again, as Manu puts it), but there are certainly use cases > where it would work -- peer DIDs, ecosystems where a DID > repository is in a known place (did:plc), and the query > parameter approach as used by did:scid and did:cel. > * Oblivious witnessing: Super interesting to think about. > did:webvh has deliberately made the technical approaches > simple/clear and left governance up to the ecosystems using > did:webvh. Technically, did:webvh supports exactly "oblivious > witnessing" as described by the did:cel spec -- the witness > generates a proof of the hash of the log entry. That said, we > did put in the spec that the witness "must verify the log > entry being witnessed", but we can (and will likely) remove > that line, as that is a governance -- and we should not > dictate that. With that, we have oblivious witnesses. > > So these are all easy changes to the did:webvh spec. Requires a > new version, but easily fitting in the design and we definitely > appreciate the ideas! > > On some of the comments from Manu earlier in the chain about > did:webvh shortcomings: > > * "did:webvh identifiers are not stable". If a did:webvh DID is > portable and "moved", it is by definition a new DID, but > retains its SCID and verifiable history. This opens new use > cases (porting the DIDs reputation when moving DID publishing > platforms) and eases the transition when its storage location > must change. Portability is thus an optional feature, not a > bug. Counter -- what happens when a did:cel uses the > ?storage... form when issuing millions of credentials, and the > storage location goes away? > * "did:webvh has pre-rotation commitments". That is a feature > that did:cel should consider. Easy to specify, optional, and > adds security -- if it is wanted/needed. > * "did:webvh requires heavier, stateful infrastructure > (witnesses, domains, and watchers)". Leaving domains aside > for now, did:webvh does not require that infrastructure -- it > is up to the ecosystem using did:webvh. For ecosystems that > require external verification, and longevity (decades), > did:webvh provides technically simple approaches that enable > ecosystems to decide on how to use (or not) those features. > o If an ecosystem (such as the Pharma industry) requires > that watchers be in place for decades in case the DID > Controller goes out of business, did:webvh gives them a > method to do so. > o If an enterprise wants to apply governance/policy rules > about DIDs published by their sub-entities, they can > require they witness DID Log Entries before publication > (as BC Gov is doing now with did:webvh). > o Regarding domains -- did:cel acknowledges that "storage" > is necessary--some place to store the DID Doc. That's > infrastructure and did:webvh's can be just as light or heavy. > * "the use of JSON Lines requires state". This is a benefit -- a > DID resolver can choose to trade off state for speed with JSON > Lines. With did:cel's structure, there is not such an option > -- you have to retrieve/process the entire log. > o That said, we're likewise pretty happy with the > performance of did:webvh -- here's a benchmark for a 10 > year-old DID, updated monthly, with multiple witnesses: > https://didwebvh.info/latest/faq/Performance/ > * "did:webvh...fully backwards compatible set of extensions to > did:web" -- I'm not sure where that came from. Here is what we > did do: > o Put no constraints on the DID Doc contents -- the DID > Controller can put anything they want in the DIDDoc. Same > as did:web. > o Make it so that there is a mechanical transformation to go > from the location of a did:web DID Doc to a did:webvh DID > Log (literally -- "add an 'l' to the end of the HTTP URL > path"). That allows a publisher of a DID to publish both, > and a resolver to check to see if a did:web has an > equivalent did:webvh that it could use to further verify > the DID. > o A DID Controller can easily transition to from did:web to > did:webvh by publishing a did:webvh and applying the > mechanical steps to publish the corresponding did:web in > parallel. > > I hope we can get together and discuss these in the future -- > hopefully in a W3C DID Methods Standardization Working Group. > > On Mon, Dec 15, 2025 at 9:32 AM Patrick St-Louis > <patrick.st-louis@opsecid.ca> wrote: > > 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/ > > > > -- > > Stephen Curran > Principal, Cloud Compass Computing, Inc. > > > > > -- > > Stephen Curran > Principal, Cloud Compass Computing, Inc. >
Received on Saturday, 3 January 2026 06:40:06 UTC