# did:jun

## Identifier types
1. Self-certifying identifier, no initial content / genesis state. A simple public key
2. Self-addressing identifier with an initial / genesis state, breaks down into:
1. Identifier incepted with multiple keys.
2. Identifier with an initial set of Witnesses.
3. Identifier with multiple keys + initial set of witnesses.
4. Identifier with a service

## Creation
Creating a self-certifying identifier is just a matter of encoding a public key, for instance, the following DID:

`did:jun:v1:CZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM`

*todo: produce valid example using keriox*

would result in this DID Document:

{
  "id": "did:jun:v1:CZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM",
  "verificationMethod": [
    {
      "id": "#k1",
      "controller": "did:jun:v1:CZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM",
      "type": "EcdsaSecp256k1VerificationKey2019",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "secp256k1",
        "x": "WfY7Px6AgH6x-_dgAoRbg8weYRJA36ON-gQiFnETrqw",
        "y": "IzFx3BUGztK0cyDStiunXbrZYYTtKbOUzx16SUK0sAY"
      }
    }
  ],
  "service": [
    {
      "id": "#linkedin",
      "type": "linkedin",
      "serviceEndpoint": "linkedin.com/in/henry-tsai-6b884014"
    },
    {
      "id": "#github",
      "type": "github",
      "serviceEndpoint": "github.com/thehenrytsai"
    }
  ],
  "authentication": [
    "#someKeyId"
  ]
}

## Resolution

## Updating

## Deactivating

## Extension to the anchor / seal types:

Two new seal types are introduced, in addition to the existing `d`, `rd`, `e`, `el`

Example use cases / identifiers:

The idea is that a `did:jun` DID can be resolvable in an anywise / pairwise manner, depending on the included witnesses / backers (if any are present at all).

The did method builds on the KERI event types described in [KID 0003](https://github.com/decentralized-identity/keri/blob/master/kids/kid0003.md) (or version 2.6 of the paper). The following event types are used: `icp`, `rot`, `isn`. The core ideas are:

- `icp` and `rot` events are used to manage the controlling keys for an identifier. The `k` and `kt` fields are only used to manage the keys controlling the identifier. **The keys listed in the `k` field will not be included in the resulting Did Document**. Keys used for signing Verifiable Credentials / establishing encrypted communication channels are managed through anchors / seals.
- As mentioned in the previous point, this DID method would make use of the `a` field to include:
- Additional keys to be associated with the identifier. These keys will be included in the resulting DID document.
- Metadata to help locate / contact grafted witnesses.

An example inception event for a `did:jun:v0` did would look as follows:

{
    "v" : "KERI10JSON00011c_",
    "i" : "EZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM",
    "s" : "0",
    "t" : "icp",
    "kt": "1",
    "k" : ["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"],
    "n" : "",
    "wt": "0",
    "w" : [],
    "c" : ["EO"],
    "a" : [{
        "wi": "DTNZH3ULvaU6JR2nmwyYAfSVPzhzS6bZ-i0d8JZAo5CM",
        "id": "did:example:123456789abcdefghijk",
        "t":  "did"
    }]
}

### Introduced TEL Event types

A few TEL event types are introduced to help provide all required metadata / functionality to enable this DID method.

1. Key management
1. `kad` - add a new key.
2. `krm` - remove a key.
3. `krk` - change the key, equivalent to krm + kad.
2. Witness discovery
1. `wdc` - includes metadata to help connect to a grafted witness.

## Communicating the KEL

In order to discover the initial witness list / get to the identifier state, the user's KEL and TEL need to be provided / made available alongside the identifier. The two options are:

1. Include the KEL / TEL as the `?tel` and `?kel` query params.
2. Reference the KEL / TEL via a URI (e.g. IPFS hash, http endpoint).

- Initially we could include the seals about the witnesses in the event using the anchors property. The drawback is the potential size increase of the KEL. The benefit is that we do not have to share a TEL.
- We need to define an event type/ilk for the witness discovery.

Provisional Witness Discovery Event data structure.

{
  "v" : "KERI10JSON00011c_",
  "t" : "wdc",

---
**Open areas of work / next steps:**
*For Now*
- [ ] Define an initial provisional data structure for Witness Discovery Events (e.g. WDC). The structures listed in [this document](https://hackmd.io/XfdKjT3ZQDi1M6Iv3iYhbg#Registry-Inception-Event) can be used as a starting point.
- [ ] Include examples for:
- [ ] An inception event with one or more witnessess + the associated discovery metadata
- [ ] A rotation event which rotates one or more witnesses + associated metadata

*For Later*
- [ ] For the first itteration / design, the Witness Discovery Event can be included in the corresponding KEL directly (i.e. NOT using a digest seal), in future itterations we can optimize this away. A number of things need to be clarified first:
- [ ] How to correctly reference an event from the TEL in a KEL event
- [ ] How to communicate the KEL to other parties (must it be the holder who communicates it, or can it be distributed somehow else?)