├── .github └── workflows │ └── auto-publish.yml ├── .pr-preview.json ├── CODEOWNERS ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── FPWD └── 2019-11-21 │ ├── images │ └── did_actions.png │ └── index.html ├── LICENSE.md ├── README.md ├── common.js ├── images ├── didCreate.svg ├── didDelete.svg ├── didRead.svg ├── didUpdate.svg ├── didUse.svg ├── did_actions.png └── domainMap.svg ├── index.html └── w3c.json /.github/workflows/auto-publish.yml: -------------------------------------------------------------------------------- 1 | name: CI 2 | on: 3 | pull_request: {} 4 | push: 5 | branches: [main] 6 | jobs: 7 | main: 8 | name: Build, Validate and Deploy 9 | runs-on: ubuntu-20.04 10 | steps: 11 | - uses: actions/checkout@v2 12 | - uses: w3c/spec-prod@v2 13 | with: 14 | W3C_ECHIDNA_TOKEN: ${{ secrets.W3C_TR_TOKEN }} 15 | W3C_WG_DECISION_URL: https://www.w3.org/2019/did-wg/Meetings/Minutes/2019-11-19-did#resolution1 16 | W3C_BUILD_OVERRIDE: | 17 | shortName: did-use-cases 18 | specStatus: WG-NOTE 19 | -------------------------------------------------------------------------------- /.pr-preview.json: -------------------------------------------------------------------------------- 1 | { 2 | "src_file": "index.html", 3 | "type": "respec" 4 | } 5 | -------------------------------------------------------------------------------- /CODEOWNERS: -------------------------------------------------------------------------------- 1 | # These owners will be the default owners for everything in 2 | # the repo. Unless a later match takes precedence, 3 | # they will be requested for review when someone opens a 4 | # pull request. 5 | * @jandrieu @philarcher 6 | 7 | # See CODEOWNERS syntax here: https://help.github.com/articles/about-codeowners/#codeowners-syntax 8 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | All documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/). 4 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Decentralized Identifier Working Group 2 | 3 | Contributions to this repository are intended to become part of Recommendation-track documents governed by the 4 | [W3C Patent Policy](https://www.w3.org/Consortium/Patent-Policy-20040205/) and 5 | [Document License](https://www.w3.org/Consortium/Legal/copyright-documents). To make substantive contributions to specifications, you must either participate 6 | in the relevant W3C Working Group or make a non-member patent licensing commitment. 7 | 8 | If you are not the sole contributor to a contribution (pull request), please identify all 9 | contributors in the pull request comment. 10 | 11 | To add a contributor (other than yourself, that's automatic), mark them one per line as follows: 12 | 13 | ``` 14 | +@github_username 15 | ``` 16 | 17 | If you added a contributor by mistake, you can remove them in a comment with: 18 | 19 | ``` 20 | -@github_username 21 | ``` 22 | 23 | If you are making a pull request on behalf of someone else but you had no part in designing the 24 | feature, you can remove yourself with the above syntax. 25 | -------------------------------------------------------------------------------- /FPWD/2019-11-21/images/did_actions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/did-use-cases/24b7848b1651ac718f1239aa929f346b7a369c5e/FPWD/2019-11-21/images/did_actions.png -------------------------------------------------------------------------------- /FPWD/2019-11-21/index.html: -------------------------------------------------------------------------------- 1 | 93 | 94 | Use Cases and Requirements for Decentralized Identifiers 95 | 384 | 385 | 386 | 393 | 595 |
596 |

Use Cases and Requirements for Decentralized Identifiers

597 | 598 |

599 | W3C First Public Working Draft 600 | 601 |

602 |
603 |
This version:
604 | https://www.w3.org/TR/2019/WD-did-use-cases-20191121/ 605 |
Latest published version:
606 | https://www.w3.org/TR/did-use-cases/ 607 |
608 |
Latest editor's draft:
https://w3c.github.io/did-use-cases/
609 | 610 | 611 | 612 | 613 | 614 | 615 |
Editors:
616 |
Joe Andrieu 617 | (Invited Expert) 618 |
Phil Archer 619 | (GS1) 620 |
621 | 622 | 623 |
Participate:
624 | GitHub w3c/did-use-cases 625 |
626 | File a bug 627 |
628 | Commit history 629 |
630 | Pull requests 631 |
632 |
633 | 634 | 635 | 636 |

637 | Copyright 638 | © 639 | 2019 640 | 641 | W3C® (MIT, 642 | ERCIM, Keio, 643 | Beihang). 644 | W3C liability, 645 | trademark and permissive document license rules 646 | apply. 647 |

648 |
649 |
650 |

Abstract

651 |

This document sets out use cases and requirements for a new type of identifier that has 4 essential characteristics:

652 |
    653 |
  1. decentralized: there should be no central issuing 654 | agency;
    2. 655 |
  2. persistent: the identifier should be inherently 656 | persistent, not requiring the continued operation of an underling organization;
    3. 657 |
  3. crytopgraphically verifiable: it should be possible 658 | to prove control of the identifier cryptographically;
    4. 659 |
  4. resolvable: it should be possible to discover 660 | metadata about the identifier.
    5. 661 |
662 |

Although existing identifiers may display some of these characteristics, none currently displays all four.

663 |
664 |

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

665 | This document was published by the Decentralized Identifier Working Group as a 666 | First Public Working Draft. 667 | This document is intended to become a W3C Recommendation. 668 |

669 | GitHub Issues are preferred for 670 | discussion of this specification. 671 | 672 | Alternatively, you can send comments to our mailing list. 673 | Please send them to 674 | public-did-wg@w3.org 675 | (archives). 676 | 677 |

678 | Publication as a First Public Working Draft does not imply endorsement by the 679 | W3C Membership. This is a draft document and may be updated, replaced or 680 | obsoleted by other documents at any time. It is inappropriate to cite this 681 | document as other than work in progress. 682 |

683 | 684 | This document was produced by a group 685 | operating under the 686 | W3C Patent Policy. 687 | 688 | 689 | W3C maintains a 690 | public list of any patent disclosures 691 | made in connection with the deliverables of 692 | the group; that page also includes 693 | instructions for disclosing a patent. An individual who has actual 694 | knowledge of a patent which the individual believes contains 695 | Essential Claim(s) 696 | must disclose the information in accordance with 697 | section 6 of the W3C Patent Policy. 698 | 699 | 700 |

701 | This document is governed by the 702 | 1 March 2019 W3C Process Document. 703 |

704 |
705 |

1. Introduction

706 |

The need for globally unique identifier schemes has been addressed many 707 | times. Globally unique ID schemes typically rely on a central authority 708 | controlling a 'root' space that is then delegated to local organizations 709 | who in turn delegate to further organizations who eventually add the final 710 | string to complete the identifer. Even if we restrict ourseleves to online 711 | identifiers, there are many examples of this.

734 |

In all these cases, ultimately, there is a central authority on which the 735 | identifier system depends. Those central authorities go to significant 736 | efforts to make their identifiers persistent and resolvable, however, 737 | should they cease to exist, the long term integrity of the identifier 738 | is at least questionable to a greater or lesser extent. For as long as 739 | those organizations exist (and they are generally well established with no 740 | immediate threat to their survival), the way to assess whether a particular 741 | identifier is in some way 'valid' is to query the issuing authority.

742 |

These factors point to a need in some circumstances for a globally unique 743 | identifier that is 'self sovereign', that is, one that does not depend on 744 | any issuing authority. Universally unique identifiers (UUIDs) [RFC4122] 745 | fulfill this role, however, there is no way to prove control of 746 | a UUID.

747 |

This document sets out use cases and requirements for a new kind of 748 | identifier that meets all these basic requirements:

749 |
    750 |
  1. decentralized: there should be no central issuing 751 | agency;
    2. 752 |
  2. persistent: the identifier should be inherently 753 | persistent, not requiring the continued operation of an underling organization;
    3. 754 |
  3. crytopgraphically verifiable: it should be possible 755 | to prove control of the identifier cryptographically;
    4. 756 |
  4. resolvable: it should be possible to discover 757 | metadata about the identifier.
    5. 758 |
759 |
760 |

1.1 Existing Work

761 |

The use cases and requirements set out below have not been created a 762 | priori. Substantial work has been done within W3C and elsewhere 763 | leading, in particular, to Decentralized 764 | Identifiers (DIDs) Data Model and Syntaxes published as a Community 765 | Group Report by the Credentials 766 | Community Group in August 2019. That work provides a framework — 767 | a set of concepts — that have proved to be useful when discussing 768 | DIDs and the problems they 769 | can solve (see below). Those concepts are used within this document to 770 | set out the detail of the problem that the Decentralized Identifier Working 771 | Group is chartered 772 | to solve. It is the nature of the standardization process that these 773 | terms may be modified within the standard itself and therefore, their 774 | use here should not be seen as authoritative.

775 |
776 |
777 |

1.2 Concepts of Decentralized Identity

778 |
Issue 39: Relying Party terminology could confuse things

Terminology in this opening prose is being discussed, in particular 779 | the term 'relying party'

780 |

A decentralized system will enable several key actions by three 781 | distinct entities: the Controller, the Relying Party, and the Subject.

782 |

Controllers create and control DIDs, 783 | while Relying Parties rely on DIDs 784 | as an identifier for interactions related to the DID Subject.

785 |

The Subject is the entity referred to by the DID, which can be anything: a person, an organization, 787 | a device, a location, even a concept. Typically, the Subject is also 788 | the Controller, but in cases of guardianship, agents (human or software), 789 | and inanimate Subjects, this is not possible. As such, the Subject has 790 | no functional role. When the Subject is, in fact, the Controller, we 791 | consider the action to be taken by the Controller on their own behalf 792 | as the Subject. When the Subject is not the Controller, the Controller 793 | is said to be taking action on behalf of the Subject, such as when an 794 | employee manages a DID 795 | on behalf of their employer or a parent uses a DID on behalf of their child.

797 |

The Controller and Relying Party may be individuals or interactive 798 | systems, but for simplicity in this document, we refer to both as if 799 | they were individual persons performing these actions.

800 |

Only a Controller can perform the actions that control a DID, however, anyone can act 801 | as a Relying Party for any DID 802 | they know, including the Controller should they wish to inspect or 803 | verify their own DID.

804 |

This use case document defines these actions in terms of the eventual 805 | systems we anticipate using the resultant specification.

806 | 807 |

Perhaps the most salient point about Decentralized Identifiers is 808 | that there are no "Identity Providers". Instead, this role is subsumed 809 | in the decentralized systems that Controllers use to manage DIDs and, in turn, Relying 810 | Parties use to apply DIDs. 811 | These decentralized systems, which we refer to as DID registries, are designed to 812 | operate independently from any particular service provider and hence, 813 | free from any given platform authority. It is anticipated that DIDs will be registered using 814 | distributed ledger technology (DLT). 815 | 816 |

In practice, the definition and operation of all current decentralized 817 | systems retain some elements of centralized control. Depending on the 818 | criteria one uses to evaluate such systems — from who controls 819 | the most widely used code base to who controls the specification — 820 | where a system resides on the spectrum of centralized and decentralized 821 | varies. However, the design of any decentralized identity system is 822 | separate from the academic debate about how decentralized it may be 823 | in practice.

824 |

The use cases presented below make use of a number of high level 825 | concepts as follows.

826 | 827 |
Note: Shared terminology
828 |

This section is automatically synchronised with the terminology section in 829 | the DID Core specification.

830 | 831 |

832 | This document attempts to communicate the concepts outlined in the 833 | decentralized identifier space by using specialized terms to discuss specific 834 | concepts. This terminology is included below and linked to throughout the 835 | document to aid the reader: 836 |

837 | 838 |
839 | 840 | 841 | 842 | 843 | 844 | 845 |
decentralized identifier (DID)
846 | 847 |
848 | A globally unique identifier that does 849 | not require a centralized registration authority because it is 850 | registered with distributed ledger technology (DLT) or other form of 851 | decentralized network. The generic format of a DID is defined in this 852 | specification. A specific DID scheme is defined in a 853 | DID method specification. 854 |
855 | 856 | 857 | 858 | 859 | 860 | 861 | 862 | 863 | 864 | 865 | 866 | 867 | 868 | 869 | 870 | 871 | 872 | 873 | 874 | 875 | 876 | 877 |
DID controller
878 | 879 |
880 | The entity, or a group of entities, in control of a DID and/or DID document. 881 | Note that the DID controller might include the DID subject. 882 |
883 | 884 | 885 |
DID document
886 | 887 |
888 | A set of data that describes the DID subject, 889 | including mechanisms, such as public keys and 890 | pseudonymous biometrics, that the DID subject can use to authenticate itself 891 | and prove their association with the DID. A DID document MAY also contain other 892 | attributes or 893 | claims 894 | describing the subject. These documents are graph-based data structures that 895 | are typically expressed using [JSON-LD], but may be expressed using other 896 | compatible graph-based data formats. 897 |
898 | 899 | 900 |
DID fragment
901 | 902 |
903 | The portion of a DID URL that follows the first hash 904 | sign character (#). DID fragment syntax is identical to URI 905 | fragment syntax. 906 |
907 | 908 | 909 |
DID method
910 | 911 |
912 | A definition of how a specific DID scheme can be implemented 913 | on a specific distributed ledger or network, including the precise 914 | method(s) by which DIDs are resolved and deactivated and DID 915 | documents are written and updated. 916 |
917 | 918 | 919 |
DID path
920 | 921 |
922 | The portion of a DID URL that begins with and includes the first forward 923 | slash character (/). DID path syntax is identical to URI path syntax. 924 |
925 | 926 | 927 |
DID registry
928 | 929 |
930 | A role a system performs to mediate the creation, verification, updating, and 931 | deactivation of decentralized identifiers. 932 | A DID registry is a type of verifiable data registry (see [VC-DATA-MODEL]). 933 |
934 | 935 | 936 |
DID query
937 | 938 |
939 | The portion of a DID URL that follows the first question 940 | mark character (?). DID query syntax is identical to URI query syntax. 941 |
942 | 943 | 944 | 945 | 946 | 947 | 948 |
DID subject
949 | 950 |
951 | The DID subject is the entity that the DID document is about, i.e., 952 | it is the entity identified by the DID and described by the DID 953 | document. 954 |
955 | 956 |
DID URL
957 | 958 |
959 | A DID plus an optional DID path, optional ? character followed by a 960 | DID query, and optional # character followed by a DID fragment. 961 |
962 | 963 | 964 |
DID scheme
965 | 966 |
967 | The formal syntax of a decentralized identifier. The generic DID 968 | scheme is defined in this specification. Separate DID method specifications 969 | define a specific DID scheme that works with that specific DID method. 970 |
971 | 972 | 973 |
distributed ledger (DLT)
974 | 975 |
976 | A distributed 977 | database in which the various nodes use a consensus 978 | protocol to maintain a shared ledger in which each transaction is 979 | cryptographically signed and chained to the previous transaction. 980 |
981 | 982 | 983 | 984 | 985 | 986 | 987 | 988 | 989 | 990 | 991 | 992 | 993 | 994 | 995 | 996 | 997 | 998 | 999 | 1000 | 1001 | 1002 | 1003 |
Uniform Resource Identifier (URI)
1004 | 1005 |
1006 | An identifier as defined by [RFC3986]. 1007 |
1008 | 1009 | 1010 |
Universally Unique Identifier (UUID)
1011 | 1012 |
1013 | An identifier as defined by [RFC4122]. 1014 |
1015 | 1016 | 1017 | 1018 | 1019 | 1020 | 1021 | 1022 |
1023 |
1024 | 1025 |
Issue 14: What does it mean for a DID to be "recorded in a registry"? FPWD

The term DID registry is under discussion within the Working Group. 1026 | A particular point to bear in mind is that not all DID methods require DIDs to be registered to be functional.

1027 | 1028 |

When we refer to methods and registries, we mean DID methods and DID registries. A working assumption for the use cases is that all 1030 | DIDs resolve to DID Documents. DID 1032 | Documents contain the cryptographic material to perform the functions related to 1033 | that particular DID, including 1034 | associated proof methods and any service endpoints, that is, services that can 1035 | make use of the DID.

1036 |
1037 |
1038 | 1039 | 1040 |
1041 |

2. Use Cases

1042 |
1043 |

2.1 Online shopper

1044 |

Traditionally, a shopper frequents a trusted retailer and can physically hold the products they wish to purchase. The product and the information about it is trusted, because it is put there by the brand, and shopper trusts the retailer has received the product through trusted supply chain partners. Today, there are a multitude of channels and platforms for selling and buying products. The internet has changed consumer purchasing behavior as more and more commerce is conducted digitally. This introduces new challenges for brands, retailers and consumers, as the relationship is not as direct as the traditional mode of shopping.

1045 |

Online shopping, especially including 3rd party marketplaces creates the proliferation of digital records about that product across platforms. Unlike a physical product, a consumer cannot be assured that the record (and the information presented about that product) came from the brand or other authoritative source. Product identification and information and the source of the product itself is less reliable, and introduces trust issues with representations of products bought and sold online. Additionally, unique identification is critical to business processes, but also to online purchasing. Very often two different products share the same identifier across the supply chain, and so what a consumer purchases and what ultimately is received may be different.

1046 |

Mechanisms are required for the following to provide trust in the digital representation of a product across platforms:

    1047 |
  1. validation of the legitimacy of an online listing — in particular on third party marketplaces;
    2. 1048 |
  2. assurance of identification uniqueness and key identifying data element accuracy.
    3. 1049 |
1050 |
1051 |
Editor's note

More short use cases to be added

1052 | 1053 |
1054 |
1055 |

3. DID Actions

1056 |
Editor's note

This section currently unchanged from CG's document - needs to be updated.

1057 |

Here are the thirteen (13) actions currently supported by DIDs as envisioned by Credentials Community Group and as intended in the DID Working Group Charter.

1058 |

In the diagram, we have grouped the actions by Create, Read, Update, and Delete (CRUD) as well as Use.

1059 | Actions supported by DIDs, grouped by type, and related to the entity which carries out the action 1060 |
1061 |

3.1 Create

1062 |

Controllers create DIDs, uniquely binding cryptographic proofs with the identifier, typically using public-private key-pairs. These DIDs are recorded in a registry in such a manner as to be able to resolve to a DID Document. The DID Document may be dynamically and deterministically generated through resolution or it may be explicitly constructed as a stand-alone resource and either stored or referenced in the registry. This process needs access to the registry, ideally a decentralized system, and like the rest of the DID CRUD actions, can be performed without interaction with any particular authority.

1063 |
1064 |
1065 |

3.2 Present

1066 |

DIDs are URIs, which is to say a string of characters. As such, they may be presented in the same manner as URIs, by simply transmitting or presenting that string of characters. DIDs, however are not designed to be human readable. They invariably contain long, complex numbers represented in various formats. For ease of use, implementations often rely on QR codes for ease of capture using a camera-enabled device such as a smart phone.

1067 |
1068 |
1069 |

3.3 Authenticate

1070 |

Relying Parties may wish to prove that the individual presenting a DID is in fact its controller or specified as a Controller for a particular service endpoint. This authentication process uses the cryptographic material in the DID Document to test if the claimed Controller can, in fact, prove control, typically through some sort of challenge-response. Some DID Documents and methods allow for separate, proofs for different service endpoints, distinct from update and delete actions. This separation allows transactional proofs that are expected to be used frequently, while controlling proofs are used rarely.

1071 |
1072 |
1073 |

3.4 Sign

1074 |

Using cryptographic material associated with that found in a DID Document, DID Controllers may sign digital assets or documents. This signature can later be verified (#7 Signature Verification) to demonstrate the authenticity of the asset. In this way, we may referred to the asset as "signed by the DID".

1075 |
1076 |
1077 |

3.5 Resolve

1078 |

The first step in using a DID for anything other than presentation is to resolve the DID to a specific DID Document, to reveal the cryptographic material and service endpoints associated with that DID. How this occurs is method-specific and currently under development in the [DID-RESOLUTION] specification.

1079 |
1080 |
1081 |

3.6 Dereference

1082 |

Dereferencing a DID uses the material in its DID Document to return a resource. By default, dereferencing a DID without a reference to a service endpoint returns the DID Document itself. When a DID is combined with a service parameter (forming a DID URL), dereferencing returns the resource pointed to from the named service endpoint, which was discovered by resolving the DID to its DID Document and looking up the endpoint by name. In this way, a Relying Party may dynamically discover and interact with the current service endpoints for a given DID. Services can therefore be given persistent identifiers that do not change even when the underlying service endpoints change.

1083 |
1084 |
1085 |

3.7 Verify Signature

1086 |

Given a digital asset signed by a DID, a Relying Party may use the cryptographic material in the DID Document to verify the signature.

1087 |
1088 |
1089 |

3.8 Rotate

1090 |

Controllers may rotate the cryptographic material for a DID by updating the DID Document as recorded in its registry. Different methods handle this differently, but the result is an update to the core cryptographic proof required to prove control of the DID and the DID Document.

1091 |
1092 |
1093 |

3.9 Modify Service Endpoint

1094 |

Controllers may change service endpoints associated with a DID, including the proof mechanism for authenticating as the Subject for any given endpoint. The process for doing this is method specific, but is designed to allow Controllers to make these change without necessarily changing the primary proof mechanism for control of the DID itself.

1095 |
1096 |
1097 |

3.10 Forward / Migrate

1098 |

To support interoperability, some methods provide a way for controllers to record in the registry (by updating the DID Document), that the DID should be redirected to another DID, which now has full authority to represent the originating DID. This mechanism allows DID controllers to migrate a DID from one method or registry to another.

1099 |
1100 |
1101 |

3.11 Recover

1102 |

Some methods provide means for recovering control of a DID if its existing private cryptographic material is lost. These means vary by method but can include social recovery, multi-sig, Shamir sharing, or pre-rotated keys. In general, recovery triggers a rotation to a new proof, allowing the Controller of that new proof to recover control of the DID without interacting with any Relying Parties.

1103 |
1104 |
1105 |

3.12 Audit

1106 |

Some methods provide an explicit audit trail of all CRUD actions on that DID, including a timestamp for when the actions took place. For distributed ledger-based registries, this audit trail is fundamental to the way the ledgers record transactions. This allows relying parties to see, for example, how recently a DID was rotated or its service endpoints updated, which may inform certain analytics regarding the reliability of the DID's cryptographic material.

1107 |
1108 |
1109 |

3.13 Deactivate

1110 |

Instead of deleting a DID, Controllers can deactivate a DID such that downstream processes like authentication and dereferencing are no longer functional. Most decentralized systems cannot guarantee actual deletion of a record. Indeed, distributed ledgers are often touted as "immutable". Methods define deactivation processes to achieve the same effect as deletion. The mechanisms for deactivation vary based on the method.

1111 |
1112 |
1113 |
1114 |

4. Feature/Benefit Grid

1115 |

In collecting and evaluating potential use cases, we have 1116 | identified fifteen (15) key features supported by the DID specification, 1117 | which provide benefits in the areas of anti-censorship, anti-exploitation, 1118 | ease of use, privacy, and sustainability.

1119 |

The features and their associated benefits can be seen in the following 1120 | grid. A brief definition of each feature follows.

1121 | 1122 | 1123 | 1124 | 1125 | 1126 | 1127 | 1128 | 1129 | 1130 | 1131 | 1132 | 1133 | 1134 | 1135 | 1136 | 1137 | 1138 | 1139 | 1140 | 1141 | 1142 | 1143 | 1144 | 1145 | 1146 | 1147 | 1148 | 1149 | 1150 | 1151 | 1152 | 1153 | 1154 | 1155 | 1156 | 1157 | 1158 | 1159 | 1160 | 1161 | 1162 | 1163 | 1164 | 1165 | 1166 | 1167 | 1168 | 1169 | 1170 | 1171 | 1172 | 1173 | 1174 | 1175 | 1176 | 1177 | 1178 | 1179 | 1180 | 1181 | 1182 | 1183 | 1184 | 1185 | 1186 | 1187 | 1188 | 1189 | 1190 | 1191 | 1192 | 1193 | 1194 | 1195 | 1196 | 1197 | 1198 | 1199 | 1200 | 1201 | 1202 | 1203 | 1204 | 1205 | 1206 | 1207 | 1208 | 1209 | 1210 | 1211 | 1212 | 1213 | 1214 | 1215 | 1216 | 1217 | 1218 | 1219 | 1220 | 1221 | 1222 | 1223 | 1224 | 1225 | 1226 | 1227 | 1228 | 1229 | 1230 | 1231 | 1232 | 1233 | 1234 | 1235 | 1236 | 1237 | 1238 | 1239 | 1240 | 1241 | 1242 | 1243 | 1244 | 1245 | 1246 | 1247 | 1248 | 1249 | 1250 | 1251 | 1252 | 1253 | 1254 | 1255 | 1256 | 1257 | 1258 | 1259 |
Feature Anti-censorAnti-exploitationEase of UsePrivacySustainability
1. Inter-jurisdictionalX   X
2. Can't be administratively deniedX    
3. Minimized rents X  X
4. No vendor lock in X  X
5. Self-issued, self-managedXX X 
6. Streamlined rotation  X  
7. No phone home   X 
8. No surveillance capitalism X XX
9. Cryptographic future proof    X
10. Survives issuing organization mortality  X X
11. Survives deployment end-of-life    X
12. Survives relationship with service provider  X X
13. Cryptographic authentication and communicationXX X 
14. Service Discovery  X X
15. Registry agnosticXX XX
1260 |
1261 |
1262 |

5. Required Features

1263 |
1264 |
1. Inter-jurisdictional
1265 |
Inter-jurisdictional identifiers do not depend on the legal jurisdiction 1266 | in which they are issued. They are valid for uses anywhere without loss 1267 | of fidelity or reliability. No jurisdiction is directly able to prevent 1268 | their use. (Anti-censorship and Sustainable).
1269 |
2. Can't be administratively denied
1270 |
These identifiers can't be denied or taken away by administrative 1271 | function. This prevents shifting politics and bad actors from 1272 | interfering. (Anti-censorship).
1273 |
3. Minimized rents
1274 |
These identifiers don't incur ongoing expenses if unused nor on a per 1275 | transaction basis. Fees based on updates—which incurs network and 1276 | computational costs to verify—are considered "minimal". (Anti-exploitation 1277 | and Sustainable).
1278 |
4. No vendor lock in
1279 |
These identifiers are not dependent on any given vendor. Vendor-specific 1280 | identifiers restrict usage to that which is acceptable to the vendor and 1281 | may allow vendors to extract disproportionate rents for usage. 1282 | (Anti-exploitation, Privacy, and Sustainable).
1283 |
5. Self-issued, self-managed
1284 |
These identifiers are created and managed by the subject of the identifier. 1285 | They are not assigned, given, sold, or rented to the individual using them. 1286 | The party relying on the identifier for identification, authentication, and 1287 | authorization, does not need to manage the creation, update, and recovery of 1288 | these identifiers. (Anti-censorship, Ease of use, and Privacy)
1289 |
6. Streamlined rotation
1290 |
When authentication materials need to be updated, these identifiers can 1291 | update without direct intervention with relying parties and with minimal 1292 | individual interaction. (Ease of use)
1293 |
7. No phone home
1294 |
When using these identifiers, there is no need to contact the issuer of the 1295 | identifier to verify it. Verification and authentication can occur without 1296 | further communication with the issuer. (Privacy)
1297 |
8. No surveillance capitalism
1298 |
These identifiers limit the effectiveness of surveillance capitalism by 1299 | minimizing cross-service correlatability. Individuals may use these 1300 | identifiers at multiple service providers without their activity being 1301 | tracked for collusion or third party embedded surveillance techniques like 1302 | cookies. (Anti-exploitation and Privacy).
1303 |
9. Cryptographic future proofing
1304 |
These identifiers are capable of being updated as technology evolves. Current 1305 | cryptography techniques are known to be susceptible to quantum computational 1306 | attacks. Future-proofed identifiers provide a means to continue using the same 1307 | identifier with updated, advanced authentication and authorization technologies. 1308 | (Sustainable)
1309 |
10. Survives organizational mortality
1310 |
These identifiers survive the demise of the organization that issued them. They 1311 | usefulness of these identifiers survive organizations going out of business, 1312 | being purchased (and potentially losing domain names or root credentials), and 1313 | even the internal decay of an organization that no longer has the ability to 1314 | verify the authenticity of records they once issued.
1315 |
11. Survives deployment end-of-life
1316 |
These identifiers are usable even after the systems deployed by relying parties 1317 | move past their useful lifetime. They are robust against technology fads and can 1318 | seamlessly work with both legacy and next-generation systems.
1319 |
12. Survives relationship with service provider
1320 |
These identifiers are not dependent on the tenure of the relationship with a 1321 | service provider. This contrasts with identifiers like service-centric emails, 1322 | e.g., joe@example.com, which when used as identifiers in other systems can cause 1323 | problems when individuals no longer use the service provider.
1324 |
13. Cryptographic authentication and communication
1325 |
These identifiers enable cryptographic techniques to authenticate individuals 1326 | and to secure communications with the subject of the identifier, typically using 1327 | public-private key pairs.
1328 |
14. Service discovery
1329 |
These identifiers allow relying parties to look up available service endpoints 1330 | for interacting with the subject of the identifier. (Ease of use and Sustainable)
1331 |
15. Registry agnostic
1332 |
These identifiers are free to reside on any registry implementing a compatible 1333 | interface. They are not beholden to any particular technology or vendor.
1334 |
1335 |
1336 |
1337 |

6. Feature Coverage

1338 |

Not all use cases illustrate each feature, and not all DID methods 1339 | support all features. However, we are gathering 1340 | use cases to make sure all key features are clearly described. The 1341 | following chart shows which features are explicitly illustrated in 1342 | the Focal Use Cases.

1343 | 1344 | 1345 | 1346 | 1347 | 1348 | 1349 | 1350 | 1351 | 1352 | 1353 | 1354 | 1355 | 1356 | 1357 | 1358 | 1359 | 1360 | 1361 | 1362 | 1363 | 1364 | 1365 | 1366 | 1367 | 1368 | 1369 | 1370 | 1371 | 1372 | 1373 | 1374 | 1375 | 1376 | 1377 | 1378 | 1379 | 1380 | 1381 | 1382 | 1383 | 1384 | 1385 | 1386 | 1387 | 1388 | 1389 | 1390 | 1391 | 1392 | 1393 | 1394 | 1395 | 1396 | 1397 | 1398 | 1399 | 1400 | 1401 | 1402 | 1403 | 1404 | 1405 | 1406 | 1407 | 1408 | 1409 | 1410 | 1411 | 1412 | 1413 | 1414 | 1415 | 1416 | 1417 | 1418 | 1419 | 1420 | 1421 | 1422 | 1423 | 1424 | 1425 | 1426 | 1427 | 1428 | 1429 | 1430 | 1431 | 1432 | 1433 | 1434 | 1435 | 1436 | 1437 | 1438 | 1439 | 1440 | 1441 | 1442 | 1443 | 1444 | 1445 | 1446 | 1447 | 1448 | 1449 | 1450 | 1451 | 1452 | 1453 | 1454 | 1455 | 1456 | 1457 | 1458 | 1459 | 1460 | 1461 | 1462 | 1463 | 1464 | 1465 | 1466 | 1467 | 1468 | 1469 | 1470 | 1471 | 1472 | 1473 | 1474 | 1475 | 1476 | 1477 | 1478 | 1479 | 1480 | 1481 | 1482 | 1483 | 1484 | 1485 | 1486 | 1487 | 1488 | 1489 |
Feature CorporateEducational
credentials		PrescriptionsDigital
Executor		Single
Sign On
1. Inter-jurisdictionalXX X 
2. Can't be administratively deniedX XXX
3. Minimized rents  X  
4. No vendor lock inXXXX 
5. Self-issued, self-managedXXXX 
6. Streamlined rotation X X 
7. No phone home XX  
8. No surveillance capitalism  X  
9. Cryptographic future proofXX  X
10. Survives issuing organization mortality X   
11. Survives deployment end-of-life X   
12. Survives relationship with service providerXX   
13. Cryptographic authentication and communicationXXXXX
14. Service Discovery     
15. Registry agnostic     
1490 |
1491 | 1492 |
1493 |

7. Focal Use Cases

1494 |
1495 |

7.1 Decentralized Corporate Identifiers (enterprise)

1496 |
1497 |

7.1.1 Background

1498 |

1499 | There are many types of identifiers that corporations use today 1500 | including tax identification numbers (e.g. 238-42-3893), Legal 1501 | Entity Identifiers (e.g. 5493000IBP32UQZ0KL24), Data Universal 1502 | Numbering System identifiers (aka. DUNS Number) (e.g. 150483782), 1503 | and many more that communicate the unique identity of an organization. 1504 | None of these numbers enable an organization to self-issue an 1505 | identifier or to use the number to cryptographically authenticate or 1506 | digitally sign agreements. A great number of business to business 1507 | and business to customer transactions could be executed more quickly 1508 | and with greater assurance of the validity of the transaction if a 1509 | mechanism to self-issue cryptographic identifiers were created. 1510 |

1511 |
1512 |
1513 |

7.1.2 Description

1514 |

1515 | A North American government would like to ensure that the supply 1516 | chain that feeds electronic products into the country is secure. As 1517 | a result, a new method of submitting digital documentation to Customs 1518 | is enabled that requires that all documentation is provided as 1519 | machine-readable digitally signed data. Digitally signed documentation 1520 | is collected at each stage of the manufacturing, packaging, and 1521 | shipping process. This documentation is then submitted to Customs 1522 | upon the products entry into the country where all digital signatures 1523 | are verified on the documentation. Some aspects of the signed 1524 | documentation, such as firmware hashes and checksums, are then used 1525 | by Customs and downstream customers to verify that the products have 1526 | not been tampered with after leaving the manufacturing facility. 1527 |

1528 |

1529 | Decentralized Identifiers should ensure 1) low 1530 | management overhead for the government, 2) self-management of 1531 | identifiers and cryptographic key material, and 3) a competitive 1532 | marketplace. 1533 |

1534 |
1535 |
1536 |

7.1.3 Challenges

1537 |

1538 | The requirement of downstream customers to use the same documentation 1539 | and digital signature mechanisms that were provided to Customs is 1540 | potentially problematic in this scenario. Governments often create ad-hoc 1541 | solutions for their import solutions, which make securing the global 1542 | supply chain difficult as each government has their own method of 1543 | securing the supply chain and identifying corporations that downstream 1544 | customers need to integrate with. If you are a global company, that 1545 | means integrating with many supply chain systems (each with different 1546 | capabilities). As such, any securing of the supply chain with downstream 1547 | customers must then depend on the country-specific corporate 1548 | identification and PKI solution, which leads to ad-hoc solutions that 1549 | drive up the cost of doing business across borders. 1550 |

1551 |

1552 | A supply chain identifier solution that is simple, self-administered, 1553 | built on global standards, is flexible in the cryptographic mechanisms 1554 | used to authenticate, and can be used by governments and downstream 1555 | customers with little to no modification to the regional government 1556 | or corporate systems does not exist today. 1557 |

1558 |
1559 |
1560 |

7.1.4 Distinctions

1561 |

1562 | Many Decentralized Identifier use cases focus on Self-Sovereign 1563 | Identity and individuals. This use case focuses on organizations and 1564 | their departments as entities that would also benefit from 1565 | Decentralized Identifiers. 1566 |

1567 |
1568 |
1569 |
1570 |

7.2 Life-long, recipient-managed Credentials (education)

1571 |
1572 |

7.2.1 Background

1573 |

Educational Verifiable Credentials [VC-DATA-MODEL] offer benefits over traditional 1574 | educational credentials in that the recipient is able to store and 1575 | share their credentials, and a third party may independently verify 1576 | the credential (including authenticating the identity of the recipient), 1577 | without necessarily consulting the issuer, and without dependence on 1578 | centuries old treaty-based bureaucratic process for the international 1579 | verification of credentials. This provides the promise of recipient-owned 1580 | long-lived credentials that the recipient may use in any country, 1581 | even if the issuing institution goes out of business. 1582 |

1583 |

However, traditional public-private key pair-based identifiers 1584 | present challenges for rotating keys, especially if 1585 | the identifier in a credential is simply the public key (with 1586 | the private key used for authentication).

1587 |
    1588 |
  1. With the public key embedded in the digitally signed credential, 1589 | it is literally impossible to update the signing key; a recipient 1590 | must contact the issuer and request re-issuing with a new 1591 | identifer. If the issuer is not reachable, or is unwilling 1592 | or unable to issue a new credential, the recipient cannot 1593 | update the cryptographic material.
    2. 1594 |
  2. If the credential relies on a centralized key registry or 1595 | authority for managing rotation, then that registry becomes 1596 | the centralized point of failure. This may or may not be an 1597 | improvement, especially for longer held credentials.
    3. 1598 |
  3. If the credential's cryptographic technology becomes outdated, 1599 | there is no way to update the credential to use a more robust 1600 | technology; a recipient must contact the issuer for reissuance.
    4. 1601 |
1602 |

The key rotation is particularly problematic for credentials 1603 | expected to last a lifetime. It should be anticipated that 1604 | a given individual will change their key management strategy and 1605 | systems several times over the course of their life, e.g. relying 1606 | on a cloud wallet, a mobile wallet, or a dedicated hardware wallet, 1607 | as their needs change.

1608 |

By issuing an educational credential to a recipient's DID, the 1609 | recipient has the ability to prove ownership of a credential even 1610 | if the cryptographic material used for authenticating changes over time. 1611 |

1612 |
1613 |
1614 |

7.2.2 Description

1615 |

When Sally earned her master’s degree at Oxford, she received a 1616 | digital diploma that contained a decentralized identifier she provided. 1617 | Over time, she updates the cryptographic material associated with that 1618 | DID to use her latest hardware wallet, with biometric protections and a 1619 | quantum resistant algorithm. A decade after graduation, she applies for 1620 | a job in Japan, for which she provides her digital diploma by uploading 1621 | it to the prospective employee’s website. To verify she is the 1622 | actual recipient of that degree, she uses the decentralized identifier 1623 | to authenticate, using her current hardware wallet (with rotated keys). 1624 | In addition to the fact that her name matches the name on the diploma, 1625 | the cryptographic authentication provides a robust verification of her 1626 | claim, allowing the employer to rely on Sally’s assertion that she 1627 | earned a master’s degree from Oxford.

1628 |
1629 |
1630 |

7.2.3 Challenges

1631 |

Rotating keys without invalidating Sally's educational credentials and 1632 | providing acceptable proof of education internationally.

1633 |
1634 |
1635 |

7.2.4 Distinction

1636 |

Oxford had no need to provide services for resetting or updating 1637 | Sally’s username or password; they had no role in managing 1638 | Sally’s changes to her authentication credentials. The potential 1639 | employer did not need to contact Oxford to verify Sally’s claim of 1640 | a master’s degree; they were able to verify the credential and 1641 | authenticate Sally’s identity with information retrieved over the 1642 | Internet.

1643 |
1644 |
1645 |
1646 |

7.3 Prescriptions (healthcare)

1647 |
1648 |

7.3.1 Background

1649 |

1650 | Alicia wants help with her urinary tract infection (UTI) and is a bit 1651 | touchy about her privacy. In the old days, she would have to make an 1652 | appointment in-person and get a paper prescription to take to a 1653 | pharmacy. She wants to save money and have peace of mind. 1654 |

1655 |
1656 |
1657 |

7.3.2 Description

1658 |

1659 | Alicia is in a state that allows an online service to diagnose and 1660 | prescribe medication. She uses the identity wallet on her smartphone 1661 | to register with the online medical practice. She tells the online 1662 | practice her name is Althea (a pseudonym) 1663 | with password-less authentication and a verified driver's license 1664 | credential to prove that she's a resident of the state. The remote physician, 1665 | Barkley, is licensed by the state Board of Medicine and credentialed by the 1666 | online service. He's securely signed in using the 1667 | identity wallet on his smartphone. Barkley issues Alicia a digital 1668 | prescription in the form of a verifiable credential and allows Alicia 1669 | to download it however she pleases. Alicia is a librarian and trusts 1670 | her local public library to erase their logs as allowed by law. She 1671 | uses one of their computers to sign-in and do all of this. She snaps 1672 | a picture of the QR code that is the prescription to take to the 1673 | pharmacy. Connor, the licensed pharmacist, scans the prescription 1674 | QR code and fills the prescription. Alicia pays cash. 1675 |

1676 |
1677 |
1678 |

7.3.3 Challenges

1679 |

The challenge of this particular use-case is that only Barkley and 1680 | Connor are verified identities and accountable for their interaction 1681 | with Alicia. Alicia can be anonymous or pairwise-pseudonymous with both 1682 | Barkley and Connor and everything just works. Alicia, Barkley, and Connor 1683 | all keep separate and legally authentic copies of the records of their 1684 | interaction in case of dispute. 1685 |

1686 |
1687 |
1688 |

7.3.4 Distinction

1689 |

1690 | The Prescription use-case is a common and high-value example of 1691 | privacy engineering as we shift to convenient and cost-effective 1692 | online commerce among licensed and unlicensed individuals as peers. 1693 | Barkley and Connor benefit by reducing or even eliminating the influence 1694 | of their respective institutions or employers and therefore make more 1695 | money. They pass some savings to Alicia who also gets increased peace 1696 | of mind. 1697 |

1698 |
1699 |
1700 |
1701 |

7.4 Digital Executor (law)

1702 |
1703 |

7.4.1 Background

1704 |

1705 | Today, when people die, there are no standard technologies for heirs, 1706 | executors, or probate courts to properly take control of an individual's 1707 | online accounts and digital assets. With a DID linked to accounts and 1708 | assets, a DID owner could define a trigger for a third party to assume 1709 | control over the DID Document. Ideally, this trigger would specify (a) 1710 | an oracle (how to know the death/incapacity occurred), (b) a means for 1711 | the new owner to assert control, and (c) appropriate checks and 1712 | accountability. 1713 |

1714 |
1715 |
1716 |

7.4.2 Description

1717 |

1718 | Kathy uses DIDs to manage her authentications to various services. 1719 | As part of her estate planning, she generates a unique credential 1720 | that she gives to her attorney, Gloria, with provisions specified in 1721 | her will, which initially lists Mike as the digital executor. With 1722 | appropriate obfuscation, that credential is specified in multiple DID 1723 | documents as a probate authority, with the authorization to change the 1724 | master key in case of death, which shall be recorded publicly, on chain, 1725 | as a notarized invocation of the probate authority. As it happens, 1726 | Kathy had a falling out with Mike and notified Gloria just two weeks 1727 | before her death that her friend Miyake should now be her digital 1728 | executor. Upon Kathy's death, Gloria uses the probate credential to 1729 | publicly record the assertion of probate and to replace the DID's master 1730 | key with a new key, controlled by Miyake, who lives in Japan (Kathy, 1731 | Gloria, and Mike live in the United States). Now, any system using 1732 | Kathy's DIDs for authentication can programmatically recognized Miyake's 1733 | authority and specifically know that Kathy's credentials were 1734 | modified under a assertion of probate. 1735 |

1736 |
1737 |
1738 |

7.4.3 Challenges

1739 |

1740 | The late date change in digital executorship from Mike to Miyake 1741 | could be problematic if Kathy had directly listed Mike's credential 1742 | in the DID Document. Because she instead chose to rely on her attorney, 1743 | Kathy has a more flexible way to direct her wishes, while still 1744 | leveraging the collective control over her authenticated logins to 1745 | various services. In addition, Miyake's geographic location could 1746 | make it hard for them to travel to the United States and may make it 1747 | difficult to provide proof of identity traditionally used by U.S. courts. 1748 | Also, because Gloria invokes the probate mechanism, Miyake need only 1749 | provide a suitable credential at that time; he did not need to create 1750 | and maintain a credential over a long period of time (as would be the 1751 | case if Gloria weren't involved). 1752 |

1753 |
1754 |
1755 |

7.4.4 Distinction

1756 |

1757 | Multiple DIDs with a common, blinded authority for probate assumption 1758 | of control. The legal selection of the new owner is mediated through 1759 | a trusted fiduciary (an attorney of record). Cross-border transfer of 1760 | ownership. 1761 |

1762 |
1763 |
1764 |
1765 |

7.5 Single Sign On (security)

1766 |
1767 |

7.5.1 Background

1768 |

1769 | Passwords are notoriously misused ("123456"), stolen from the 1770 | supposedly-secure database on the server-side, easy to forget when 1771 | sufficiently secure, and never the last word in authentication for 1772 | forgotten password situations. Proving control of a DID can replace 1773 | storage and retrieval of a shared secret. 1774 |

1775 |
1776 |
1777 |

7.5.2 Description

1778 |
Editor's note

This section in particular needs review to ensure it carries 1779 | information relevant to the WG's work.

1780 |

Use a DID as a single-sign-on to a Web site, for example between 1781 | a Web page and a Web browser with a mobile identity app. When desirable, 1782 | the relationship can add a shared secret for 2FA.

1783 |

Detailed aspects of this use case are out of scope for the Decentralized 1784 | Identifier Working Group but they have been explored elsewhere [DID-Auth]. 1785 | 1786 | 1787 |

1788 | 1789 |
1790 |
1791 |

7.5.3 Challenges

1792 |

1793 | Transfer sign-on capability from control of a password to control of 1794 | 1795 | the DID. 1796 |

1797 |
1798 |
1799 |

7.5.4 Distinction

1800 |

1801 | This use case describes the most common authentication action for 1802 | people on the Internet. 1803 |

1804 |
1805 |
1806 |
1807 | 1808 | 1809 |
1810 |

A. References

1811 | 1812 |
1813 |

A.1 Informative references

1814 |
1815 |
[DID-Auth]
Introduction to DID Auth. Markus Sabadello; Kyle Den Hartog; Christian Lundkvist; Cedric Franz; Alberto Elias; Andrew Hughes; John Jordan; Dmitri Zagidulin. URL: https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.md
[DID-RESOLUTION]
Decentralized Identifier Resolution (DID Resolution). Markus Sabadello; Dmitri Zagidulin. W3C Community Group Report. URL: https://w3c-ccg.github.io/did-resolution/
[JSON-LD]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[RFC4122]
A Universally Unique IDentifier (UUID) URN Namespace. P. Leach; M. Mealling; R. Salz. IETF. July 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc4122
[RFC6901]
JavaScript Object Notation (JSON) Pointer. P. Bryan, Ed.; K. Zyp; M. Nottingham, Ed.. IETF. April 2013. Proposed Standard. URL: https://tools.ietf.org/html/rfc6901
[VC-DATA-MODEL]
Verifiable Credentials Data Model 1.0. Manu Sporny; Grant Noble; Dave Longley; Daniel Burnett; Brent Zundel. W3C. 5 September 2019. W3C Proposed Recommendation. URL: https://www.w3.org/TR/vc-data-model/
1816 |
-------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | All documents in this Repository are licensed by contributors 2 | under the 3 | [W3C Document License](https://www.w3.org/Consortium/Legal/copyright-documents). 4 | 5 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | ![W3C Logo](https://www.w3.org/Icons/w3c_home) 3 | 4 | # Decentralized Identifier Use Cases v1.0 5 | 6 | This is the repository of the W3C’s note on Decentralized Identifier Use Cases v1.0, developed by the [DID Working Group](https://www.w3.org/2019/did-wg/). The editors’ draft of the specification can also be [read directly](https://w3c.github.io/did-use-cases/). 7 | 8 | Work on this document has now been completed with publication of the [Use Cases and Requirements as a Working Group Note](https://www.w3.org/TR/2021/NOTE-did-use-cases-20210317/) on 17th March 2021. 9 | 10 | ## Contributing to the Repository 11 | 12 | Use the standard fork, branch, and pull request workflow to propose changes to the specification. Please make branch names informative—by including the issue or bug number for example. 13 | 14 | Editorial changes that improve the readability of the spec or correct spelling or grammatical mistakes are welcome. 15 | 16 | Please read [CONTRIBUTING.md](CONTRIBUTING.md), about licensing contributions. 17 | 18 | ## Code of Conduct 19 | 20 | W3C functions under a [code of conduct](https://www.w3.org/Consortium/cepc/). 21 | 22 | ## DID Working Group Repositories 23 | 24 | * [W3C Decentralized Identifier Specification v1.0](https://github.com/w3c/did-core) 25 | * [Home page of the Decentralized Identifier Working Group](https://github.com/w3c/did-wg) 26 | * [Specs and documentation for all DID-related /.well-known resources](https://github.com/decentralized-identity/.well-known) 27 | * [W3C Decentralized Characteristics Rubric v1.0](https://github.com/w3c/did-rubric) 28 | * [Decentralized Identifier Use Cases v1.0](https://github.com/w3c/did-use-cases) 29 | * [W3C DID Test Suite and Implementation Report](https://github.com/w3c/did-test-suite) 30 | -------------------------------------------------------------------------------- /common.js: -------------------------------------------------------------------------------- 1 | /* globals omitTerms, respecConfig, $, require */ 2 | /* exported linkCrossReferences, restrictReferences, fixIncludes */ 3 | 4 | var didwg = { 5 | // Add as the respecConfig localBiblio variable 6 | // Extend or override global respec references 7 | localBiblio: { 8 | "DID-CORE": { 9 | title: "Decentralized Identifiers", 10 | href: "https://w3c.github.io/did-core/", 11 | authors: [ 12 | "Drummond Reed", 13 | "Manu Sporny", 14 | "Dave Longley", 15 | "Christopher Allen", 16 | "Ryan Grant", 17 | "Markus Sabadello" 18 | ], 19 | status: "Editor's Draft", 20 | publisher: "Decentralized Identifier Working Group" 21 | }, 22 | "DID-METHOD-REGISTRY": { 23 | title: "The Decentralized Identifier Method Registry", 24 | href: "https://w3c-ccg.github.io/did-method-registry/", 25 | authors: [ 26 | "Manu Sporny", 27 | "Drummond Reed" 28 | ], 29 | status: "CG-DRAFT", 30 | publisher: "Credentials Community Group" 31 | }, 32 | "DID-RESOLUTION": { 33 | title: "Decentralized Identifier Resolution", 34 | href: "https://w3c-ccg.github.io/did-resolution/", 35 | authors: [ 36 | "Markus Sabadello", 37 | "Dmitri Zagidulin" 38 | ], 39 | status: "Draft Community Group Report", 40 | publisher: "Credentials Community Group" 41 | }, 42 | "DID-AUTH-INTRO": { 43 | title: "Introduction to DID Auth", 44 | href: "https://github.com/WebOfTrustInfo/rwot6-santabarbara/blob/master/final-documents/did-auth.md", 45 | authors: [ 46 | "Markus Sabadello", 47 | "Dmitri Zagidulin", 48 | "Kyle Den Hartog", 49 | "Christian Lundkvist", 50 | "Cedric Franz", 51 | "Alberto Elias", 52 | "Andrew Hughes", 53 | "John Jordan", 54 | "Dmitri Zagidulin" 55 | ], 56 | status: "Final Paper", 57 | publisher: "Rebooting the Web of Trust" 58 | }, 59 | "DID-AUTH-OIDC-SIOP": { 60 | title: "DID Auth profile for OpenID Connect", 61 | href: "https://github.com/decentralized-identity/papers/blob/master/did-authn/siop/did-authn-siop-profile.md", 62 | authors: [ 63 | "Oliver Terbu" 64 | ], 65 | status: "Draft", 66 | publisher: "Decentralized Identity Foundation" 67 | }, 68 | "CREDENTIAL-HANDLER-API": { 69 | title: "Credential Handler API", 70 | href: "https://w3c-ccg.github.io/credential-handler-api/", 71 | authors: [ 72 | "Dave Longley", 73 | "Manu Sporny" 74 | ], 75 | status: "Editor's Draft", 76 | publisher: "Credentials Community Group" 77 | } 78 | } 79 | }; 80 | 81 | 82 | 83 | // We should be able to remove terms that are not actually 84 | // referenced from the common definitions 85 | // 86 | // the termlist is in a block of class "termlist", so make sure that 87 | // has an ID and put that ID into the termLists array so we can 88 | // interrogate all of the included termlists later. 89 | var termNames = [] ; 90 | var termLists = [] ; 91 | var termsReferencedByTerms = [] ; 92 | 93 | function restrictReferences(utils, content) { 94 | "use strict"; 95 | var base = document.createElement("div"); 96 | base.innerHTML = content; 97 | 98 | // New new logic: 99 | // 100 | // 1. build a list of all term-internal references 101 | // 2. When ready to process, for each reference INTO the terms, 102 | // remove any terms they reference from the termNames array too. 103 | $.each(base.querySelectorAll("dfn"), function(i, item) { 104 | var $t = $(item) ; 105 | var titles = $t.getDfnTitles(); 106 | var dropit = false; 107 | // do we have an omitTerms 108 | if (window.hasOwnProperty("omitTerms")) { 109 | // search for a match 110 | $.each(omitTerms, function(j, term) { 111 | if (titles.indexOf(term) !== -1) { 112 | dropit = true; 113 | } 114 | }); 115 | } 116 | // do we have an includeTerms 117 | if (window.hasOwnProperty("includeTerms")) { 118 | var found = false; 119 | // search for a match 120 | $.each(includeTerms, function(j, term) { 121 | if (titles.indexOf(term) !== -1) { 122 | found = true; 123 | } 124 | }); 125 | if (!found) { 126 | dropit = true; 127 | } 128 | } 129 | if (dropit) { 130 | $t.parent().next().remove(); 131 | $t.parent().remove(); 132 | } else { 133 | var n = $t.makeID("dfn", titles[0]); 134 | if (n) { 135 | termNames[n] = $t.parent() ; 136 | } 137 | } 138 | }); 139 | 140 | var $container = $(".termlist",base) ; 141 | var containerID = $container.makeID("", "terms") ; 142 | termLists.push(containerID) ; 143 | 144 | return (base.innerHTML); 145 | } 146 | // add a handler to come in after all the definitions are resolved 147 | // 148 | // New logic: If the reference is within a 'dl' element of 149 | // class 'termlist', and if the target of that reference is 150 | // also within a 'dl' element of class 'termlist', then 151 | // consider it an internal reference and ignore it. 152 | 153 | require(["core/pubsubhub"], function(respecEvents) { 154 | "use strict"; 155 | respecEvents.sub('end', function(message) { 156 | if (message === 'core/link-to-dfn') { 157 | // all definitions are linked; find any internal references 158 | $(".termlist a.internalDFN").each(function() { 159 | var $r = $(this); 160 | var id = $r.attr('href'); 161 | var idref = id.replace(/^#/,"") ; 162 | if (termNames[idref]) { 163 | // this is a reference to another term 164 | // what is the idref of THIS term? 165 | var $def = $r.closest('dd') ; 166 | if ($def.length) { 167 | var $p = $def.prev('dt').find('dfn') ; 168 | var tid = $p.attr('id') ; 169 | if (tid) { 170 | if (termsReferencedByTerms[tid]) { 171 | termsReferencedByTerms[tid].push(idref); 172 | } else { 173 | termsReferencedByTerms[tid] = [] ; 174 | termsReferencedByTerms[tid].push(idref); 175 | } 176 | } 177 | } 178 | } 179 | }) ; 180 | 181 | // clearRefs is recursive. Walk down the tree of 182 | // references to ensure that all references are resolved. 183 | var clearRefs = function(theTerm) { 184 | if ( termsReferencedByTerms[theTerm] ) { 185 | $.each(termsReferencedByTerms[theTerm], function(i, item) { 186 | if (termNames[item]) { 187 | delete termNames[item]; 188 | clearRefs(item); 189 | } 190 | }); 191 | } 192 | // make sure this term doesn't get removed 193 | if (termNames[theTerm]) { 194 | delete termNames[theTerm]; 195 | } 196 | }; 197 | 198 | // now termsReferencedByTerms has ALL terms that 199 | // reference other terms, and a list of the 200 | // terms that they reference 201 | $("a.internalDFN").each(function () { 202 | var $item = $(this) ; 203 | var t = $item.attr('href'); 204 | var r = t.replace(/^#/,"") ; 205 | // if the item is outside the term list 206 | if ( ! $item.closest('dl.termlist').length ) { 207 | clearRefs(r); 208 | } 209 | }); 210 | 211 | // delete any terms that were not referenced. 212 | Object.keys(termNames).forEach(function(term) { 213 | var $p = $("#"+term) ; 214 | if ($p) { 215 | var tList = $p.getDfnTitles(); 216 | $p.parent().next().remove(); 217 | $p.parent().remove() ; 218 | tList.forEach(function( item ) { 219 | if (respecConfig.definitionMap[item]) { 220 | delete respecConfig.definitionMap[item]; 221 | } 222 | }); 223 | } 224 | }); 225 | } 226 | }); 227 | }); 228 | -------------------------------------------------------------------------------- /images/didCreate.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 6 | 7 | 36 | 37 | 38 | 39 | 41 | 42 | 43 | 44 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | Create 61 | 62 | 63 | 64 | Subject 65 | 66 | 67 | 68 | 69 | Controller 70 | 71 | 72 | 73 | 74 | Create 75 | 76 | 77 | 78 | DID 79 | 80 | 81 | 82 | Register DID 83 | 84 | 85 | 86 | Registry 87 | 88 | 89 | 90 | 91 | -------------------------------------------------------------------------------- /images/didDelete.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 6 | 7 | 58 | 59 | 60 | 61 | 62 | 63 | 65 | 66 | 67 | 68 | 70 | 71 | 72 | 73 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | Deactivate 92 | 93 | 94 | 95 | Controller 96 | 97 | 98 | 99 | 100 | Deactivate DID 101 | 102 | 103 | 104 | Registry 105 | 106 | 107 | 108 | Requesting party 109 | 110 | 111 | 112 | 113 | Resolve DID 114 | 115 | 116 | 117 | 118 | 'Inactive' 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | -------------------------------------------------------------------------------- /images/didRead.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 6 | 7 | 46 | 47 | 48 | 49 | 50 | 51 | 53 | 54 | 55 | 56 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | Read 73 | 74 | 75 | Registry 76 | 77 | 78 | 79 | Resolve DID 80 | 81 | DID Doc 82 | 83 | Audit 84 | 85 | 86 | 87 | 88 | Requesting Party 89 | 90 | 91 | 92 | Service endpoint 93 | 94 | 95 | 96 | 97 | Dereference DID 98 | 99 | 100 | 101 | 102 | Identity provider 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | -------------------------------------------------------------------------------- /images/didUpdate.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 6 | 7 | 46 | 47 | 48 | 49 | 50 | 51 | 53 | 54 | 55 | 56 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | Update 73 | 74 | 75 | 76 | Controller 77 | 78 | 79 | 80 | 81 | Modify 82 | 83 | 84 | 85 | 86 | Service endpoints 87 | 88 | 89 | Forward/Migrate 90 | 91 | 92 | Recovery material 93 | 94 | 95 | 96 | 97 | Rotate or revoke 98 | 99 | 100 | 101 | Public proof material 102 | 103 | 104 | 105 | 106 | 107 | -------------------------------------------------------------------------------- /images/didUse.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 6 | 7 | 37 | 38 | 39 | 40 | 41 | 42 | 44 | 45 | 46 | 47 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | Use 66 | 67 | 68 | 69 | Controller 70 | 71 | 72 | 73 | 74 | Present 75 | 76 | 77 | 78 | DID 79 | 80 | 81 | 82 | Publish 83 | 84 | 85 | 86 | Public proof material 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | Resolve 96 | 97 | 98 | 99 | 100 | Requesting Party 101 | 102 | 103 | 104 | Private proof material 105 | 106 | 107 | 108 | Sign using 109 | 110 | 111 | 112 | Challenge string 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | Auth request 121 | 122 | 123 | 124 | Signed response 125 | 126 | 127 | 128 | Auth response 129 | 130 | 131 | 132 | 133 | Verify signature 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | -------------------------------------------------------------------------------- /images/did_actions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/did-use-cases/24b7848b1651ac718f1239aa929f346b7a369c5e/images/did_actions.png -------------------------------------------------------------------------------- /images/domainMap.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 6 | 41 | 42 | 43 | 44 | 45 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | Use cases 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | Learners & workers 91 | 92 | 93 | 94 | 95 | 6.2 Lifelong credentials 96 | 97 | 98 | 99 | 100 | 2.7 Pseudonymous work 101 | 102 | 103 | 104 | 105 | 106 | 2.5 Transferable skills 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | Law & legal 128 | 129 | 130 | 131 | 132 | 2.9 Permanent residence 133 | 134 | 135 | 136 | 137 | 6.4 Digital executor 138 | 139 | 140 | 141 | 142 | 2.11 Public Authority creds 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | Corporate 166 | 167 | 168 | 169 | 170 | 2.4 Accessing data 171 | 172 | 173 | 174 | 175 | 6.1 Enterprise identifiers 176 | 177 | 178 | 179 | 180 | 2.3 Confidential engage 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | Retail & consumer 202 | 203 | 204 | 205 | 206 | 207 | 2.12 Correlation control 208 | 209 | 210 | 211 | 212 | 213 | 214 | 2.1 Online shopper 215 | 216 | 217 | 218 | 219 | 6.3 Prescriptions 220 | 221 | 222 | 223 | 224 | 6.5 Alice rents a car 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | Supply chain 255 | 256 | 257 | 258 | 259 | 260 | 2.10 Import retro toys 261 | 262 | 263 | 264 | 265 | 2.2 Vehicle assemblies 266 | 267 | 268 | 269 | 270 | 2.8 Pseudomymous dist. 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | Auth’n & authorization 293 | 294 | 295 | 296 | 297 | 6.6 Secure Comms 298 | 299 | 300 | 301 | 302 | 2.6 X-platform sharing 303 | 304 | 305 | 306 | 307 | 308 | 309 | 310 | 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": [117488] 3 | , "contacts": ["iherman"] 4 | , "repo-type": "note" 5 | , "shortName": "did-use-cases" 6 | } 7 | --------------------------------------------------------------------------------