DIDs: did:webvh

[wenjing]

DIDs: did:webvh: https://identity.foundation/didwebvh/
supprted and used for all M2-2 demos and tests.

[pohlm01]

@wenjing I created a branch to develop and test the did:webvh integration. As discussed, my first approach is to use the Python implementation for generation first.
For resolving and verifying, I rely on the Rust implementation from the Decentralized Identity Foundation.

The did-webvh branch contains code that can successfully resolve and verify did:webvh using the Rust implementation of the Decentralized Identity Foundation.

Additionally, it contains an - admittedly lengthy - description of how to create a did:webvh with the Python implementation. I'm wondering a bit about how to proceed from here. The described procedure with the Python implementation is certainly not optimal w.r.t. usability. At the same time, the TSP SDK must support resolving did:webvh, but I would assume that creation of those is not its main concern. Unfortunately, the generation of did:webvh is quite an involved process, which means that we need to invest a decent amount of resources if we want to implement it as part of the TSP SDK to improve usability. At the same time, we run into the risk of having an outdated, incompatible implementation as the webvh specification evolves.

Maybe you can have a look at the mentioned description and let me know if we should prioritize an implementation of webvh generation. If so, we should consider developing this in the (currently empty) provisioner directory of the Decentralized Identity Foundation repository.

[wenjing]

Maybe another way to clarify is to take a step back and look at what we need to have for demonstrating TSP SDK:

(0) First is creation of a DID - for testing and demo purposes.

We should modify the "tsp create" command so that it can be used to create various types of VIDs.

i.e. a unified "tsp create --type {did:web | did:webvh | did:peer ... } just for illustration.

this is just to make the cli structure simpler than it is today.

(1) Now we need to implement "tsp create --type did:webvh" as a new type (the other two already exist).

One half of this is similar to did:web and can be reused.
The other half is verifying its history (aka event log or key event log). The location of the log should be also located in did:teaspoon.world - or if you choose to use github - then maybe use a URL from did:teaspoon.world.

(2) This new type of DID also supports a new operation that the python implementation calls "update", for example for key rotation.

So we need a new CLI command: maybe something like "tsp update" ...

(3) Verify must be enhanced to handle extra verification of the history - for the receiving end verification by the SDK, this would be in rust.

(4) Same for CLI "tsp verify" command from the initial sender used by the demo. This is ok to be in python.

I may still be missing something, e.g. all the show/display functions also need to be updated to show/display the extra information.

I am not sure if there's anyway to be any less than the above list?

[wenjing]

I'm not sure how feasible - but a possible alternative is to use the current did:web implementation and enhance it with history (creation, verify, and update operations).

The benefit is that you already have most of the operations, and wallet, and did support system. We could still use the python demo as reference and maybe even reuse some basic modules?

[pohlm01]

a unified "tsp create --type {did:web | did:webvh | did:peer ... } just for illustration.

Yes, I'll do this still. Just wanted to get the functionality ready first. Thanks for the reminder.

did:webvh is a new type of DID, it is not did:web. You should implement a new one, not using the same CLI

Yes, also true. I used it for this proof-of-concept, as did:webvh essentially embeds a did:web in a verifiable history.

Verify must be enhanced to handle extra verification of the history - for the receiving end verification by the SDK, this would be in rust.

✅ This already happens

all the show/display functions also need to be updated to show/display the extra information.

True

In essence, I would continue by automating the manual procedure. This requires a working Python installation of the computer that we execute the tsp create --webvh command.