edouard.paris / did-method-plc
Fork of github.com/did-method-plc/did-method-plc
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

specs: clarify terminology

bryan newbold 8c2414cb 91a930c2

+3 -3
+3 -3
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. ··· 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`