Re: [PROPOSED WORK ITEM] CEL DID Method (did:cel)

Hi Manu,

Thanks you for such a thorough response.  I wonder how you find the time…

> Hope that helps reflect on some of your thoughts, Steve... interested
> to hear what you think about all of that.

I think it’s a very sound response - cant find anything to disagree with.  Meanwhile
Noted about did:cel resolvability - it’s a parameter URL.  Store it wherever you want and change storage locations any time you like.  Doesn’t matter because what matters is the cryptographic log itself.
Agreed that one person’s “set of did profiles” is another persons suite of did methods. Again, doesn’t matter.  A few distinct did methods seems reasonable and what’s more important is that that suite of methods is perceived by the market as a useful harmonious consensus from W3C.  
Also note the distinction between did:webvh witnessing the entire document and did:cel witnessing the hash.  Intuitively the blind witness (of the hash) seems cleaner. I can't think of a business reason why you’d need a witness to review the content rather than notarise existence.  Maybe Stephen Curran as a use case for that.
Got the clarification on heartbeat as a prevention of malicious fork from an earlier compromised key.  So actually useful even in short lived did’s like one identifying a consignment because, if there’s a lot of value in that title transfer then attacks will be attempted.
Also noted that “the market” will figure out which witnesses to trust - although it would be good to have a bit of heavyweight bootstrapping.  What UN/CEFACT could do in that area is to add that GRID registrars SHOULD also run a witness service to our policy recommendation document that will emerge from the GRID project.  Just like UNTP (implementation instrument) has an associated policy recommendation (rec 49), so GRID will have much the same.  That would be a place to highlight the opportunity for GRID anchored witnesses.

So, all good - I sense a harmonious consensus on the near term horizon and a corresponding practical and valuable W3C recommendation on DIDs.

Kind regards


Steve Capell
UN/CEFACT Vice-Chair
steve.capell@gmail.com
+61 410437854



> On 20 Jan 2026, at 8:25 am, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On Sat, Jan 17, 2026 at 9:05 PM steve capell <steve.capell@gmail.com> wrote:
>> I’m interested because I have an inkling that did methods based on witnessed event logs can solve some long standing business challenges in a very robust, scalable, interoperable, and cost effective way.
> 
> Yes, to your notion that witnessed event logs can solve some long
> standing business challenges in supply chain. I would make your
> statement broader than DID Methods, though, which is what the CEL spec
> is about -- DID Documents are just one thing that has state that can
> be summarized in a CEL, but I wouldn't focus on DIDs as the enabling
> technology -- the enabling technology is a cryptographic event log
> with witnesses, heartbeats, and decentralized storage. More below...
> 
>> Does too much optionality in did:webvh present a security risk? There’s truth in that but my instinct says that it’s not black and white but rather a question of degree.
> 
> Yes, agreed, and I believe there's rough consensus that it is a
> question of degree.
> 
> At some point on one end of the spectrum, you don't have enough
> features for people to care, and then somewhere at the other end of
> the spectrum, you have too many features that can be implemented
> and/or combined in unexpected ways that scares people away.
> 
> For example, IMHO, TTL at the log-level is of questionable value (but
> it probably doesn't lead to a security concern)... however, domain
> portability does have value (and it definitely leads to a security
> concern for some use cases -- like where you definitely do not want
> domain portability to even be an option because your production
> operations people are probably going to forget to turn the feature
> on/off based on the use case). IOW, you don't even want the feature to
> be there, and if it's mandatory to implement, you don't want to NOT
> implement it and then have a non-conforming implementation.
> 
> So, yes, it's not black or white, which is why optional features get
> debated... and the more optional features there are, the more debate
> there will be.
> 
>> Someone in the meeting said “why not have a suite of quite specific profiles?” Which resonated with me.
> 
> Yes, and some might say: That's called a DID Method. :)
> 
> ... and the counter-argument is: But DID Methods can have optionality
> within them, which is also true. So, now we're just talking about what
> options are acceptable to the broadest base of implementers/deployers
> per DID Method.
> 
> There are, of course, details here that matter so if we are going to
> converge on a minimum set of DID Methods as a community (which is the
> goal), then we need to talk about those details.
> 
>> What matters is that the market sees consensus and value in the options and clear guidance on when to use which feature for what business purpose.
> 
> Yes, absolutely, this is another thing where I think there is rough
> consensus that this is the best outcome. I know others might be
> dismayed by the discussion, and it really would be good if we could
> agree on one DID Method for all of our use cases, and if we can't do
> that, then the smallest possible number to address the broadest
> possible set of use cases.
> 
> Since the early days of DIDs, the community has been pretty consistent
> that we believed only a "handful" of DID Methods would end up
> surviving long-term -- implementers only have so much time and
> attention to analyze a DID Method and tend to just use what others in
> their ecosystem are using. "More than two, but less than 10" was the
> general feeling at the time, and probably is to this day.
> 
> Yes, having 250+ DID Methods doesn't help implementers pick one, which
> is what the upcoming W3C DID Methods WG and DID Method standardization
> at DIF are attempting to address... and this conversation about
> did:webvh and did:cel is a part of that "building consensus" process.
> I'm going to respond to that particular item in a separate thread, as
> this email is already pretty long and I wanted to engage with some of
> your points without diving into any of them at depth (in this thread,
> at least).
> 
>> How to resolve a did:cel document given the did:cel identifier?
> 
> You get a DID URL with a `storage` parameter that tells you where to go:
> 
> did:cel:IDENTIFIER?storage=STORAGE_URL
> 
> There is an example of how that happens in a protocol here:
> 
> https://w3c-ccg.github.io/did-cel-spec/#did-authentication
> 
>> there seemed to be some thinking that perhaps it’s not important to be able to find that storage location from the did itself because that can be handled through some controller-verifier out of bounds path.
> 
> That might be a misperception -- it is important, but the hint is in
> the DID URL, not the DID itself.
> 
> The design decision made in did:cel was: Placing a variable storage
> location in the DID itself is probably the wrong thing to do because
> you want the DID to stay static for very long periods of time where
> the storage location could change many times throughout that period.
> It's an architectural layering decision where there is a clean
> separation between the long lived identifier and the short lived
> storage location.
> 
>> That presupposes that the controller and verifier are in some kind of direct communication (eg a holder presenting to a verifier).
> 
> No, it doesn't -- you can provide the DID URL in any field that takes
> a URL... including the credentialSubject.id, proof.verificationMethod,
> and so on. No direct communication necessary (and this is more or less
> what did:webvh has to do, too).
> 
>> How to choose witnesses (controller) and how to trust witnesses (verifier)?  It seems to me that trustworthy witnesses are pretty fundamental to both methods.
> 
> Both methods have traditionally taken different approaches to
> witnesses. did:cel requires oblivious witnesses while did:webvh had
> the witnesses actually looking at the contents of the log. did:webvh
> might change that requirement based on our latest discussion.
> 
> Remember that "trust" is wholly based on your perspective. If you are
> a verifier in Country A, which does not have a good relationship with
> Country B, you probably won't pick Country B as your sole witness.
> 
> did:cel is designed for adversarial witness networks. The more
> adversaries you can get to witness your event log, the higher the
> global trust will be in your event log. That is, if you can get both
> Country A and Country B to witness your event log, it's better than
> just getting Country A or Country B alone to witness your event log.
> 
> Ultimately, the controller wants to pick a set of witnesses that is
> going to give them the highest level of acceptance among the broadest
> set of witnesses, even when verifiers explicitly distrust a certain
> subset of witnesses.
> 
>> what stops me creating an entire 2-year event log in two seconds by choosing three buddies to act as witnesses and lie about timestamps?
> 
> Do most/all of the verifiers you will be interacting with trust those
> witnesses? If so, yes, that is a possible attack vector. :) If you, as
> a verifier, want to prevent that attack vector, you're going to have
> to insist on a larger collection of witnesses that you are pretty sure
> aren't going to collude in that way, a blockchain-based DID Method, or
> a different DID Method entirely.
> 
> Now, there are market forces that can correct lying witnesses -- if it
> ever got out that a witness was lying, they'd be put on just about
> every deny list that you could imagine. There are audits that could be
> done to assert that specific versions of "known good software" were
> being run for particular witness services, etc.
> 
>> Some kind of directory of reliable witnesses seems like a handy thing.... So the answer to the question of which witnesses do we both trust could be “anyone on the GRID”.
> 
> Yeah, that would be one strategy among many that would help the
> ecosystem, and anchoring it at the UN would be a great addition to the
> ecosystem. Amir's point about over-centralization standing, I expect a
> number of trusted institutions to publish their list of trusted
> witnesses.
> 
> We would be grateful to you for seeing what you might be able to do
> given your position as UN/CEFACT Vice-Chair.
> 
>> Other stuff.  There’s more questions like when is a did:cel a heartbeat valuable (even indispensable) and when does it not really matter?
> 
> Heartbeats matter when you want to prevent hostile storage services
> from rolling your DID history back or attackers from abitrarily
> forking your DID after they have stolen one of your keys.
> 
> You can prevent that from happening if you have some other thing in
> the ecosystem that is protecting you from that (like did:webvh
> Watchers). However, since Watchers aren't mandatory, I believe that
> did:webvh DID controller's could see rollback/fork attacks if the
> system managing the DID has a compromise of a historical key. I have
> not thought deeply about what it means to not have heartbeats and not
> have a watcher so I might have that totally wrong.
> 
> Hope that helps reflect on some of your thoughts, Steve... interested
> to hear what you think about all of that.
> 
> -- manu
> 
> -- 
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/