From 6e4a60361f86dbec437750c00997d408d3a96e9e Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sat, 12 Oct 2024 16:16:09 -0400 Subject: [PATCH 1/8] Add use cases to introduction. --- index.html | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 72 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index c47fdfa..9e757cc 100644 --- a/index.html +++ b/index.html @@ -312,13 +312,27 @@

Introduction

+ +

+The use of shared secrets for [=authentication=] and [=authorization=], such as +the use of passwords, has resulted in a variety of security failures over the +past several decades. To address these security failures, systems can upgrade to +the use of + +asymmetric cryptography, which uses digital signatures that are far more +difficult to compromise. However, one shortcoming of digital signatures is +the difficulty in disseminating the information, such as public cryptographic +keys, to those that would need to verify the security of the digital signature. +

+

A [=controller document=] is a set of data that specifies one or more -relationships between a [=controller=] and a set of data, such as a set of -public cryptographic keys. The [=controller document=] contains [=verification -relationships=] that explicitly permit the use of certain [=verification -methods=] for specific purposes. +relationships between an identifier that is controlled by a [=controller=] and a +set of data, such as a set of public cryptographic keys. The [=controller +document=] contains [=verification relationships=] that explicitly permit the +use of certain [=verification methods=] for specific purposes.

+

It is expected that other specifications, such as [[[?DID-CORE]]], will profile the features that are defined in this specification, requiring and/or @@ -326,6 +340,60 @@

Introduction

others.

+
+

Use Cases

+

+The following use cases are illustrative of the need for this specification. +While many other use cases exist, the following paragraphs highlight the +main scenarios that this specification is designed to improve upon. +

+ +
+

Identification

+ +

+Lemmy runs an enterprise portal that manages large amounts of sensitive data +submitted by people working for a variety of organizations. He would like to use +identifiers for entities in the database where control over the identifier can +be cryptographically proven in order to increase security related to who is +allowed to access and update each organizations data. +

+
+ +
+

Cryptographic Purpose

+ +

+Stef, who operates a high security service, would like to ensure that certain +cryptographic keys used by his customers can only be used for certain purposes +to enable different levels of access and protection for each type of +cryptographic key. +

+
+ +
+

Service Engagement

+ +

+Marge, a software developer, would like to publicly advertise ways in which +other people on the Web can reach her through various communication services she +uses based on her globally unique identifier. +

+
+ +
+

Extensibility

+ +

+Cory, a systems architect, would like to extend the use cases described in this +section in a way that provides new functionality while not creating conflicts +with others that are adding extensions. +

+
+ +
+ +

A conforming controller document is any concrete expression of the From a2af418c49f41ec5964930b7685772e72e72a244 Mon Sep 17 00:00:00 2001 From: Joe Andrieu Date: Sat, 12 Oct 2024 16:26:29 -0400 Subject: [PATCH 2/8] Add requirements based on use cases. --- index.html | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) diff --git a/index.html b/index.html index 9e757cc..1ff3a9b 100644 --- a/index.html +++ b/index.html @@ -393,6 +393,71 @@

Extensibility

+
+

Requirements

+ +

+The use cases outlined in the previous section result in at least the following +requirements: +

+ +
+
1. Guaranteed Unique Identifier
+
+Identifiers are globally unique with no possibility of duplication. +
+
2. Proof of Control
+
+It is possible to prove that the entity claiming control over the identifier is +indeed its controller. +
+
3. Associated cryptographic material
+
+The identifier is tightly coupled with cryptographic material that can be used +to prove control over that identifier. +
+
4. Streamlined key rotation
+
+When authentication materials need to be updated, these identifiers can update +without direct intervention with requesting parties and with minimal individual +interaction. +
+
5. Service endpoint discovery
+
+These identifiers allow requesting parties to look up available service +endpoints for interacting with the subject of the identifier. +
+
6. Delegation of control
+
+The controller of the identifier is able to delegate that control to a third +party. +
+
7. Cryptographic future proof
+
+These identifiers are capable of being updated as technology evolves. Current +cryptography techniques are known to be susceptible to quantum computational +attacks. Future-proofed identifiers provide a means to continue using the same +identifier with updated, advanced authentication and authorization technologies. +
+
8. Cryptographic authentication and communication
+
+These identifiers enable cryptographic techniques to authenticate individuals +and to secure communications with the subject of the identifier, typically using +public-private key pairs. +
+
9. Legally-enabled identity
+
+These identifiers can be used as a basis for credentials and transactions that +can be recognized as legally valid under one or more jurisdictions. +
+
10. Human-centered interoperability
+
+Decentralized identifiers need to be easy to use by people with no technical +expertise or specialist knowledge. +
+
+ +

From 120dc1f400024fd576d88711609ecf0384ff96fc Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sat, 12 Oct 2024 16:33:41 -0400 Subject: [PATCH 3/8] Refer to DID Use Cases for further commentary. --- index.html | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/index.html b/index.html index 1ff3a9b..14d2cd2 100644 --- a/index.html +++ b/index.html @@ -344,11 +344,12 @@

Introduction

Use Cases

The following use cases are illustrative of the need for this specification. -While many other use cases exist, the following paragraphs highlight the -main scenarios that this specification is designed to improve upon. +While many other related use cases exist, such as those in [[[DID-USE-CASES]]], +the following paragraphs highlight the main scenarios that this specification is +designed to address.

-
+

Identification

@@ -360,7 +361,7 @@

Identification

-
+

Cryptographic Purpose

@@ -371,7 +372,7 @@

Cryptographic Purpose

-
+

Service Engagement

@@ -381,7 +382,7 @@

Service Engagement

-
+

Extensibility

@@ -397,8 +398,9 @@

Extensibility

Requirements

-The use cases outlined in the previous section result in at least the following -requirements: +The following requirements are derived from the illustrative use cases in this +specification. Further requirements resulting in a more decentralized solution +can be found in [[[DID-USE-CASES]]].

From db7281eb1b3b8c63aa559cc8f20eda8cab93d53c Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sun, 13 Oct 2024 11:20:20 -0400 Subject: [PATCH 4/8] Focus intro on advantages of asymmetric cryptography. Co-authored-by: Dave Longley --- index.html | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/index.html b/index.html index 14d2cd2..3c84b9f 100644 --- a/index.html +++ b/index.html @@ -314,15 +314,13 @@

Introduction

-The use of shared secrets for [=authentication=] and [=authorization=], such as -the use of passwords, has resulted in a variety of security failures over the -past several decades. To address these security failures, systems can upgrade to -the use of - -asymmetric cryptography, which uses digital signatures that are far more -difficult to compromise. However, one shortcoming of digital signatures is -the difficulty in disseminating the information, such as public cryptographic -keys, to those that would need to verify the security of the digital signature. +Digital signatures, based on +asymmetric +cryptography, can be used in [=authentication=] and [=authorization=] +schemes to make them difficult for adversaries to compromise. However, +one shortcoming of digital signatures is the challenge in disseminating +necessary information, such as public cryptographic keys, to those who need +to verify the security of a digital signature.

From 4b02bcd176e15693174f889f7267bd3878620dfe Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sun, 20 Oct 2024 17:35:23 -0400 Subject: [PATCH 5/8] Fix grammar and flow in use cases and requirements. Co-authored-by: Ted Thibodeau Jr Co-authored-by: David Chadwick --- index.html | 61 +++++++++++++++++++++++++++--------------------------- 1 file changed, 31 insertions(+), 30 deletions(-) diff --git a/index.html b/index.html index 3c84b9f..bbf9a5a 100644 --- a/index.html +++ b/index.html @@ -316,10 +316,10 @@

Introduction

Digital signatures, based on asymmetric -cryptography, can be used in [=authentication=] and [=authorization=] -schemes to make them difficult for adversaries to compromise. However, +cryptography, can be used to make [=authentication=] and [=authorization=] +schemes more difficult for adversaries to compromise. However, one shortcoming of digital signatures is the challenge in disseminating -necessary information, such as public cryptographic keys, to those who need +necessary information, such as public cryptographic keys and revocation information, to those who need to verify the security of a digital signature.

@@ -341,9 +341,9 @@

Introduction

Use Cases

-The following use cases are illustrative of the need for this specification. +The use cases below illustrate the need for this specification. While many other related use cases exist, such as those in [[[DID-USE-CASES]]], -the following paragraphs highlight the main scenarios that this specification is +those described below are the main scenarios that this specification is designed to address.

@@ -355,7 +355,7 @@

Identification

submitted by people working for a variety of organizations. He would like to use identifiers for entities in the database where control over the identifier can be cryptographically proven in order to increase security related to who is -allowed to access and update each organizations data. +allowed to access and update each organization's data.

@@ -364,9 +364,9 @@

Cryptographic Purpose

Stef, who operates a high security service, would like to ensure that certain -cryptographic keys used by his customers can only be used for certain purposes -to enable different levels of access and protection for each type of -cryptographic key. +cryptographic keys used by his customers can only be used for specific purposes +(such as encryption, authorization, and/or authentication) to enable different +levels of access and protection for each type of cryptographic key.

@@ -376,7 +376,7 @@

Service Engagement

Marge, a software developer, would like to publicly advertise ways in which other people on the Web can reach her through various communication services she -uses based on her globally unique identifier. +uses based on her globally unique identifier(s).

@@ -385,8 +385,8 @@

Extensibility

Cory, a systems architect, would like to extend the use cases described in this -section in a way that provides new functionality while not creating conflicts -with others that are adding extensions. +section in a way that provides new functionality without creating conflicts +with extensions being added by others.

@@ -396,9 +396,9 @@

Extensibility

Requirements

-The following requirements are derived from the illustrative use cases in this -specification. Further requirements resulting in a more decentralized solution -can be found in [[[DID-USE-CASES]]]. +The following requirements are derived from the use cases described earlier in +this specification. Additional requirements which could lead to a more +decentralized solution can be found in [[[DID-USE-CASES]]].

@@ -413,13 +413,13 @@

Requirements

3. Associated cryptographic material
-The identifier is tightly coupled with cryptographic material that can be used -to prove control over that identifier. +The identifier is tightly coupled with cryptographic material that an entity +can use to prove control over that identifier.
4. Streamlined key rotation
-When authentication materials need to be updated, these identifiers can update -without direct intervention with requesting parties and with minimal individual +Entities denoted by designated identifiers can update authentication materials +without direct intervention by requesting parties and with minimal individual interaction.
5. Service endpoint discovery
@@ -429,23 +429,24 @@

Requirements

6. Delegation of control
-The controller of the identifier is able to delegate that control to a third -party. +The controller of the identifier is able to delegate that control, in full +and/or in part, to a third party.
-
7. Cryptographic future proof
+
7. Cryptographically future-proof
-These identifiers are capable of being updated as technology evolves. Current -cryptography techniques are known to be susceptible to quantum computational -attacks. Future-proofed identifiers provide a means to continue using the same -identifier with updated, advanced authentication and authorization technologies. +These identifiers and associated information are capable of being updated +as technology evolves. Current cryptographic techniques are known to be +susceptible to quantum computational attacks. Future-proofed identifiers +provide a means by which to continue using the same identifier with updated, +advanced authentication and/or authorization technologies.
8. Cryptographic authentication and communication
-These identifiers enable cryptographic techniques to authenticate individuals -and to secure communications with the subject of the identifier, typically using -public-private key pairs. +These identifiers enable the use of cryptographic techniques that can be employed +to authenticate individuals and/or to secure communications with the subject of +the identifier, typically using public-private key pairs.
-
9. Legally-enabled identity
+
9. Legally recognizable identification
These identifiers can be used as a basis for credentials and transactions that can be recognized as legally valid under one or more jurisdictions. From 6ad135b7aac59637b0818de7db5108e0a12028b7 Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sun, 20 Oct 2024 17:48:32 -0400 Subject: [PATCH 6/8] Add use case for issuing and presenting claims. --- index.html | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index bbf9a5a..0599066 100644 --- a/index.html +++ b/index.html @@ -342,9 +342,9 @@

Introduction

Use Cases

The use cases below illustrate the need for this specification. -While many other related use cases exist, such as those in [[[DID-USE-CASES]]], -those described below are the main scenarios that this specification is -designed to address. +While many other related use cases exist, such as those in [[[DID-USE-CASES]]] +and [[[VC-USE-CASES]]], those described below are the main scenarios that this +specification is designed to address.

@@ -390,6 +390,18 @@

Extensibility

+
+

Issue and Present Claims

+ +

+Neru would like to issue digital credentials on behalf of her company that +contain claims about their employees. The claims that are made need to use +identifiers that are cryptographically attributable back to Neru's company and +need to allow for the holder's of those credentials to be able to +cryptographically authenticate themselves when they present the credential. +

+
+
@@ -3263,7 +3275,7 @@

Keep Personal Data Private

If a [=controller document=] is about a specific individual and is public-facing, it is critical that [=controller documents=] contain no personal biometric or biographical data. While it is true that personal data -might include pseudonymous information, such as a public cryptographic key or an IP address, +might include pseudonymous information, such as a public cryptographic key or an IP address, publishing that sort of information does not create the same immediate privacy dangers as publishing an individual's full name, profile photo, or social media account in a [=controller document=]. A better alternative is to transmit From 8dac97593e78a8efd5ac910e3c5189276d20b710 Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sun, 20 Oct 2024 17:59:12 -0400 Subject: [PATCH 7/8] Add section on cryptographic verification. --- index.html | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/index.html b/index.html index 0599066..831e511 100644 --- a/index.html +++ b/index.html @@ -348,14 +348,25 @@

Use Cases

-

Identification

+

Globally Unique Identifiers

-Lemmy runs an enterprise portal that manages large amounts of sensitive data -submitted by people working for a variety of organizations. He would like to use -identifiers for entities in the database where control over the identifier can -be cryptographically proven in order to increase security related to who is -allowed to access and update each organization's data. +Lemmy runs multiple enterprise portals that manage large amounts of sensitive +data submitted by people working for a variety of organizations. He would like +to use identifiers for entities in the databases that are provided by +his customers and do not depend on easily phishable information such as +email addresses and passwords. +

+
+ +
+

Cryptographic Verification

+ +

+Lemmy would like to ensure that his customers prove control over their +identifiers — for example, by using public/private key cryptography +— in order to increase security related to who is allowed to access and +update each organization's data.

From 7a2f27db9168f5a4b6e37a51f7bd77a90a47b2d5 Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sun, 20 Oct 2024 18:05:57 -0400 Subject: [PATCH 8/8] Make introductory paragraph use simpler language. --- index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 831e511..8a68292 100644 --- a/index.html +++ b/index.html @@ -317,9 +317,9 @@

Introduction

Digital signatures, based on asymmetric cryptography, can be used to make [=authentication=] and [=authorization=] -schemes more difficult for adversaries to compromise. However, -one shortcoming of digital signatures is the challenge in disseminating -necessary information, such as public cryptographic keys and revocation information, to those who need +schemes more difficult for adversaries to compromise. However, one shortcoming +of digital signatures is the challenge in distributing necessary information, +such as public cryptographic keys and revocation information, to those who need to verify the security of a digital signature.