commit 60e815821ddb077ce8157534341eb9abda6ef708 · edouard.paris/did-method-plc

+12 -2

README.md

···

20
20

21
21

- `did` (string): the full DID identifier

22
22

- `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.

23
23
-
- `verificationMethods` (map with string keys and values): a set of service / public key mappings. the values are public keys `did:key` encoding; they get re-encoded in "multibase" form when rendered in DID document. the key strings should not include a `#` prefix; that will be added when rendering the DID document. used to generate `verificationMethods` of DID document. these keys do not have control over the DID document

23
23
+
- `verificationMethods` (map with string keys and values): maps services to public keys, stored in `did:key` encoding. The service id strings should not include a `#` prefix; that will be added when rendering the DID document. used to generate `verificationMethods` of DID document. these keys do not have control over the DID document.

24
24

- `alsoKnownAs` (array of strings): priority-ordered list of URIs which indicate other names or aliases associated with the DID identifier

25
25

- `services` (map with string keys; values are maps with `type` and `endpoint` string fields): a set of service / URL mappings. the key strings should not include a `#` prefix; that will be added when rendering the DID document.

26
26

···

32
32

33
33

Note that `rotationKeys` and `verificationMethods` (signing keys) may have public keys which are re-used across many accounts. There is not necessarily a one-to-one mapping between a DID and either rotation keys or signing keys.

34
34

35
35
-
Only `secp256k1` ("k256") and NIST P-256 ("p256") keys are currently supported, for both rotation and signing keys.

35
35
+
Only `secp256k1` ("k256") and NIST P-256 ("p256") keys are currently supported for rotation keys, whereas `verificationMethods` keys can be any syntactically-valid `did:key`.

36
36

37
37

### Use with AT Protocol

38
38

···

92
92

Rotation keys are serialized as strings using [did:key](https://w3c-ccg.github.io/did-key-spec/), and only `secp256k1` ("k256") and NIST P-256 ("p256") are currently supported.

93
93

94
94

The signing keys (`verificationMethods`) are also serialized using `did:key` in operations. When rendered in a DID document, signing keys are represented as objects, with the actual keys in multibase encoding, as required by the DID Core specification.

95
95
+

96
96
+
Although `verificationMethods` signing keys can be of any key type (unlike rotation keys), they must still be syntactically valid. i.e. They must have a `did:key:` prefix, followed by a `base58btc` multibase string.

95
97

96
98

The DID itself is derived from the hash of the first operation in the log, called the "genesis" operation. The signed operation is encoded in DAG-CBOR; the bytes are hashed with SHA-256; the hash bytes are `base32`-encoded (not hex encoded) as a string; and that string is truncated to 24 chars to yield the "identifier" segment of the DID.

97
99

···

407
409

- MIT license ([LICENSE-MIT](https://github.com/ipfs/kubo/blob/master/LICENSE-MIT) or http://opensource.org/licenses/MIT)

408
410

409
411

Downstream projects and users may chose either license, or both, at their discretion. The motivation for this dual-licensing is the additional software patent assurance provided by Apache 2.0.

412
412
+

413
413
+
## Changelog

414
414
+

415
415
+
### 2025-06-05

416
416
+

417
417
+
- `verificationMethods` keys may now use any syntactically-valid `did:key:`, regardless of key format (allowing e.g. `ed25519` keys). Rotation keys are not affected by this change, the original format constraints still apply.

418
418
+

419
419
+
- A total limit of 10 `verificationMethods` (per DID) has been added.

+12 -2

website/spec/v0.1/did-plc.md

···

       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.

     

       18
       18
       -
       - `verificationMethods` (map with string keys and values): a set service / public key mappings. the values are public keys `did:key` encoding; they get re-encoded in "multibase" form when rendered in DID document. the key strings should not include a `#` prefix; that will be added when rendering the DID document. used to generate `verificationMethods` of DID document. these keys do not have control over the DID document

     

       18
       18
       +
       - `verificationMethods` (map with string keys and values): maps services to public keys, stored in `did:key` encoding. The service id strings should not include a `#` prefix; that will be added when rendering the DID document. used to generate `verificationMethods` of DID document. these keys do not have control over the DID document.

     

       19
       19
        
       - `alsoKnownAs` (array of strings): priority-ordered list of URIs which indicate other names or aliases associated with the DID identifier

     

       20
       20
        
       - `services` (map with string keys; values are maps with `type` and `endpoint` string fields): a set of service / URL mappings. the key strings should not include a `#` prefix; that will be added when rendering the DID document.

     

       21
       21
        
       

     
···

       27
       27
        
       

     

       28
       28
        
       Note that `rotationKeys` and `verificationMethods` (signing keys) may have public keys which are re-used across many accounts. There is not necessarily a one-to-one mapping between a DID and either rotation keys or signing keys.

     

       29
       29
        
       

     

       30
       30
       -
       Only `secp256k1` ("k256") and NIST P-256 ("p256") keys are currently supported, for both rotation and signing keys.

     

       30
       30
       +
       Only `secp256k1` ("k256") and NIST P-256 ("p256") keys are currently supported for rotation keys, whereas `verificationMethods` keys can be any syntactically-valid `did:key`.

     

       31
       31
        
       

     

       32
       32
        
       ### Use with AT Protocol

     

       33
       33
        
       

     
···

       87
       87
        
       Rotation keys are serialized as strings using [did:key](https://w3c-ccg.github.io/did-key-spec/), and only `secp256k1` ("k256") and NIST P-256 ("p256") are currently supported.

     

       88
       88
        
       

     

       89
       89
        
       The signing keys (`verificationMethods`) are also serialized using `did:key` in operations. When rendered in a DID document, signing keys are represented as objects, with the actual keys in multibase encoding, as required by the DID Core specification.

     

       90
       90
       +
       

     

       91
       91
       +
       Although `verificationMethods` signing keys can be of any key type (unlike rotation keys), they must still be syntactically valid. i.e. They must have a `did:key:` prefix, followed by a `base58btc` multibase string.

     

       90
       92
        
       

     

       91
       93
        
       The DID itself is derived from the hash of the first operation in the log, called the "genesis" operation. The signed operation is encoded in DAG-CBOR; the bytes are hashed with SHA-256; the hash bytes are `base32`-encoded (not hex encoded) as a string; and that string is truncated to 24 chars to yield the "identifier" segment of the DID.

     

       92
       94
        
       

     
···

       390
       392
        
       A "DID PLC history explorer" web interface would make the public nature of the DID audit log more publicly understandable.

     

       391
       393
        
       

     

       392
       394
        
       It is conceivable that longer DID PLCs, with more of the SHA-256 characters, will be supported in the future. It is also conceivable that a different hash algorithm would be allowed. Any such changes would allow existing DIDs in their existing syntax to continue being used.

     

       395
       395
       +
       

     

       396
       396
       +
       ## Changelog

     

       397
       397
       +
       

     

       398
       398
       +
       ### 2025-06-05

     

       399
       399
       +
       

     

       400
       400
       +
       - `verificationMethods` keys may now use any syntactically-valid `did:key:`, regardless of key format (allowing e.g. `ed25519` keys). Rotation keys are not affected by this change, the original format constraints still apply.

     

       401
       401
       +
       

     

       402
       402
       +
       - A total limit of 10 `verificationMethods` (per DID) has been added.