From 2daeec34d43fb7d46289c229b66179aab1664dc6 Mon Sep 17 00:00:00 2001 From: rhiaro Date: Sat, 30 Mar 2019 17:35:51 +0100 Subject: [PATCH 1/6] Remove implied ledger requirement, fixes #149 --- index.html | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index da4bea7..ecae216 100644 --- a/index.html +++ b/index.html @@ -1368,9 +1368,8 @@

-Since Authorization and Delegation are typically implemented by the -ledger, each DID Method specification is expected to detail how -authorization and delegation are performed for the ledger. +Each DID Method MUST define how authorization and delegation are +implemented, including any necessary cryptographic operations.

From 3ab68500030c0e27d05aad259e6081cdef82412b Mon Sep 17 00:00:00 2001 From: rhiaro Date: Sat, 30 Mar 2019 17:44:41 +0100 Subject: [PATCH 2/6] Define Decentralized Identifer Registry as a type of VDR --- common.js | 13 +++++++++++++ terms.html | 8 ++++++++ 2 files changed, 21 insertions(+) diff --git a/common.js b/common.js index 6082aec..8026987 100644 --- a/common.js +++ b/common.js @@ -27,6 +27,19 @@ var ccg = { status: "FPWD", publisher: "Verifiable Claims Working Group" }, + "VC-DATA-MODEL": { + title: "Verifiable Credentials Data Model", + href: "https://www.w3.org/TR/verifiable-claims-data-model/", + authors: [ + "Manu Sporny", + "Dave Longley", + "Grant Noble", + "David Chadwick", + "Daniel C. Burnett" + ], + status: "FPWD", + publisher: "Verifiable Claims Working Group" + }, // aliases to known references "HTTP-SIGNATURES": { aliasOf: "http-signatures" diff --git a/terms.html b/terms.html index f5ffa0e..dd7518e 100644 --- a/terms.html +++ b/terms.html @@ -43,6 +43,14 @@ System, and most national ID systems. +

Decentralized Identifier Registry (DIR)
+ +
+A role a system performs to mediate the creation, verification, updating, and +deactivation of Decentralized Identifiers. +A DIR is a type of Verifiable Data Registry (see [[VC-DATA-MODEL]]). +
+
Decentralized Public Key Infrastructure (DPKI)
From 6cb73bad7e3e80bbd7eee4eea70f0b78163f5a3a Mon Sep 17 00:00:00 2001 From: rhiaro Date: Sat, 30 Mar 2019 18:10:57 +0100 Subject: [PATCH 3/6] Use 'Decentralized Identifier Registry' instead of '(distributed) ledger' throughout. Fixes #150. Also removes some redundant language from Overview (fixing #119). --- index.html | 106 +++++++++++++++++++++++++---------------------------- terms.html | 2 +- 2 files changed, 50 insertions(+), 58 deletions(-) diff --git a/index.html b/index.html index ecae216..8ea95ac 100644 --- a/index.html +++ b/index.html @@ -206,18 +206,17 @@

-The emergence of distributed ledger technology (DLT), sometimes -referred to as blockchain technology, provides the opportunity for -fully decentralized identity management. In a decentralized -identity system, entities (in the sense of discrete identifiable units -such as—but not limited to—people and organisations) are free to use any -shared root of trust. -Globally distributed ledgers, decentralized P2P networks, or other systems -with similar capabilities, provide the means for managing a root of -trust with neither centralized authority nor a single point of -failure. In combination, DLTs and decentralized identity systems -enable any entity to create and manage their own identifiers on any -number of distributed, independent roots of trust. +Globally distributed ledgers, decentralized P2P networks, and other systems +with similar capabilities, provide an opportunity for fully decentralized +identity management. In a decentralized identity system, entities +(in the sense of discrete identifiable units such as—but not limited to—people +and organisations) are free to use any shared root of trust, with neither +centralized authority nor a single point of failure. +Combining decentralized identity systems enables any entity to create and +manage their own identifiers on any number of distributed, independent roots of +trust, an architecture referred to as + +DPKI (decentralized PKI).

@@ -234,20 +233,11 @@

-DID methods are the mechanism by which a DID and its associated DID -Document are created, read, updated, and deactivated on a specific -distributed ledger or network. DID methods are defined using separate -DID method specifications. -

- -

-This design eliminates dependence on centralized registries for -identifiers as well as centralized certificate authorities for key -management—the standard pattern in hierarchical PKI (public -key infrastructure). Because DIDs reside on a distributed ledger, -each entity may serve as its own root authority—an architecture -referred to as -DPKI (decentralized PKI). +DID methods are the mechanism by which a DID (the character string +identifier) and its associated DID Document are created, read, +updated, and deactivated in a Decentralized Identifier Registry. +DID methods are defined using separate DID method specifications for +specific systems.

@@ -335,12 +325,12 @@

The first purpose of this specification is to define the generic DID scheme and a generic set of operations on DID documents that can be -implemented for any distributed ledger or network capable of -supporting DIDs. The second purpose of this specification is to +implemented for any Decentralized Identifier Registry. The second +purpose of this specification is to define the conformance requirements for a DID method specification—a separate specification that defines a specific DID scheme and specific set of DID document operations for a specific -distributed ledger or network. +Decentralized Identifier Registry.

@@ -855,10 +845,10 @@

Ideally a DID would be a completely abstract decentralized identifier (like a UUID) that could be bound -to multiple underlying distributed ledgers or networks over time, -thus maintaining its persistence independent of any particular ledger -or network. However registering the same identifier on multiple -ledgers or networks introduces extremely hard entityship and +to multiple underlying Decentralized Identifier Registries over time, +thus maintaining its persistence independent of any particular system. +However registering the same identifier on multiple +Decentralized Identifier Registries introduces extremely hard entityship and start-of-authority (SOA) problems. It also greatly increases implementation complexity for developers. @@ -867,7 +857,7 @@

To avoid these issues, it is RECOMMENDED that DID method specifications only produce DIDs and DID methods bound to strong, -stable ledgers or networks capable of making the highest level of +stable Decentralized Identifier Registries capable of making the highest level of commitment to persistence of the DID and DID method over time.

@@ -875,8 +865,8 @@

Although not included in this version, future versions of this specification may support a DID Document equivID property to establish verifiable equivalence relations between DIDs -representing the same subject on multiple ledgers or -networks. Such equivalence relations can produce the practical +representing the same subject on multiple Decentralized Identifier +Registries. Such equivalence relations can produce the practical equivalent of a single persistent abstract DID. See Future Work (Section ).

@@ -982,8 +972,8 @@

  • -When this DID Document is registered with the target distributed -ledger or network, the registered DID MUST match this DID subject +When this DID Document is registered with the target Decentralized +Identifier Registry, the registered DID MUST match this DID subject value.
    • @@ -1379,15 +1369,15 @@

    1. -A ledger could implement a coarse grained guardian -pattern by reusing the same proof purpose pattern used by the - authentication property, or more preferably +A Decentralized Identifier Registry could implement a coarse +grained guardian pattern by reusing the same proof purpose +pattern used by the authentication property, or more preferably
    2. -A ledger could implement a Capabilities-based approach and -provide more fine-grained control of authorization, delegation, and -guardianship. +A Decentralized Identifier Registry could implement a +Capabilities-based approach and provide more fine-grained control of +authorization, delegation, and guardianship.
    @@ -1727,7 +1717,7 @@

    Now that the JSON-LD Context has been created, the developer MUST publish it somewhere that is accessible to any DID Document processor. For this example, let us assume that the JSON-LD Context -above is published in the decentralized ledger at the following URL: +above is published at the following URL: did:example:contexts:987654321. At this point, extending the first example in this section is a simple matter of including the context above and adding the new property to the DID Document. @@ -1938,8 +1928,8 @@

    Since the method name is part of the DID, it SHOULD be as short as practical. A method name of five characters or less is RECOMMENDED. -The method name MAY reflect the name of the distributed ledger or -network to which the DID method specification applies. +The method name MAY reflect the name of the Decentralized Identifier +Registry to which the DID method specification applies.

    @@ -1966,7 +1956,7 @@

    To enable the full functionality of DIDs and DID Documents on a -particular distributed ledger or network (called the target system), a +particular Decentralized Identifier Registry, a DID method specification MUST specify how each of the following CRUD operations is performed by a client. Each operation MUST be @@ -2043,8 +2033,8 @@

    Although a core feature of distributed ledgers is immutability, the DID method specification MUST specify how a client can deactivate a DID -on the target system, including all cryptographic operations -necessary to establish proof of deactivation. +on the Decentralized Identifier Registry, including all cryptographic +operations necessary to establish proof of deactivation.

    @@ -2362,7 +2352,7 @@

    1. -Subscriptions. If the ledger or network on which the DID is +Subscriptions. If the Decentralized Identifier Registry on which the DID is registered directly supports change notifications, this service can be offered to DID controllers. Notifications may be sent directly to the relevant service endpoints listed in an existing DID. @@ -2467,14 +2457,14 @@

      -Keep Personally-Identifiable Information (PII) Off-Ledger +Keep Personally-Identifiable Information (PII) Private

      -If a DID method specification is written for a public ledger or -network where all DIDs and DID Documents will be publicly available, +If a DID method specification is written for a public Decentralized +Identifier Registry where all DIDs and DID Documents will be publicly available, it is STRONGLY RECOMMENDED that DID Documents contain no PII. All PII -should be kept off-ledger behind service endpoints under the control +should be kept behind service endpoints under the control of the subject. With this privacy architecture, PII may be exchanged on a private, peer-to-peer basis using communications channels identified and secured by key descriptions in DID documents. This also @@ -2581,8 +2571,10 @@

      Including an equivalence property, such as equivID, in DID Documents whose value is an array of DIDs would allow subjects to assert two or more DIDs that represent the same subject. This capability has -numerous uses, including supporting migration between ledgers and -providing forward compatibility of existing DIDs to future DLTs. In +numerous uses, including supporting migration between Decentralized +Identifier Registries and +providing forward compatibility of existing DIDs to future Decentralized +Identifier Registries. In theory, equivalent DIDs should have the same identifier rights, allowing verifiable claims made against one DID to apply to equivalent DIDs. Equivalence was not diff --git a/terms.html b/terms.html index dd7518e..188ee6f 100644 --- a/terms.html +++ b/terms.html @@ -43,7 +43,7 @@ System, and most national ID systems.

    -
    Decentralized Identifier Registry (DIR)
    +
    Decentralized Identifier Registry (DIR)
    A role a system performs to mediate the creation, verification, updating, and From cf73b61c5d9654c0dcf840b27536aaaec54e264d Mon Sep 17 00:00:00 2001 From: rhiaro Date: Sat, 30 Mar 2019 18:14:16 +0100 Subject: [PATCH 4/6] Replace 'target system' with DIR --- index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 8ea95ac..d180ab8 100644 --- a/index.html +++ b/index.html @@ -1996,7 +1996,7 @@

    The DID method specification MUST specify how a client creates a DID -and its associated DID Document on the target system, including all +and its associated DID Document on the Decentralized Identifier Registry, including all cryptographic operations necessary to establish proof of control.

    @@ -2008,7 +2008,7 @@

    The DID method specification MUST specify how a client uses a DID to -request a DID Document from the target system, including how the +request a DID Document from the Decentralized Identifier Registry, including how the client can verify the authenticity of the response.

    @@ -2020,7 +2020,7 @@

    The DID method specification MUST specify how a client can update a -DID Document on the target system, including all cryptographic +DID Document on the Decentralized Identifier Registry, including all cryptographic operations necessary to establish proof of control.

    From 75be78566bae82f8a7a304c44625734d037d8765 Mon Sep 17 00:00:00 2001 From: rhiaro Date: Sun, 31 Mar 2019 16:47:42 +0200 Subject: [PATCH 5/6] Revert changes to the Overview for now --- index.html | 44 +++++++++++++++++++++++--------------------- 1 file changed, 23 insertions(+), 21 deletions(-) diff --git a/index.html b/index.html index d180ab8..70c44b3 100644 --- a/index.html +++ b/index.html @@ -206,17 +206,18 @@

    -Globally distributed ledgers, decentralized P2P networks, and other systems -with similar capabilities, provide an opportunity for fully decentralized -identity management. In a decentralized identity system, entities -(in the sense of discrete identifiable units such as—but not limited to—people -and organisations) are free to use any shared root of trust, with neither -centralized authority nor a single point of failure. -Combining decentralized identity systems enables any entity to create and -manage their own identifiers on any number of distributed, independent roots of -trust, an architecture referred to as - -DPKI (decentralized PKI). +The emergence of distributed ledger technology (DLT), sometimes +referred to as blockchain technology, provides the opportunity for +fully decentralized identity management. In a decentralized +identity system, entities (in the sense of discrete identifiable units +such as—but not limited to—people and organisations) are free to use any +shared root of trust. +Globally distributed ledgers, decentralized P2P networks, or other systems +with similar capabilities, provide the means for managing a root of +trust with neither centralized authority nor a single point of +failure. In combination, DLTs and decentralized identity systems +enable any entity to create and manage their own identifiers on any +number of distributed, independent roots of trust.

    @@ -233,19 +234,20 @@

    -DID methods are the mechanism by which a DID (the character string -identifier) and its associated DID Document are created, read, -updated, and deactivated in a Decentralized Identifier Registry. -DID methods are defined using separate DID method specifications for -specific systems. +DID methods are the mechanism by which a DID and its associated DID +Document are created, read, updated, and deactivated on a specific +distributed ledger or network. DID methods are defined using separate +DID method specifications.

    -Note that DID methods may also be developed for identifiers -registered in federated or centralized identity management systems. -For their part, all types of identifier systems may add support for -DIDs. This creates an interoperability bridge between the worlds of -centralized, federated, and decentralized identifiers. +This design eliminates dependence on centralized registries for +identifiers as well as centralized certificate authorities for key +management—the standard pattern in hierarchical PKI (public +key infrastructure). Because DIDs reside on a distributed ledger, +each entity may serve as its own root authority—an architecture +referred to as +DPKI (decentralized PKI).

    From 980fdbc9f3367889e17f85222184375b4ffd619d Mon Sep 17 00:00:00 2001 From: rhiaro Date: Sun, 31 Mar 2019 16:48:46 +0200 Subject: [PATCH 6/6] Revert changes to the Overview for now --- index.html | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/index.html b/index.html index 70c44b3..1648758 100644 --- a/index.html +++ b/index.html @@ -250,6 +250,14 @@

    DPKI (decentralized PKI).

    +

    +Note that DID methods may also be developed for identifiers +registered in federated or centralized identity management systems. +For their part, all types of identifier systems may add support for +DIDs. This creates an interoperability bridge between the worlds of +centralized, federated, and decentralized identifiers. +

    +

    Motivations for DIDs