# Peer DIDs with KERI

Peer DIDs were invented before KERI was formally described. Once KERI came along, it became clear that KERI is a more sweeping generalization of the same principles that informed most of the peer DID design. Peer DIDs embody the main principles that KERI advocates, but use just a subset of KERI's features. This means that we can redefine peer DIDs in terms of KERI. The benefits of doing so are:

* The peer DID spec can be much, much simpler.
* Peer DIDs get an upgrade path.
* KERI gets added momentum.
* Communities can come together.
* The DID method landscape can consolidate.

This document is a first cut at redefining peer DIDs this way.

## The differences

* Peer DIDs use exactly and only the agents of the peers as witnesses. In a pairwise relationship between Alice and Bob, this means the witnesses might be Alice's cell phone, laptop, and cloud agent -- plus Bob's tablet and desktop. No witness outside the control of the peers (whether blockchain or not) is allowed.
* Peer DIDs conflate the management of signing keys/authenticness with the management of encryption keys. KERI concerns itself only with the management of signing keys.
* Peer DIDs can be used in static mode (no changes allowed after creation). KERI can be limited to only the inception invent, but I think there is no formal way to express the intention of staticness?
* Peer DIDs define a CRDT-oriented protocol for gossiping deltas. KERI doesn't describe how communication happens; it only says what should happen when data arrives.
* Peer DIDs allow a DID value to convey initial state (keys other than signing, and even enpoints) without losing the self-certifying property. KERI models these as post-inception events. This is much cleaner, but is problematic from a communication standpoint if there's only one chance to communicate your DID to another party.

## A next-gen peer-DID spec
* Separate encryption keys from signing keys.
* Formalize in KERI how to declare that a DID will never change after inception.
* Figure out how to express post-inception events in a KERI did value without losing the self-certifying property.
* Separate out the protocol for gossiping DID state among peers (put it in a separate doc and incorporate by reference), and base it on DIDComm v2 gossyp.
* Decide whether to keep SGL rules (which allow changes to authorizations other than for signing keys). Can we replace them with KERI m-of-n support?

## Comments from Signal

> Regarding initial state being anchorable: I get how this solves the problem from a trust perspective, but it doesn't solve it from a communication perspective. The anchored content still has to be communicated. So I need to describe how collateral content (e.g., endpoints in a DID doc) can be gossiped over the same channel, *at the same time*, as KERI events. Do you agree with this analysis?

At least for service endpoints, KERI has a solution that is outside KERI per se. Its called an OOBI (Out of Band Introduction) that makes a connection between a KERI AID and a URL. The URL is queried for the KEL that includes the information needed to authenticte and authorize the endpoint in the URL. OOBIs may forward so if the endpoint changes the old endpoint just returns an OOBI for the new endpoint etc.

In other words the missing piece OOBIs provide to KERI is discovery. And KERI doesn't need some other authoritative mechanism for discovery, It just needs a verification policy for what is discovered. So if I have information that is anchored that needs to be discovered then I create an OOBI that tells someone where to go to find that anchored information and verify that it is indeed authentic, authorized, authoritative by virtue of being anchored.

Many use did:docs as an authoritative mechanism. KERI uses did:docs for one thing only and that is OOBI discovery which is not authoritative in and of itself but leads to an authoritative mechanism that can be verified. The authoritative mechanism is the KEL (or microledger in peer:did parlance). A did:doc is not authoritative in KERI.

The beauty of OOBIs is that any existing web discovery mechanism can be leveraged. The worst that can happen is the discovery fails to produce verifiable information. But because all successful discovery ends with verifiable information there are no hijacks or security problems only availabliity problems and sufficient redundancy solves availability problems. So instead of or in addition to did resolvers, we can use web search engines to publish OOBIs for service endpoints, or .well-known urls, or blog posts or QR codes, whatever. Any existing web mechanism for publishing information becomes a potential OOBI source.

At one point we started down the path of using a DHT for global discovery with KERI but then I realized that all I needed was an OOBI that was in a web searchable location. I could just DuckDuckGo (Google) the AID to get its service endpoints.

The mechanics of the Issue Hold Verify model mean that further discovery of other related information besides the OOBI can be accomplished through percolation, no global discovery mechanism needed besides OOBIs and web search. For interoperability reasons we can publish OOBIs in a did:keri did doc but the did:doc is not considered authortative and does not need to be secure by itself. The authoritative stuff is anchored to the KEL discovered via the OOBI.

> I am going to start on such a doc.

> Did you see my question about replacing SGL rules with KERI m-of-n support? I think I can do this, but I don't know for sure. Is it the case that the only way to decide is to dive deep into the KERI spec and carefully analyze? Or do you have something about m-of-n support that's more accessible than the full spec?

I am not sure I fully understand your question. KERI directly supports signing thresholds for KERI events. KERI also supports delegated identifiers. So in many cases what one might solve using SGL (simplified grant language) to authorize a different identifier to do something could be accomplished by delegating that identifier and then using a threshold of signers to authorize the delegated identifier.

The chaining logic of ACDC also can be leveraged. I don't think this replaces the generality of SGL. I think that SGL could be used to formalize the validation logic for chained ACDCs. Ie what does the validation chain have to look like and the SGL rules for it to be valid. But I am not familiar enough to do more than speculate.

To be clear we are talking about two complementary delegation mechanisms. Chains of delegated identifiers and chains of delegated ACDCs. A delegated identifier is a non-specific grant of signing authority. A delegated ACDC is an exercise of a grant of specified signing authority to grant even more specified signing authority. They work well in combination. So you can have both delegation of generic authority via delegated identifiers and delegation of specific authority via delegated ACDCs. I don't beleive that SGL is applicable to delegated identifiers because the signing authority is unconstrained except for the threshold but SGL may have application to delegated ACDCs which could benefit from more complex constraints. But the use cases may be that you don't need SGL at first and can be a later enhancement.

KERI signing (which includes signing of delegations) supports two types of thresholds. The first is a simple integer m-of-n. The second is an ordered fractionally weighted threshold that can have AND clauses. To satisfy a given clause the signers who sign must have weights that sum to 1 for every ANDed clause. So for example one could have the single clause threshold:

[1/2, 1/2, 1/4, 1/4]

with indexed signers indicated by their offset in a signers list of public keys e.g. 0,1,2,3

So if signer 0 and 1 sign then their weights sum to 1 and the threshold is met. Or if any combination of one of signer 0 or 1 and both signer 2 and 3 sign then the threshold is also met.

The following is a two clause threshold.

[(1,1), (1/3,1/3,1/3,1/3,1/3)]

Satisfaction happens if either signer 0 or 1 sign AND any 3 of signers 2-6 sign.

An M of N threshold is equivalent to a single clause with N weights each of value 1/M.

So one could express quite complex authorization threshold logic given fractionally weighted signing thresholds across multiple layers of delegated identifiers that are used to issue and/or present delegation chains (trees) of ACDCs without ever employing anything like SGL. But formalizing authorization logic that is even more expressive via something like SGL could be useful but may not be necessary.

Currently we have not introduced any normative modifiers on the links of ACDC provenance chains. We are currently assuming AND logic across all links of all branches of a provenance tree. We could introduce specified logical modifiers to each link in a chain so that provenance trees are combinational logic trees of ANDs and ORs for example. With fractionally weighted modifiers we could model any type of logical inference. This simple change might provide functionality that subsumes much of the functionality of SGL.