commit 984ddbd211ce0e7780349d9b6cea85e5a4d8ef35 · edouard.paris/did-method-plc

+16 -17

README.md

···

       2
        
       

     

       3
        
       DID PLC is a self-authenticating [DID](https://www.w3.org/TR/did-core/) which is strongly-consistent, recoverable, and allows for key rotation.

     

       4
        
       

     

       5
       -
       An example DID is: `did:plc:yk4dd2qkboz2yv6tpubpc6co`

     

       6
        
       

     

       7
       -
       Control over a `did:plc` identity rests in a set of re-configurable "rotation" keys pairs. These keys can sign update "operations" to mutate the identity (including key rotations), with each operation referencing a prior version of the identity state by hash. Each identity starts from an initial "genesis" operation, and the hash of this initial object is what defines the DID itself (that is, the DID URI "identifier" string). A central "directory" server collects and validates operations, and maintains a transparent log of operations for each DID.

     

       8
        
       

     

       9
        
       ## Motivation

     

       10
        
       

     

       11
       -
       [Bluesky](https://blueskyweb.xyz/) developed DID PLC when designing the [AT Protocol](https://atproto.com) ("atproto") because we were not satisfied with any of the existing DID methods.

     

       12
       -
       We wanted a strongly consistent, highly available, recoverable, and cryptographically secure method with fast and cheap propagation of updates.

     

       13
        
       

     

       14
       -
       We originally titled the method "Placeholder", because we didn't want it to stick around forever in its current form. We are actively hoping to replace it with or evolve it into something less centralized - likely a permissioned DID consortium. That being said, we do intend to support `did:plc` in the current form until after any successor is deployed, with a reasonable grace period. We would also provide a migration route to allow continued use of existing `did:plc` identifiers.

     

       15
        
       

     

       16
        
       ## How it works

     

       17
        
       

     
···

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

     

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

     

       25
        
       

     

       26
       -
       Every update "operation" to the DID identifier, including the initial creation operation ("genesis" operation), contains all of the above information, except for the `did` field. The DID itself is generated from a hash of the signed genesis operation (details described below), which makes the DID entirely self-certifying. Updates after initial creation contain a pointer to the most-recent previous operation (by hash).

     

       27
        
       

     

       28
       -
       "Operations" are signed and submitted to the central PLC directory server over an un-authenticated HTTP request. The PLC server validates operations against any and all existing operations on the DID (including signature validation, recovery time windows, etc), and either rejects the operation or accepts and permanently stores the operation, along with a server-generated timestamp.

     

       29
        
       

     

       30
       -
       A special operation type is a "tombstone", which clears all of the data fields and permanently "de-activates" the DID. Note that the usual recovery time window applies to "tombstone" operations.

     

       31
        
       

     

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

     

       33
        
       

     

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

     

       35
        
       

     

       36
        
       ### Use with AT Protocol

     

       37
        
       

     

       38
        
       The following information should be included for use with atproto:

     

       39
        
       

     

       40
       -
       - `verificationMethods`: an `atproto` entry with a "blessed" public key type, to be used as a "signing key" for authenticating updates to the account's repository. the signing key does not have any control over the DID identity unless also included in the `rotationKeys` list. best practice is to maintain separation between rotation keys and atproto signing keys

     

       41
       -
       - `alsoKnownAs`: should include an `at://` URI indicating a "handle" (hostname) for the account. note that the handle/DID mapping needs to be validated bi-directionally (via handle resolution), and needs to be re-verified periodically

     

       42
        
       - `services`: an `atproto_pds` entry with an `AtprotoPersonalDataServer` type and http/https URL `endpoint` indicating the account's current PDS hostname. for example, `https://pds.example.com` (no `/xrpc/` suffix needed).

     

       43
        
       

     

       44
        
       ### Operation Serialization, Signing, and Validation

     

       45
        
       

     

       46
       -
       There are a couple variations on the "operation" data object schema. The operations are also serialized both as simple JSON objects, or binary DAG-CBOR encoding for the purpose of hashing or signing.

     

       47
        
       

     

       48
        
       A regular creation or update operation contains the following fields:

     

       49
        
       

     
···

       52
        
       - `verificationMethods` (mapping of string keys and values): as described above

     

       53
        
       - `alsoKnownAs` (array of strings): as described above

     

       54
        
       - `services` (mapping of string keys and object values): as described above

     

       55
       -
       - `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"

     

       56
        
       - `sig` (string): signature of the operation in `base64url` encoding

     

       57
        
       

     

       58
        
       A tombstone operation contains:

     
···

       377
        
       

     

       378
        
       ## Possible Future Changes

     

       379
        
       

     

       380
       -
       The set of allowed ("blessed") public key cryptographic algorithms (aka, curves) may expanded over time, slowly. Likewise, support for additional "blessed" CID types and parameters may be expanded over time, slowly.

     

       381
        
       

     

       382
        
       The recovery time window may become configurable, within constraints, as part of the DID metadata itself.

     

       383
        
       

     

       384
        
       Support for "DID Controller Delegation" could be useful (eg, in the context of atproto PDS hosts), and may be incorporated.

     

       385
        
       

     

       386
       -
       In the context of atproto, support for multiple "handles" for the same DID is being considered, with a single "primary" handle. But no final decision has been made yet.

     

       387
        
       

     

       388
        
       We welcome proposals for small additions to make `did:plc` more generic and reusable for applications other than atproto. But no promises: atproto will remain the focus for the near future.

     

       389
        
       

     

       390
       -
       Moving governance of the `did:plc` method, and operation of registry servers, out of the sole control of Bluesky PBC is something we are enthusiastic about. Audit log snapshots, mirroring, and automated third-party auditing have all been considered as mechanisms to mitigate the centralized nature of the PLC server.

     

       391
        
       

     

       392
        
       The size of the `verificationMethods`, `alsoKnownAs`, and `service` mappings/arrays may be specifically constrained. And the maximum DAG-CBOR size may be constrained.

     

       393

···

DID PLC is a self-authenticating [DID](https://www.w3.org/TR/did-core/) which is strongly-consistent, recoverable, and allows for key rotation.

5
+
An example DID is: `did:plc:ewvi7nxzyoun6zhxrhs64oiz`

7
+
Control over a `did:plc` identity rests in a set of reconfigurable rotation keys pairs. These keys can sign update operations to mutate the identity (including key rotations), with each operation referencing a prior version of the identity state by hash. Each identity starts from an initial genesis operation, and the hash of this initial object is what defines the DID itself (that is, the DID URI identifier string). A central directory server collects and validates operations, and maintains a transparent log of operations for each DID.

## Motivation

11
+
[Bluesky PBC](https://blueskyweb.xyz/) developed DID PLC when designing the [AT Protocol](https://atproto.com) (atproto) because we were not satisfied with any of the existing DID methods. We wanted a strongly consistent, highly available, recoverable, and cryptographically secure method with fast and cheap propagation of updates.

13
+
We originally titled the method "placeholder", because we didn't want it to stick around forever in its current form. We are actively hoping to replace it with or evolve it into something less centralized - likely a permissioned DID consortium. That being said, we do intend to support `did:plc` in the current form until after any successor is deployed, with a reasonable grace period. We would also provide a migration route to allow continued use of existing `did:plc` identifiers.

## How it works

···

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

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

25
+
Every update operation to the DID identifier, including the initial creation operation (the genesis operation), contains all of the above information, except for the `did` field. The DID itself is generated from a hash of the signed genesis operation (details described below), which makes the DID entirely self-certifying. Updates after initial creation contain a pointer to the most-recent previous operation (by hash).

27
+
Operations are signed and submitted to the central PLC directory server over an un-authenticated HTTP request. The PLC server validates operations against any and all existing operations on the DID (including signature validation, recovery time windows, etc), and either rejects the operation or accepts and permanently stores the operation, along with a server-generated timestamp.

29
+
A special operation type is a "tombstone", which clears all of the data fields and permanently deactivates the DID. Note that the usual recovery time window applies to tombstone operations.

31
+
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.

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

### Use with AT Protocol

The following information should be included for use with atproto:

39
+
- `verificationMethods`: an `atproto` entry with a "blessed" public key type, to be used as a signing key for authenticating updates to the account's repository. The signing key does not have any control over the DID identity unless also included in the `rotationKeys` list. Best practice is to maintain separation between rotation keys and atproto signing keys.

40
+
- `alsoKnownAs`: should include an `at://` URI indicating a handle (hostname) for the account. Note that the handle/DID mapping needs to be validated bi-directionally (via handle resolution), and needs to be re-verified periodically

- `services`: an `atproto_pds` entry with an `AtprotoPersonalDataServer` type and http/https URL `endpoint` indicating the account's current PDS hostname. for example, `https://pds.example.com` (no `/xrpc/` suffix needed).

### Operation Serialization, Signing, and Validation

45
+
There are a couple variations on the operation data object schema. The operations are also serialized both as simple JSON objects, or binary DAG-CBOR encoding for the purpose of hashing or signing.

A regular creation or update operation contains the following fields:

···

- `verificationMethods` (mapping of string keys and values): as described above

- `alsoKnownAs` (array of strings): as described above

- `services` (mapping of string keys and object values): as described above

54
+
- `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"

- `sig` (string): signature of the operation in `base64url` encoding

A tombstone operation contains:

···

376

377

## Possible Future Changes

378

379
+
The set of allowed ("blessed") public key cryptographic algorithms (aka, curves) may expanded over time, slowly. Likewise, support for additional blessed CID types and parameters may be expanded over time, slowly.

380

381

The recovery time window may become configurable, within constraints, as part of the DID metadata itself.

382

383

Support for "DID Controller Delegation" could be useful (eg, in the context of atproto PDS hosts), and may be incorporated.

384

385
+
In the context of atproto, support for multiple handles for the same DID is being considered, with a single primary handle. But no final decision has been made yet.

386

387

We welcome proposals for small additions to make `did:plc` more generic and reusable for applications other than atproto. But no promises: atproto will remain the focus for the near future.

388

389
+
We are enthusiastic about the prospect of moving governance of the `did:plc` method, and operation of registry servers, out of the sole control of Bluesky PBC. Audit log snapshots, mirroring, and automated third-party auditing have all been considered as mechanisms to mitigate the centralized nature of the PLC server.

390

391

The size of the `verificationMethods`, `alsoKnownAs`, and `service` mappings/arrays may be specifically constrained. And the maximum DAG-CBOR size may be constrained.

392

+14 -14

go-didplc/cmd/webplc/spec/v0.1/did-plc.md

···

       5
        
       

     

       6
        
       DID PLC is a self-authenticating [DID](https://www.w3.org/TR/did-core/) which is strongly-consistent, recoverable, and allows for key rotation.

     

       7
        
       

     

       8
       -
       An example DID is: `did:plc:yk4dd2qkboz2yv6tpubpc6co`

     

       9
        
       

     

       10
       -
       Control over a `did:plc` identity rests in a set of re-configurable "rotation" keys pairs. These keys can sign update "operations" to mutate the identity (including key rotations), with each operation referencing a prior version of the identity state by hash. Each identity starts from an initial "genesis" operation, and the hash of this initial object is what defines the DID itself (that is, the DID URI "identifier" string). A central "directory" server collects and validates operations, and maintains a transparent log of operations for each DID.

     

       11
        
       

     

       12
        
       ## How it works

     

       13
        
       

     
···

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

     

       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
        
       

     

       22
       -
       Every update "operation" to the DID identifier, including the initial creation operation ("genesis" operation), contains all of the above information, except for the `did` field. The DID itself is generated from a hash of the signed genesis operation (details described below), which makes the DID entirely self-certifying. Updates after initial creation contain a pointer to the most-recent previous operation (by hash).

     

       23
        
       

     

       24
       -
       "Operations" are signed and submitted to the central PLC directory server over an un-authenticated HTTP request. The PLC server validates operations against any and all existing operations on the DID (including signature validation, recovery time windows, etc), and either rejects the operation or accepts and permanently stores the operation, along with a server-generated timestamp.

     

       25
        
       

     

       26
       -
       A special operation type is a "tombstone", which clears all of the data fields and permanently "de-activates" the DID. Note that the usual recovery time window applies to "tombstone" operations.

     

       27
        
       

     

       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
        
       

     

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

     

       31
        
       

     

       32
        
       ### Use with AT Protocol

     

       33
        
       

     

       34
        
       The following information should be included for use with atproto:

     

       35
        
       

     

       36
       -
       - `verificationMethods`: an `atproto` entry with a "blessed" public key type, to be used as a "signing key" for authenticating updates to the account's repository. the signing key does not have any control over the DID identity unless also included in the `rotationKeys` list. best practice is to maintain separation between rotation keys and atproto signing keys

     

       37
       -
       - `alsoKnownAs`: should include an `at://` URI indicating a "handle" (hostname) for the account. note that the handle/DID mapping needs to be validated bi-directionally (via handle resolution), and needs to be re-verified periodically

     

       38
        
       - `services`: an `atproto_pds` entry with an `AtprotoPersonalDataServer` type and http/https URL `endpoint` indicating the account's current PDS hostname. for example, `https://pds.example.com` (no `/xrpc/` suffix needed).

     

       39
        
       

     

       40
        
       ### Operation Serialization, Signing, and Validation

     

       41
        
       

     

       42
       -
       There are a couple variations on the "operation" data object schema. The operations are also serialized both as simple JSON objects, or binary DAG-CBOR encoding for the purpose of hashing or signing.

     

       43
        
       

     

       44
        
       A regular creation or update operation contains the following fields:

     

       45
        
       

     
···

       48
        
       - `verificationMethods` (mapping of string keys and values): as described above

     

       49
        
       - `alsoKnownAs` (array of strings): as described above

     

       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"

     

       52
        
       - `sig` (string): signature of the operation in `base64url` encoding

     

       53
        
       

     

       54
        
       A tombstone operation contains:

     
···

       371
        
       

     

       372
        
       ## Possible Future Changes

     

       373
        
       

     

       374
       -
       The set of allowed ("blessed") public key cryptographic algorithms (aka, curves) may expanded over time, slowly. Likewise, support for additional "blessed" CID types and parameters may be expanded over time, slowly.

     

       375
        
       

     

       376
        
       The recovery time window may become configurable, within constraints, as part of the DID metadata itself.

     

       377
        
       

     

       378
        
       Support for "DID Controller Delegation" could be useful (eg, in the context of atproto PDS hosts), and may be incorporated.

     

       379
        
       

     

       380
       -
       In the context of atproto, support for multiple "handles" for the same DID is being considered, with a single "primary" handle. But no final decision has been made yet.

     

       381
        
       

     

       382
        
       We welcome proposals for small additions to make `did:plc` more generic and reusable for applications other than atproto. But no promises: atproto will remain the focus for the near future.

     

       383
        
       

     

       384
       -
       Moving governance of the `did:plc` method, and operation of registry servers, out of the sole control of Bluesky PBLLC is something we are enthusiastic about. Audit log snapshots, mirroring, and automated third-party auditing have all been considered as mechanisms to mitigate the centralized nature of the PLC server.

     

       385
        
       

     

       386
        
       The size of the `verificationMethods`, `alsoKnownAs`, and `service` mappings/arrays may be specifically constrained. And the maximum DAG-CBOR size may be constrained.

     

       387

···

DID PLC is a self-authenticating [DID](https://www.w3.org/TR/did-core/) which is strongly-consistent, recoverable, and allows for key rotation.

8
+
An example DID is: `did:plc:ewvi7nxzyoun6zhxrhs64oiz`

10
+
Control over a `did:plc` identity rests in a set of reconfigurable rotation keys pairs. These keys can sign update operations to mutate the identity (including key rotations), with each operation referencing a prior version of the identity state by hash. Each identity starts from an initial genesis operation, and the hash of this initial object is what defines the DID itself (that is, the DID URI identifier string). A central directory server collects and validates operations, and maintains a transparent log of operations for each DID.

## How it works

···

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

22
+
Every update operation to the DID identifier, including the initial creation operation (the genesis operation), contains all of the above information, except for the `did` field. The DID itself is generated from a hash of the signed genesis operation (details described below), which makes the DID entirely self-certifying. Updates after initial creation contain a pointer to the most-recent previous operation (by hash).

24
+
Operations are signed and submitted to the central PLC directory server over an un-authenticated HTTP request. The PLC server validates operations against any and all existing operations on the DID (including signature validation, recovery time windows, etc), and either rejects the operation or accepts and permanently stores the operation, along with a server-generated timestamp.

26
+
A special operation type is a "tombstone", which clears all of the data fields and permanently deactivates the DID. Note that the usual recovery time window applies to tombstone operations.

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.

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

### Use with AT Protocol

The following information should be included for use with atproto:

36
+
- `verificationMethods`: an `atproto` entry with a "blessed" public key type, to be used as a signing key for authenticating updates to the account's repository. The signing key does not have any control over the DID identity unless also included in the `rotationKeys` list. Best practice is to maintain separation between rotation keys and atproto signing keys.

37
+
- `alsoKnownAs`: should include an `at://` URI indicating a handle (hostname) for the account. Note that the handle/DID mapping needs to be validated bi-directionally (via handle resolution), and needs to be re-verified periodically

### Operation Serialization, Signing, and Validation

42
+
There are a couple variations on the operation data object schema. The operations are also serialized both as simple JSON objects, or binary DAG-CBOR encoding for the purpose of hashing or signing.

A regular creation or update operation contains the following fields:

···

- `verificationMethods` (mapping of string keys and values): as described above

- `alsoKnownAs` (array of strings): as described above

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

- `sig` (string): signature of the operation in `base64url` encoding

A tombstone operation contains:

···

371

372

## Possible Future Changes

373

374
+
The set of allowed ("blessed") public key cryptographic algorithms (aka, curves) may expanded over time, slowly. Likewise, support for additional blessed CID types and parameters may be expanded over time, slowly.

375

376

The recovery time window may become configurable, within constraints, as part of the DID metadata itself.

377

378

Support for "DID Controller Delegation" could be useful (eg, in the context of atproto PDS hosts), and may be incorporated.

379

380
+
In the context of atproto, support for multiple handles for the same DID is being considered, with a single primary handle. But no final decision has been made yet.

381

382

We welcome proposals for small additions to make `did:plc` more generic and reusable for applications other than atproto. But no promises: atproto will remain the focus for the near future.

383

384
+
We are enthusiastic about the prospect of moving governance of the `did:plc` method, and operation of registry servers, out of the sole control of Bluesky PBC. Audit log snapshots, mirroring, and automated third-party auditing have all been considered as mechanisms to mitigate the centralized nature of the PLC server.

385

386

The size of the `verificationMethods`, `alsoKnownAs`, and `service` mappings/arrays may be specifically constrained. And the maximum DAG-CBOR size may be constrained.

387

+1 -1

go-didplc/cmd/webplc/templates/base.html

···

       86
        
       

     

       87
        
       <footer class="container-fluid">

     

       88
        
       	<div class="container">

     

       89
       -
           <small>Developed by <a href="https://blueskyweb.xyz">Bluesky</a> for <a href="https://atproto.com">atproto</a></small>

     

       90
        
         </div>

     

       91
        
       </footer>

     

       92
        
       {% endblock -%}

···

       86
        
       

     

       87
        
       <footer class="container-fluid">

     

       88
        
       	<div class="container">

     

       89
       +
           <small>Developed by <a href="https://blueskyweb.xyz">Bluesky PBC</a> for <a href="https://atproto.com">atproto</a></small>

     

       90
        
         </div>

     

       91
        
       </footer>

     

       92
        
       {% endblock -%}

+3 -3

go-didplc/cmd/webplc/templates/home.html

···

       6
        
           <h3>A self-authenticating Decentralized Identifier (DID) system which is strongly-consistent, recoverable, and allows for key rotation</h3>

     

       7
        
         </hgroup>

     

       8
        
       

     

       9
       -
         <p>PLC is a persistent global identifier system, which allows accounts to retain relationships while changing names or migrating between service providers. It makes use of cryptography and gives individuals (or organizations) direct control and ownership over their identitifier, but does not make use of any blockchain or cryptocurrency technology, and is "cheap" enough to provide as a no-cost service.</p>

     

       10
        
       

     

       11
       -
         <p>PLC is a "method" which implements the W3C Decentralized Identifier (DID) standard. This means it is interoperable and resuable by other applications and organization.</p>

     

       12
        
       

     

       13
       -
         <p>Bluesky developed DID Placeholder when designing the AT Protocol ("atproto") because we were not satisfied with any of the existing DID methods. We wanted a strongly consistent, highly available, recoverable, and cryptographically secure method with fast and cheap propagation of updates.</p>

     

       14
        
       

     

       15
        
         <p>While PLC originally stood for "placeholder", the system has been in production use for several months, with over half a million registered accounts in the atproto network as of August 2023. While it is conceivable that the method will evolve or be replaced over time by a successor method, we feel that the current system provides value and is worth consideration as a persistent identifier for other applications.</p>

     

       16

···

       6
        
           <h3>A self-authenticating Decentralized Identifier (DID) system which is strongly-consistent, recoverable, and allows for key rotation</h3>

     

       7
        
         </hgroup>

     

       8
        
       

     

       9
       +
         <p>PLC is a persistent global identifier system, which allows accounts to retain relationships while changing names or migrating between service providers. It makes use of cryptography and gives individuals (or organizations) direct control and ownership over their identitifier, but does not make use of any blockchain or cryptocurrency technology, and is inexpensive enough to provide as a no-cost service.</p>

     

       10
        
       

     

       11
       +
         <p>PLC is a method which implements the W3C Decentralized Identifier (DID) standard. This means it is interoperable and resuable by other applications and organization.</p>

     

       12
        
       

     

       13
       +
         <p>Bluesky PBC developed DID Placeholder when designing the AT Protocol (atproto) because we were not satisfied with any of the existing DID methods. We wanted a strongly consistent, highly available, recoverable, and cryptographically secure method with fast and cheap propagation of updates.</p>

     

       14
        
       

     

       15
        
         <p>While PLC originally stood for "placeholder", the system has been in production use for several months, with over half a million registered accounts in the atproto network as of August 2023. While it is conceivable that the method will evolve or be replaced over time by a successor method, we feel that the current system provides value and is worth consideration as a persistent identifier for other applications.</p>

     

       16