This discussion will help us focus on the key requirements we need in the VID section of the Working Draft.

Darrell O'Donnell observed that the process of deciding about the acceptability of a VID is a two-part question:

1. The VID type.
2. The appraisability of the VID instance.

We want to push receivers towards the most secure VIDs. Sam Smith said that we should provide examples of the types and instances of VIDs that can prevent the most attacks. We are facing a tsunami of "edge attacks". Sam mentioned the HIPAA "Wall of Shame" showing how many breaches and the size of each. So "we are losing the battle" to protect HIPAA. That will capture all of OIDC and all of DNS.

The list we compiled is:

1. AIDs (Autonomic Identifiers) as defined by the KERI suite of specs.
   1. AIDs use the out-of-band introduction (OOBI) protocol (the OOBI spec is within the CESR spec). You need at least one VID relationship in order to set up the relationship. Once you have the first one, you can use the relationship formation protocol within the TSP to set others.
   2. The OOBI protocol is not necessarily AID-specific. It just relates an IP address with a VID.
   3. It relates 3 things: 1) VID, 2) IP address or DNS name, and optionally 3) a role (a string). The role allows the controller to organize their endpoints.
   4. APIs for KERI are based on an adaptation of the Web principle that location = service. You can query an endpoint and get the list of routes that the endpoint supports. A route is the base path of a URL (unparameterized). So a route can be used with other protocols without having to use the URL mini-language.
   5. AIDs are self-appraising, so they already satisfy appraisability. To appraise, the receiver can discover the endpoint, retrieve the KEL (key event log), and then verify the AID and the nature of its key stake. The receiver can tell the number of witnesses. KERI also has multiple duplicity recovery mechanisms. So the KEL can be appraised.
   6. KERI has two modes: direct and indirect. Either side can be either, so you can have direct-direct, direct-indirect, or indirect-indirect. The receiver just needs to know what mode the sender is in.
      1. In direct mode, the first item the sender would transmit is the KEL. The first event in the KEL has the AID and the inception event. That begins the event log. In direct mode, the AIDs are completely private. 
      2. In indirect mode, the sender is using other witnesses. So the sender assumes the receiver knows how to look up the sender's endpoint via an OOBI. Or the receiver can use a well-known endpoint. Wenjing noted that indirect mode is closer to the TSP discovery. Sam noted that, "The Web itself is a good discovery mechanism." So the Web can be used to retrieve a KEL and use that to do the appraisability. So an AID can be embedded in another DID can be used to bootstrap discovery. In indirect mode, the receiver can also verify the KEL with other witnesses.
      3. Watchers are how the receiver protects from an "eclipse attack": an attack where the only nodes that the receiver can see are from the attacker. So essentially the attacker creates a forked KEL. That's what watchers protect against. The "first seen" policy in KERI mean that an attacker must attack all watchers.
   7. The final outcome is that, the KEL verifies, and there is no evidence of duplicity, then the receiver decides based on the appraisal whether to trust the AID for the particular context.
   8. SUMMARY: To establish a VID relationship with a controller using an AID requires accessing the set of KERI API endpoints. Those endpoints can be public or private.
2. did:webs — see AID above (it is KERI under the hood).
3. did:dht — <need reference> 

   https://did-dht.com/

4. did:x509 — <reference X5VTF TF>
5. did:indy:<namespace> — <reference>

6. Open Enteprise Agent relies on did:prism - I'd love to explore how this can be used (if appropriate)

Sam Smith noted that any ledger-based DID method can use the ledger to verify key state. But if keys are compromised, the ledger cannot confer that fact.

Sam explained that a key compromise impersonation attack is now quite common. So any VID method that is based on the Web is susceptible to this attack. There is a link to the attack is in the SPAC white paper. Any protocol that is not signing messages is subject to this attack. Double-ratchet does not protect directly from the attack, but it does shorten the time window. KCI Attack:

• https://www.usenix.org/system/files/conference/woot15/woot15-paper-hlauschek.pdf
• https://www.cryptologie.net/article/372/key-compromise-impersonation-attacks-kci/

Neil Thomson:

FWIW - this might be a bit stale - I produced this 3 months ago as an object of conformity for verifiable identifiers. https://github.com/dgc-cgn/CAS-Digital-Trade-Documentation/blob/main/scheme/objects/obj-verifiable-identifier.md

Whether to adopt a VID or not depends on Risk Analysis.

If certain attacks are deemed low risk by a given eco-system, then that's their choice in terms of what VID types are acceptable.

this paper might be better though https://www.usenix.org/system/files/conference/woot15/woot15-paper-hlauschek.pdf

Wendy: Aren’t we talking about modularity and defense in depth?