# RWOT 12 - Next Level Secure DID:web - or adding did document updates to did:web

Exact title TBD :wink:

[Our task description](https://docs.google.com/document/d/1wLvWB5eh0vnVJg473CG5GVvxattah7PX2vaXKx3san0)

Hack MD for the actual paper: https://hackmd.io/@Echsecutor/Hks4b7Oka
This is versioned on a (at least) daily basis here: https://github.com/WebOfTrustInfo/rwot12-cologne/blob/main/draft-documents/beyond-did-web.md

## Extra Docs:

- DID method (:web + others) comparison doc: https://hackmd.io/@piafdZMCQwuxBfxK92zZhA/BJViZQuya/edit
-

## :dart: Goals of this group

- Compare existing methods
- In case we find a better solution, we will also add it here
- What are the Business needs?
- Find/define a w method which supports DID document updates
- In particular **key rotation**
- Also service updates in case the endpoints changes
- Versioning of did docs
- Which attacks do we secure against?

## :books: Resources to look at

- W3C DID Method Specification as of May 2023: [did:web](https://w3c-ccg.github.io/did-method-web/)
- LedgerDomain: [did:webplus](https://github.com/LedgerDomain/did-webplus) including Rust working code
- Trust over IP spec: [did:webs](https://trustoverip.github.io/tswg-did-method-webs-specification/)
The ToIP GitHub repo with the spec is here: https://github.com/trustoverip/tswg-did-method-webs-specification
- DID:DNS https://danubetech.github.io/did-method-dns/
- DID:github https://github.com/decentralized-identity/github-did
- DID:gitN https://github.com/dhuseby/did-git-spec/blob/master/did-git-spec.md
- Well Known DID: https://identity.foundation/.well-known/resources/did-configuration/

### [did:keri](https://identity.foundation/keri/did_methods/)
- :warning: This is not a finished did spec
- Highly Sketchy
- Essential Idea: Use a Key Event Log

### RWOT12: [did:web2.0](https://github.com/WebOfTrustInfo/rwot12-cologne/blob/main/advance-readings/did-web-2.0.md) proposal
- [Traits](https://github.com/WebOfTrustInfo/rwot12-cologne/blob/main/advance-readings/did-web-2.0.md#did-method-traits) = testable properties of did methods
- Recovery key in did doc `"recover": "[hash of the secret recovery key]"`
- Chaining to old versions
> New DID Document property, previous, an object that contains a link to the previous version of the DID document (using the self-certifying hash URL discussed above), as well as a signature over that previous URL using the Recovery Key.
- Recovery key = master key for signing the chain
- Signed did doc
- access -> hash of did doc in fragment
- did:webs:example.com#hash=12345
- or query parameter ` "id": "did:webs:example.com?hash=12345",`

---

## Relation to Git for solving the duplicity attack vector

I talked with Torsten Lodderstedt about key rotation in OIDC tech stack (similar to DID:web) ... they do long term archiving via GIT (bitbucket) for QTSP:
- Snap shot every 15 minutes
- Every snap short is written into a git
- This also works when companies file for bankruptcy
- Snapshots are being signed
- All partner have bitbucket access to yes ... partner can do git clone

This approach is being accepted by QTSPs from a compliance perspective. We should consider using it for DID:web as well. (I would like to focus on prooven and simple technology to be implemented. Maybe there is an easier solution than using git.)

Go deeper:
https://yes.com/docs/qes/2.5/index.html#_long_term_non_repudiation

# Known problems to did:web
- check the current sepc and write down the problems that are not solved
- compare these problems with the other methods and check
- think about other problems and how they can be solved (can they be solved in all situations or only in some)
- what are solved and how (if so, compare in different aspect like simplicity, speed, etc.)
- What new problems does the method bring with it
- what problems are still out there

How faimilar are the new methods compares to did:web? Can you use the did:web resolver to get the base information like "every did:webs method is also a did:web method"? If not, is it still did:web

-----

# Proposed Paper Content:

## Abstract

- Starting from did:web
- Identify + keep the good stuff
- Identify what needs to be enhanced
- Business requirements
- Attack vector mitigation
- Future-proofing
- Compare existing did:web methods / enhancement proposals
-

---

Features Roadmap:

Short-term Secure DID:web (light solution):
* Self-certifying identifiers tied to a domain.
* Web-published documents, ideally backward-compatible.
* A verifiable "microledger" combining time stamping of data and their sequencing with certainty about the data originator (DID doc controller). Microledger shall provide the entire history from DID-doc inception to recent key rotation and service endpoint configuration events.
* versionTime/versionId syntax (tbd).
* Event Transactions: A transparent history showcasing each event.
* Secure snapshotting / archiving (e.g. Git)

Long-term Secure DID:web (comprehensive)
* Implementation of Pre-rotation and PQC
* Integration of advanced KERI features, particularly those countering duplicity attacks.
* Exploration and adoption of other innovative features.

# Feedback On 19/09/2023 15:46, Stephen Curran wrote:

* AFAIU, the core idea of did:webplus is a sequence of DIDDocs that are versioned and chained together to create the history, whereas did:webs has two files published on change -- the current DIDDoc and the KERI log from which all previous DIDDocs (and other events) can be derived, and, when processed to completion, yields the current DIDDoc.

Editorial:
* While I am not a KERI expert, it is my understanding/hope that by using KERI, all of the details of the microledger are dealt with cleanly, with solid security and technical foundations. The variations (did:webplus, did:plc) have their ways of accomplishing what amounts to the same thing - in a much lighter way.
* This trade-off is as someone on the call said -- the weight of KERI vs. coming up with "new things" that are sufficient and easily understood. The specification should only use the necessary parts of KERI (e.g. the event log format and only the necessary events needed). The other parts of KERI -- ACDC, witnesses, watchers and other possibilities are other things that can be done with KERI that a resolver might want to do, but aren't needed in a Web-based DID Method.
* Multi-signature support means that a DID can be controlled in a specified way by a set of entities -- e.g. the board of a company, a partnership etc. Events in the log require transactions that meet the multi-signature needs. The multi-sig requirements manifest in the DIDDoc for use in, for example, verifiable credential scenarios. Definitely for advanced use cases.

Ah, this makes sense. Does multi-signature or threshold signature result in a conventional single-key signature that can be verified the conventional way, with the additional multi- metadata in the DID Doc, VC proof object, etc? Or is the KERI complexity mandatory for things so signed to be verified?

* Signed Files: did:webs explicitly takes advantage of the DID URL pathing to encourage the use of verifiable file publishing to enable use cases -- especially verifiable credential use cases. I think it will be a very powerful capability that is dead-simple for any Web-based DID method. We should use that to make the adoption argument compelling.
* "whois" Folder: The did:webs "whois" concept is another dead-simple thing that any Web-based DID method can use as a huge simplification for a Trust ecosystem. They enable an effective "Decentralized Trust Registry" by having issuers publish their "authorization to be an issuer" verifiable credentials given to them by siloed authorities (e.g. the Pharma industries groups that were talked about on the call). Ecosystems can define what VCs they would expect other participants to publish and discovery and verification is dead simple.

Any chance this could be a separate spec, or optional extension? I think it's great to specify the `whois` folder but not to make it mandatory for a shared/interop-layer did:webplus spec.

I'm interested in what Carsten called "KERI lite", as I've heard the term but not a definition. I think that aligns with my goal that we support "only the events to accomplish did:webs features", but I'd like to be sure. I think there could be a "did:keri" or just KERI to have all the features of KERI, but not as part of a Web-based DID Method.

Maybe if did:webs is KERI light, than did:webplus is KERI light-light? 😄

# Meetings

## 20231013

Present: Mirko, Dan, Sebastian, Hans

* We move the paper to github: https://github.com/Echsecutor/beyond-did-web/
* We move and assign all HackMD comments as Github issues.
* Should we withdraw our `DID Web with attached validation` proposal from the paper?
* We agree that we may leave it in if it does contribute something, albeit small.
* Next meeting: 27th October 11:30 CEST

## 20231027

Present: Mirko, Dan, Sebastian

### Updates to did:webs and did:webplus since RWOT

`did:webs` and `did:webplus` are moving targets: Both have been updated substantially since September.

* `did:webs`
* It is now stored as a fully compatible `did:web` inside `did.json` file, and only converted to `did:webs` for KERI processing.
* Added details on DID document metadata fields.
* Added privacy considerations.
* Maybe more...
* `did:webplus`
* ...

### Usign common Markdown formatting

We already have some merge conflicts due to use of markdown linters/formatting tool.

The recommended approach is:

1. Install pre-commit: `pip install pre-commit` or `brew install pre-commit`
1. Pull latest main branch
1. Install the hook (config lives in `.pre-commit-config.yaml` file): `pre-commit install`

Your git commits will now be formatted when you execute `git commit`.

### Next meeting: 10th November 11:30 CET

Little progress has been done, we push the deadline of our tasks by 2 weeks: 10th November.

Please complete your tasks before then and read the paper.
We could then meet and organise the last few tasks before publishing.

## 20231110

Present:

Agenda:

* Decide final tasks before publication.