Re: Experimental did:cel Witness Service (open-source)

On Thu, Mar 5, 2026, at 10:04 AM, Filip Kolarik wrote:
> Manu, thank you. The oblivious witness concept is intriguing and holds promise for decentralized systems.
> 
> The witness service implementation was straightforward, which encouraged me to implement additional services covering the did:cel lifecycle. It binds Google KMS with did:cel, allowing anyone to host their identifiers and it contributes to greater diversity in the ecosystem.
> 
> https://github.com/filip26/iron-did-cel-witness
> 
> One of the other major did:cel features should be "infrastructure democratization". I picture an ecosystem composed of services using HTTPS endpoints, DIDComm, IFPS, or other protocols,  where you can manage mission-critical DIDs that require high protection using an enterprise-level solution with HSM protection, while other DIDs, like those related to individuals, might reside on your mobile phone, and I’m happy to contribute to this effort.

Hi Filip!

I love your simple building block implementation approach. This is exactly what we need. A bunch of small and simple libraries that operate on what I call cryptographic spaces. The tools sit at the boundary where data crosses.

I believe the last hurdle to overcome for the technologies discussed on this list is general adoption. That requires interoperable building blocks around a coherent model.

My frustration is that we have no complete coherent model in spec and code how the entire ecosystem fits together.

Everyone is implementing their own paths in their own systems and there is little effort to write and read data to the same substrate. We need to build a reference pattern that all our systems are able to integrate with. This will shift work towards finding synergy which I think is required to catalyze this new ecosystem.

I am building towards this vision of user-controlled & deployed systems. I have a vertical JS stack running from module development to running in server sandboxes and browsers with IPFS and program catalogs referencing components as the distribution mechanism.

My plan is to port your libraries to javascript and begin building what I call the "Sovereign Substrate". The idea is that it is a data space that the user controls and it starts locally in a single process and distributes to the web with adapters everywhere.

I have everything built in the open to deploy code from source to remote runtime in up to < 5 sec avoiding build pipelines for any JIT hot-reloadable code (server middleware, browser UI components, backend processes can restart too, ...).

What I am missing is expertise and bandwidth in building the cryptographic data spaces and boundary libraries. AI now allows me to port libraries but it would be nice to get actual participation.

My goals is to integrate with the VC/DID ecosystem and the Gordian Envelope system to bring both together into the same substrate.

If any of this sounds interesting I would be happy to share more of my vision and where I am at.

Christoph



> 
> Feedback is welcome.
> 
> Best regards,
> Filip
> https://www.linkedin.com/in/filipkolarik/
> 
> On Sun, Mar 1, 2026 at 10:55 PM Patrick St-Louis <patrick.st-louis@opsecid.ca> wrote:
>> If there's compatibility, I don't see why the webvh information website couldn't reference it. I'm unsure about creating a hard dependency in the specification. We use a secure peer to peer DIDComm protocol for witness requests in our implementation, and are unlikely to implement an HTTP API interface in the foreseeable future. I believe other implementers have also defined their API services for witnessing, which should be taken into consideration.
>> 
>> We debated including an API definition in the witness/watcher service, and opted to define only watchers because witness governance is outside of the WebVH spec, and implementers shouldn't be restricted by special infrastructure requirements. However as mentioned, I think providing a reference API definition could be interesting.
>> 
>> Perhaps did:cel could also include a dependency on a witness DIDComm protocol. This would also be interesting.
>> 
>> On Sun, Mar 1, 2026 at 4:40 PM Manu Sporny <msporny@digitalbazaar.com> wrote:
>>> On Fri, Feb 27, 2026 at 11:51 AM Filip Kolarik <filip26@gmail.com> wrote:
>>> > I’m excited to share an experimental witness service
>>> >
>>> > While designed for did:cel, the service can also be used to witness arbitrary events, providing a lightweight, verifiable, and high-performance proof layer for other decentralized or event-driven applications.
>>> 
>>> This is awesome, Filip! I really like the fact that it highlights a
>>> number of things:
>>> 
>>> Oblivious witness services:
>>> 
>>> 1. Can be simple and quick to build.
>>> 2. Can be cost effective to operate.
>>> 3. Can be lightning fast (with c14n templates).
>>> 4. Can leverage industry standard HSMs.
>>> 5. Can be generalized to any market vertical.
>>> 
>>> Would you have any aversion to us writing down the API for the service
>>> in a spec? It feels like it should be a separate, really lightweight
>>> spec that both the CEL spec, and did:cel depend on. I'd love to see
>>> did:webvh depend on it as well, thoughts on that from the did:webvh
>>> folks?
>>> 
>>> -- manu
>>> 
>>> -- 
>>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>>> Founder/CEO - Digital Bazaar, Inc.
>>> https://www.digitalbazaar.com/