Fork of github.com/did-method-plc/did-method-plc
Merge pull request #89 from did-method-plc/bnewbold/spec-core-field-terms
clarify terminology around "core data fields"
+4
-4
+4
-4
website/spec/v0.1/did-plc.md
+4
-4
website/spec/v0.1/did-plc.md
···
11
11
12
12
## How it works
13
13
14
-
The core data fields associated with an active `did:plc` identifier at any point in time are listed below. The encoding and structure differs somewhat from DID document formatting and semantics, but this information is sufficient to render a valid DID document.
14
+
The metadata associated with an active `did:plc` identifier at any point in time is listed below. The encoding and structure differs somewhat from DID document formatting and semantics, but this information is sufficient to render a valid DID document.
15
15
16
16
- `did` (string): the full DID identifier
17
17
- `rotationKeys` (array of strings): priority-ordered list of public keys in `did:key` encoding. must include least 1 key and at most 5 keys, with no duplication. control of the DID identifier rests in these keys. not included in DID document.
···
48
48
- `verificationMethods` (mapping of string keys and values): as described above
49
49
- `alsoKnownAs` (array of strings): as described above
50
50
- `services` (mapping of string keys and object values): as described above
51
-
- `prev` (string, nullable): a CID hash pointer to a previous operation if an update, or `null` for a creation. If `null`, the key should actually be part of the object, with value `null`, not simply omitted. In DAG-CBOR encoding, the CID is string-encoded, not a binary IPLD "Link"
51
+
- `prev` (string, nullable): a CID hash pointer to a previous operation of an update, or `null` for a creation. If `null`, the key should actually be part of the object, with value `null`, not simply omitted. In DAG-CBOR encoding, the CID is string-encoded, not a binary IPLD "Link"
52
52
- `sig` (string): signature of the operation in `base64url` encoding
53
53
54
54
A tombstone operation contains:
···
148
148
149
149
To summarize the process of creating a new `did:plc` identifier:
150
150
151
-
- collect values for all of the core data fields, including generating new secure key pairs if necessary
151
+
- collect values for the essential operation data fields, including generating new secure key pairs if necessary
152
152
- construct an "unsigned" regular operation object. include a `prev` field with `null` value. do not use the deprecated/legacy operation format for new DID creations
153
153
- serialize the "unsigned" operation with DAG-CBOR, and sign the resulting bytes with one of the initial `rotationKeys`. encode the signature as `base64url`, and use that to construct a "signed" operation object
154
154
- serialize the "signed" operation with DAG-CBOR, take the SHA-256 hash of those bytes, and encode the hash bytes in `base32`. use the first 24 characters to generate DID value (`did:plc:<hashchars>`)
···
163
163
164
164
- if the current DID state isn't known, fetch the current state from `https://plc.directory/:did/data`
165
165
- if the most recent valid DID operation CID (hash) isn't known, fetch the audit log from `https://plc.directory/:did/log/audit`, identify the most recent valid operation, and get the `cid` value. if this is a recovery operation, the relevant "valid" operation to fork from may not be the most recent in the audit log
166
-
- collect updated values for all of the core data fields, including generating new secure key pairs if necessary (eg, key rotation)
166
+
- collect updated values for the essential operation data fields, including generating new secure key pairs if necessary (eg, key rotation)
167
167
- construct an "unsigned" regular operation object. include a `prev` field with the CID (hash) of the previous valid operation
168
168
- serialize the "unsigned" operation with DAG-CBOR, and sign the resulting bytes with one of the previously-existing `rotationKeys`. encode the signature as `base64url`, and use that to construct a "signed" operation object
169
169
- serialize the "signed" operation as simple JSON, and submit it via HTTP POST to `https://plc.directory/:did`