;
109 | .
110 |
--------------------------------------------------------------------------------
/vocabs/v1/vocab.jsonld:
--------------------------------------------------------------------------------
1 | {
2 | "@context": {
3 | "domain": {
4 | "@id": "http://www.w3.org/2000/01/rdf-schema#domain",
5 | "@type": "@id"
6 | },
7 | "range": {
8 | "@id": "http://www.w3.org/2000/01/rdf-schema#range",
9 | "@type": "@id"
10 | },
11 | "isDefinedBy": {
12 | "@id": "http://www.w3.org/2000/01/rdf-schema#isDefinedBy",
13 | "@type": "@id"
14 | },
15 | "label": {
16 | "@id": "http://www.w3.org/2000/01/rdf-schema#label"
17 | },
18 | "comment": {
19 | "@id": "http://www.w3.org/2000/01/rdf-schema#comment"
20 | },
21 | "sec": "https://w3id.org/security#",
22 | "as": "https://www.w3.org/ns/activitystreams#",
23 | "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
24 | "owl": "http://www.w3.org/2002/07/owl#",
25 | "xsd": "http://www.w3.org/2001/XMLSchema#",
26 | "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
27 | "did": "https://www.w3.org/ns/did#"
28 | },
29 | "@graph": [
30 | {
31 | "@id": "https://www.w3.org/ns/did#",
32 | "@type": "owl:Ontology",
33 | "comment": "For historical reasons, most of the terms are in the 'sec:' namespace rather than the 'did:' namespace. These terms do not describe/define any cryptographic primitives and are formally defined in the DID Core specification. Future Working Group may define a formal specification for the complete 'sec:' vocabulary."
34 | },
35 | {
36 | "@id": "did:DIDSubject",
37 | "@type": "rdfs:Class",
38 | "comment": "Top level class for resources identified via a DID subject",
39 | "isDefinedBy": "https://www.w3.org/TR/did-core/#core-properties",
40 | "label": "DID Document"
41 | },
42 | {
43 | "@id": "did:Service",
44 | "@type": "rdfs:Class",
45 | "comment": "Service endpoints are used in DID documents to express ways of communicating with the DID subject or associated entities",
46 | "isDefinedBy": "https://www.w3.org/TR/did-core/#services",
47 | "label": "Service Endpoint"
48 | },
49 | {
50 | "@id": "did:VerificationMethod",
51 | "@type": "rdfs:Class",
52 | "comment": "Superclass for all specific verification Methods. It is an 'abstract' class, never used by itself.",
53 | "isDefinedBy": "https://www.w3.org/TR/did-core/#verification-methods",
54 | "label": "Verification Method"
55 | },
56 | {
57 | "@id": "sec:assertionMethod",
58 | "@type": "rdf:Property",
59 | "comment": "The assertionMethod property is used to express a verification relationship which indicates that a verification method can be used to verify a proof that a statement was asserted on behalf of the DID subject.",
60 | "isDefinedBy": "https://www.w3.org/TR/did-core/#assertion",
61 | "range": "did:VerificationMethod"
62 | },
63 | {
64 | "@id": "sec:authenticationMethod",
65 | "@type": "rdf:Property",
66 | "comment": "Authentication is a verification relationship which an entity can use to prove it is the DID subject or acting on behalf of the DID Subject as a DID Controller.",
67 | "isDefinedBy": "https://www.w3.org/TR/did-core/#authentication",
68 | "range": "did:VerificationMethod"
69 | },
70 | {
71 | "@id": "sec:capabilityDelegationMethod",
72 | "@type": "rdf:Property",
73 | "comment": "The capabilityDelegation property is used to express a verification relationship which an entity can use to grant capabilities as the DID subject or on behalf of the DID subject to other capability invokers. ",
74 | "isDefinedBy": "https://www.w3.org/TR/did-core/#capability-delegation",
75 | "range": "did:VerificationMethod"
76 | },
77 | {
78 | "@id": "sec:capabilityInvocationMethod",
79 | "@type": "rdf:Property",
80 | "comment": "The capabilityInvocation property is used to express a verification relationship which an entity can use to invoke capabilities as the DID subject or on behalf of the DID subject.",
81 | "isDefinedBy": "https://www.w3.org/TR/did-core/#capability-invocation",
82 | "range": "did:VerificationMethod"
83 | },
84 | {
85 | "@id": "sec:controller",
86 | "@type": "rdf:Property",
87 | "comment": "An entity that is authorized to make changes to a DID Document",
88 | "isDefinedBy": "https://www.w3.org/TR/did-core/#control"
89 | },
90 | {
91 | "@id": "sec:keyAgreementMethod",
92 | "@type": "rdf:Property",
93 | "comment": "The keyAgreement property is used to express a verification relationship which an entity can use to engage in key agreement protocols on behalf of the DID subject.",
94 | "isDefinedBy": "https://www.w3.org/TR/did-core/#key-agreement",
95 | "range": "did:VerificationMethod"
96 | },
97 | {
98 | "@id": "sec:publicKeyMultibase",
99 | "@type": [
100 | "rdf:Property",
101 | "owl:DatatypeProperty"
102 | ],
103 | "domain": "did:VerificationMethod",
104 | "isDefinedBy": "https://www.w3.org/TR/did-core/#verification-methods",
105 | "label": "A string that conforms to a multibase encoded public key",
106 | "range": "xsd:string"
107 | },
108 | {
109 | "@id": "sec:publicKeyJwk",
110 | "@type": [
111 | "rdf:Property",
112 | "owl:DatatypeProperty"
113 | ],
114 | "domain": "did:VerificationMethod",
115 | "isDefinedBy": "https://www.w3.org/TR/did-core/#verification-methods",
116 | "label": "Public Key in JWK",
117 | "range": "rdf:JSON"
118 | },
119 | {
120 | "@id": "sec:verificationMethod",
121 | "@type": "rdf:Property",
122 | "comment": "A generic method to refer to a Verification Method",
123 | "isDefinedBy": "https://www.w3.org/TR/did-core/#verification-methods",
124 | "range": "did:VerificationMethod"
125 | },
126 | {
127 | "@id": "as:alsoKnownAs",
128 | "@type": "rdf:Property",
129 | "comment": "This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers.",
130 | "isDefinedBy": "https://www.w3.org/TR/did-core/#also-known-as"
131 | },
132 | {
133 | "@id": "did:service",
134 | "@type": "rdf:Property",
135 | "domain": "did:DIDSubject",
136 | "isDefinedBy": "https://www.w3.org/TR/did-core/#services",
137 | "range": "did:Service"
138 | },
139 | {
140 | "@id": "did:serviceEndpoint",
141 | "@type": "rdf:Property",
142 | "domain": "did:Service",
143 | "isDefinedBy": "https://www.w3.org/TR/did-core/#services"
144 | }
145 | ]
146 | }
147 |
--------------------------------------------------------------------------------
/vocabs/v1/shacl.jsonld:
--------------------------------------------------------------------------------
1 | {
2 | "@context": {
3 | "path": {
4 | "@id": "http://www.w3.org/ns/shacl#path",
5 | "@type": "@id"
6 | },
7 | "pattern": {
8 | "@id": "http://www.w3.org/ns/shacl#pattern"
9 | },
10 | "nodeKind": {
11 | "@id": "http://www.w3.org/ns/shacl#nodeKind",
12 | "@type": "@id"
13 | },
14 | "datatype": {
15 | "@id": "http://www.w3.org/ns/shacl#datatype",
16 | "@type": "@id"
17 | },
18 | "maxCount": {
19 | "@id": "http://www.w3.org/ns/shacl#maxCount",
20 | "@type": "http://www.w3.org/2001/XMLSchema#integer"
21 | },
22 | "minCount": {
23 | "@id": "http://www.w3.org/ns/shacl#minCount",
24 | "@type": "http://www.w3.org/2001/XMLSchema#integer"
25 | },
26 | "targetObjectsOf": {
27 | "@id": "http://www.w3.org/ns/shacl#targetObjectsOf",
28 | "@type": "@id"
29 | },
30 | "targetClass": {
31 | "@id": "http://www.w3.org/ns/shacl#targetClass",
32 | "@type": "@id"
33 | },
34 | "not": {
35 | "@id": "http://www.w3.org/ns/shacl#not",
36 | "@type": "@id"
37 | },
38 | "property": {
39 | "@id": "http://www.w3.org/ns/shacl#property",
40 | "@type": "@id"
41 | },
42 | "targetSubjectsOf": {
43 | "@id": "http://www.w3.org/ns/shacl#targetSubjectsOf",
44 | "@type": "@id"
45 | },
46 | "sec": "https://w3id.org/security#",
47 | "as": "https://www.w3.org/ns/activitystreams#",
48 | "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
49 | "sh": "http://www.w3.org/ns/shacl#",
50 | "xsd": "http://www.w3.org/2001/XMLSchema#",
51 | "did": "https://www.w3.org/ns/did#"
52 | },
53 | "@graph": [
54 | {
55 | "@id": "_:ObjectShape",
56 | "@type": "sh:NodeShape",
57 | "property": [
58 | {
59 | "nodeKind": "sh:IRI",
60 | "path": "sec:capabilityDelegationMethod"
61 | },
62 | {
63 | "nodeKind": "sh:IRI",
64 | "path": "sec:verificationMethod"
65 | },
66 | {
67 | "nodeKind": "sh:IRI",
68 | "path": "sec:authenticationMethod"
69 | },
70 | {
71 | "nodeKind": "sh:IRI",
72 | "path": "did:capabilityInvocationMethod"
73 | },
74 | {
75 | "nodeKind": "sh:IRI",
76 | "path": "as:alsoKnownAs"
77 | },
78 | {
79 | "path": "sec:controller",
80 | "pattern": "^did:[a-z0-9]+:[a-zA-Z0-9.-_:]+"
81 | },
82 | {
83 | "nodeKind": "sh:IRI",
84 | "path": "sec:keyAgreementMethod"
85 | },
86 | {
87 | "nodeKind": "sh:IRI",
88 | "path": "sec:assertionMethod"
89 | },
90 | {
91 | "nodeKind": "sh:IRI",
92 | "path": "did:service"
93 | }
94 | ],
95 | "targetClass": "did:DIDSubject",
96 | "targetSubjectsOf": [
97 | "as:alsoKnownAs",
98 | "sec:authenticationMethod",
99 | "did:service",
100 | "sec:capabilityDelegationMethod",
101 | "sec:keyAgreementMethod",
102 | "sec:verificationMethod",
103 | "sec:assertionMethod",
104 | "sec:capabilityInvocationMethod"
105 | ]
106 | },
107 | {
108 | "@id": "_:VerificationMethodShape",
109 | "@type": "sh:NodeShape",
110 | "not": {
111 | "@id": "_:b5",
112 | "@type": "sh:NodeShape",
113 | "property": [
114 | {
115 | "sh:minCount": 1,
116 | "path": "sec:publicKeyMultibase"
117 | },
118 | {
119 | "sh:minCount": 1,
120 | "path": "sec:publicKeyJwk"
121 | }
122 | ]
123 | },
124 | "property": [
125 | {
126 | "datatype": "rdf:JSON",
127 | "sh:maxCount": 1,
128 | "nodeKind": "sh:Literal",
129 | "path": "sec:publicKeyJwk"
130 | },
131 | {
132 | "sh:minCount": 1,
133 | "path": "sec:controller",
134 | "pattern": "^did:[a-z0-9]+:[a-zA-Z0-9.-_:]+"
135 | },
136 | {
137 | "sh:minCount": 1,
138 | "nodeKind": "sh:IRI",
139 | "path": "rdf:type"
140 | },
141 | {
142 | "datatype": "xsd:string",
143 | "sh:maxCount": 1,
144 | "nodeKind": "sh:Literal",
145 | "path": "sec:publicKeyMultibase"
146 | }
147 | ],
148 | "targetClass": "did:VerificationMethod",
149 | "targetObjectsOf": [
150 | "sec:capabilityInvocationMethod",
151 | "sec:assertionMethod",
152 | "sec:keyAgreementMethod",
153 | "sec:verificationMethod",
154 | "sec:capabilityDelegationMethod",
155 | "sec:authenticationMethod"
156 | ]
157 | },
158 | {
159 | "@id": "_:ServiceShape",
160 | "@type": "sh:NodeShape",
161 | "property": [
162 | {
163 | "@id": "_:b3",
164 | "sh:minCount": 1,
165 | "nodeKind": "sh:BlankNodeOrIRI",
166 | "path": "did:serviceEndpoint"
167 | },
168 | {
169 | "@id": "_:b19",
170 | "sh:minCount": 1,
171 | "nodeKind": "sh:IRI",
172 | "path": "rdf:type"
173 | }
174 | ],
175 | "targetClass": "did:ServiceEndpoint",
176 | "targetObjectsOf": "did:service"
177 | }
178 | ]
179 | }
180 |
--------------------------------------------------------------------------------
/json_schemas/core.schema.json:
--------------------------------------------------------------------------------
1 | {
2 | "$schema": "http://json-schema.org/draft-07/schema#",
3 | "$id": "https://w3c.github.io/did-spec-registries/schemas/core.schema.json",
4 | "title": "DID Core Vocabulary schema",
5 | "$comment": "The JWK.schema part is a copy of the JWK schema (https://preview.npmjs.com/package/jwk-schema), published by Jonathan Wilbur (https://github.com/JonathanWilbur)",
6 | "definitions": {
7 | "did.schema" : {
8 | "type" : "string",
9 | "pattern" : "^did:[a-z0-9]+:[a-zA-Z0-9.-_:]+"
10 | },
11 |
12 | "type.schema" : {
13 | "type" : [
14 | "string",
15 | "array"
16 | ],
17 | "uniqueItems": true,
18 | "items" : {
19 | "type" : "string"
20 | }
21 | },
22 |
23 | "JWK.schema" : {
24 | "type" : "object",
25 | "properties": {
26 | "kty": {
27 | "type": "string"
28 | },
29 | "use": {
30 | "type": "string"
31 | },
32 | "key_ops": {
33 | "type": "array",
34 | "items": {
35 | "type": "string"
36 | }
37 | },
38 | "alg": {
39 | "type": "string"
40 | },
41 | "kid": {
42 | "type": "string"
43 | },
44 | "x5u": {
45 | "type": "string"
46 | },
47 | "x5c": {
48 | "type": "array",
49 | "items": {
50 | "type": "string"
51 | }
52 | },
53 | "x5t": {
54 | "type": "string"
55 | },
56 | "x5t#S256": {
57 | "type": "string"
58 | }
59 | },
60 | "required": ["kty"],
61 | "additionalProperties": true
62 | },
63 |
64 | "one_verification_method.schema" : {
65 | "type" : "object",
66 | "properties": {
67 | "publicKeyJwk" : {
68 | "$ref" : "#/definitions/JWK.schema"
69 | },
70 | "publicKeyMultibase" : {
71 | "type" : "string"
72 | },
73 | "controller" : {
74 | "$ref" : "#/definitions/did.schema"
75 | },
76 | "id" : {
77 | "type": "string",
78 | "format" : "uri-reference"
79 | },
80 | "type" : {
81 | "$ref" : "#/definitions/type.schema"
82 | }
83 | },
84 | "required" : ["id", "type", "controller"],
85 | "not": {
86 | "required" : ["publicKeyJwk","publicKeyMultibase"]
87 | },
88 | "additionalProperties" : true
89 | },
90 |
91 | "verification_method_strict.schema" : {
92 | "type" : "array",
93 | "uniqueItems": true,
94 | "items" : {
95 | "$ref" : "#/definitions/one_verification_method.schema"
96 | }
97 | },
98 |
99 | "verification_method_with_urls.schema" : {
100 | "type" : "array",
101 | "uniqueItems": true,
102 | "items" : {
103 | "oneOf" : [
104 | {
105 | "type": "string",
106 | "format" : "uri-reference"
107 | },
108 | {
109 | "$ref" : "#/definitions/one_verification_method.schema"
110 | }
111 | ]
112 | }
113 | },
114 |
115 | "service.schema" : {
116 | "type" : "array",
117 | "uniqueItems": true,
118 | "items" : {
119 | "type" : "object",
120 | "properties" : {
121 | "id" : {
122 | "type" : "string",
123 | "format" : "uri-reference"
124 | },
125 | "type" : {
126 | "$ref" : "#/definitions/type.schema"
127 | },
128 | "serviceEndpoint" : {
129 | "oneOf" : [
130 | {
131 | "type": "string",
132 | "format" : "uri-reference"
133 | },
134 | {
135 | "type" : "object"
136 | },
137 | {
138 | "type" : "array",
139 | "uniqueItems": true,
140 | "items": {
141 | "oneOf" : [
142 | {
143 | "type": "string",
144 | "format" : "uri-reference"
145 | },
146 | {
147 | "type" : "object"
148 | }
149 | ]
150 | }
151 | }
152 | ]
153 | }
154 | },
155 | "required": ["id", "type", "serviceEndpoint"],
156 | "additionalProperties" : true
157 | }
158 | }
159 | },
160 |
161 | "type": "object",
162 | "properties": {
163 | "id" : {
164 | "$ref" : "#/definitions/did.schema"
165 | },
166 | "alsoKnownAs" : {
167 | "type" : "array",
168 | "uniqueItems": true,
169 | "items": {
170 | "type" : "string",
171 | "format" : "uri-reference"
172 | }
173 | },
174 | "controller" : {
175 | "$ref" : "#/definitions/did.schema"
176 | },
177 | "verificationMethod" : {
178 | "$ref" : "#/definitions/verification_method_strict.schema"
179 | },
180 | "authentication" : {
181 | "$ref" : "#/definitions/verification_method_with_urls.schema"
182 | },
183 | "assertionMethod" : {
184 | "$ref" : "#/definitions/verification_method_with_urls.schema"
185 | },
186 | "keyAgreement" : {
187 | "$ref" : "#/definitions/verification_method_with_urls.schema"
188 | },
189 | "capabilityDelegation" : {
190 | "$ref" : "#/definitions/verification_method_with_urls.schema"
191 | },
192 | "capabilityInvocation" : {
193 | "$ref" : "#/definitions/verification_method_with_urls.schema"
194 | },
195 | "service" : {
196 | "$ref" : "#/definitions/service.schema"
197 | }
198 | },
199 | "required" : ["id"],
200 | "additionalProperties" : true
201 | }
202 |
--------------------------------------------------------------------------------
/vocabs/v1/vocab.rdf:
--------------------------------------------------------------------------------
1 |
2 |
6 |
7 |
8 | For historical reasons, most of the terms are in the 'security' namespace rather than the 'did' namespace. These terms do not describe/define any cryptographic primitives and are formally defined in the DID Core specification. Future Working Group may define a formal specification for the complete 'sec:' vocabulary.
9 |
10 |
11 |
12 | This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers.
13 |
14 |
15 |
16 |
17 | Authentication is a verification relationship which an entity can use to prove it is the DID subject or acting on behalf of the DID Subject as a DID Controller.
18 |
19 |
20 |
21 |
22 | Service endpoints are used in DID documents to express ways of communicating with the DID subject or associated entities
23 |
24 |
25 | Service Endpoint
26 |
27 |
28 |
29 |
30 |
31 |
32 | Public Key in JWK
33 |
34 |
35 |
36 |
37 |
38 |
39 |
40 |
41 |
42 | The assertionMethod property is used to express a verification relationship which indicates that a verification method can be used to verify a proof that a statement was asserted on behalf of the DID subject.
43 |
44 |
45 |
46 |
47 |
48 |
49 | The capabilityInvocation property is used to express a verification relationship which an entity can use to invoke capabilities as the DID subject or on behalf of the DID subject.
50 |
51 |
52 |
53 | The keyAgreement property is used to express a verification relationship which an entity can use to engage in key agreement protocols on behalf of the DID subject.
54 |
55 |
56 |
57 |
58 |
59 |
60 |
61 |
62 |
63 | A string that conforms to a multibase encoded public key
64 |
65 |
66 |
67 |
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
76 | The capabilityDelegation property is used to express a verification relationship which an entity can use to grant capabilities as the DID subject or on behalf of the DID subject to other capability invokers.
77 |
78 |
79 |
80 |
81 | Verification Method
82 | Superclass for all specific verification Methods. It is an 'abstract' class, never used by itself.
83 |
84 |
85 |
86 |
87 |
88 | A generic method to refer to a Verification Method
89 |
90 |
91 |
92 | An entity that is authorized to make changes to a DID Document
93 |
94 |
95 |
96 |
97 | DID Document
98 |
99 | Top level class for resources identified via a DID subject
100 |
101 |
102 |
--------------------------------------------------------------------------------
/methods/index.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | DID Methods
6 |
7 |
12 |
13 |
14 |
71 |
208 |
236 |
237 |
238 |
239 |
240 | This document serves as a collection of known DID Methods.
241 |
242 |
243 |
244 |
245 |
246 |
247 | Comments regarding this document are welcome. Please file issues
248 | directly on
249 | GitHub,
250 | or send them
251 | to public-did-wg@w3.org (
252 | subscribe,
253 | archives).
254 |
255 |
256 |
257 | Portions of the work on this specification have been funded by the
258 | United States Department of Homeland Security's Science and Technology
259 | Directorate under contracts HSHQDC-16-R00012-H-SB2016-1-002, 70RSAT20T00000010,
260 | and HSHQDC-17-C-00019. The content of this specification does not
261 | necessarily reflect the position or the policy of the U.S. Government
262 | and no official endorsement should be inferred.
263 |
264 |
265 |
266 | Work on this registry has also been supported by the Rebooting the
267 | Web of Trust community facilitated by Christopher Allen, Shannon
268 | Appelcline, Kiara Robles, Brian Weller, Betty Dhamers, Kaliya Young,
269 | Kim Hamilton Duffy, Manu Sporny, Drummond Reed, Joe Andrieu, and
270 | Heather Vescent, Dmitri Zagidulin, and Dan Burnett.
271 |
272 |
273 |
274 |
291 |
292 |
293 | DID Methods
294 |
295 |
296 | This table summarizes the DID method specifications currently in development.
297 | The links will be updated as subsequent Implementer’s Drafts are produced.
298 | This registry does not act as an endorsement of any particular DID method or its
299 | underlying technologies by the W3C, the W3C Decentralized Identifier Working Group,
300 | or any affiliated members of the W3C. It exists as a mechanism for developers to
301 | discover various DID methods that they might wish to implement.
302 |
303 |
304 | The normative requirements for DID method specifications can be found in
305 | Decentralized Identifiers
306 | v1.0: Methods [[DID-CORE]]. DID methods that do not meet these requirements
307 | will not be accepted. We encourage DID method authors to provide an email
308 | address in the Author Links column, as this helps with maintenance.
309 | If an email address is omitted, a label noting that there is no
310 | contact information for the author will be applied to the registry entry.
311 |
312 |
313 |
314 |
315 |
316 |
317 |
318 |
319 |
--------------------------------------------------------------------------------
/vocabs/v1/vocab.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 | DID Core v1.0 Terms
7 |
8 |
9 |
10 |
12 |
13 |
65 |
79 |
80 |
81 |
82 |
83 |
84 | This the namespace document for the Linked Data Vocabulary representation of the DID Core v1.0 data model.
85 |
86 |
87 |
88 |
90 |
91 |
92 |
93 | Introduction
94 |
95 |
96 |
97 | This document contains the vocabulary terms defined in the DID Core v1.0 data model [[did-core]]. The following namespaces are used:
98 |
99 |
100 | - DID Core Namespace
101 | https://www.w3.org/ns/did#
102 | - Security Vocabulary Namespace
103 | https://w3id.org/security#
104 | - ActivityStreams 2.0 Terms
105 | https://www.w3.org/ns/activitystreams#
106 |
107 |
108 |
109 | While the DID Core v1.0 namespace URI is https://www.w3.org/ns/did#, for historical reasons most of the terms are in the https://w3id.org/security# namespace, though defined in the DID Core specification [[did-core]]. These terms do not define any cryptographic primitives and are formally defined in the DID Core specification. Future Working Group may define a formal specification for the complete security vocabulary.
110 |
111 |
112 | Some of the terms, as defined in the DID Core specification [[did-core]], use a slightly different term name as their full URIs. For example, the term https://w3id.org/security#keyAgreementMethod is referred to as keyAgreement in the DID Core specification. The mapping is done, for JSON-LD, by the official JSON-LD Context. For the sake of clarity, section
113 | below references both those terms.
114 |
115 |
116 |
117 | Extensions to DID Core v1.0 terms can be found in the DID Specification Registries [[did-spec-registries]]. Extensions may be in the https://w3id.org/security# namespace or may have their own namespaces; they have their own JSON-LD Contexts.
118 |
119 |
120 |
121 |
122 | Formal Versions of the Vocabulary
123 |
124 | The formal RDF [[rdf11-concepts]] vocabulary, using RDFS [[rdf-schema]] terms, is available in the following formats:
125 |
126 |
127 |
128 | - Turtle:
129 | - https://www.w3.org/ns/did.ttl
130 | - JSON-LD:
131 | - https://www.w3.org/ns/did.jsonld
132 | - RDF/XML:
133 | - https://www.w3.org/ns/did.rdf
134 |
135 |
136 |
137 | These files can also be accessed using content negotiations on the https://www.w3.org/ns/did URI HTTP request, referring to the text/turtle, application/ld+json, or application/rdf+xml media types, respectively,
138 |
139 |
140 |
141 |
142 |
143 | Vocabulary
144 |
145 |
146 |
147 |
148 | Classes
149 |
150 |
151 | Note: the RDFS Classes are not defined in the DID Core v1.0 specification [[did-core]] and are only used by the formal RDFS vocabulary specification. Users of the JSON-LD representation of the DID Data Model are advised not to use
152 | these.
153 |
154 |
155 |
156 | DIDSubject
157 | -
158 |
159 | - URI:
https://www.w3.org/ns/did#serviceEndpoint
160 |
161 |
162 | Service
163 | -
164 |
165 | - URI:
https://www.w3.org/ns/did#Service
166 |
167 |
168 | VerificationMethod
169 | -
170 |
171 | - URI:
https://www.w3.org/ns/did#VerificationMethod
172 |
173 |
174 |
175 |
176 |
177 |
178 | Properties
179 |
180 |
181 | Terms are listed here in alphabetical order, and linked to their definitions in the DID Core v1.0 [[did-core]] specification.
182 |
183 |
184 |
185 | alsoKnownAs
186 | -
187 |
191 |
192 |
193 | assertionMethod
194 | -
195 |
199 |
200 |
201 | authenticationMethod, referred to as authentication
202 | -
203 |
207 |
208 |
209 | capabilityDelegationMethod, referred to as capabilityDelegation
210 | -
211 |
215 |
216 |
217 | capabilityInvocationMethod, referred to as capabilityInvocation
218 | -
219 |
223 |
224 |
225 | controller
226 | -
227 |
231 |
232 |
233 | keyAgreementMethod, referred to as keyAgreement
234 | -
235 |
239 |
240 |
241 | publicKeyMultibase
242 | -
243 |
247 |
248 |
249 | publicKeyJwk
250 | -
251 |
255 |
256 |
257 | service
258 | -
259 |
263 |
264 |
265 |
266 | serviceEndpoint
267 | -
268 |
272 |
273 |
274 |
275 | verificationMethod
276 | -
277 |
281 |
282 |
283 |
284 |
285 |
286 |
287 |
288 | Constraints Definitions
289 |
290 | Although not formally part of the Vocabulary specification, the RDF shape constraints, related to this vocabulary, are also available:
291 |
292 |
293 | - Expressed in SHACL [[shacl]], available in Turtle or JSON-LD formats.
294 | - Expressed in ShEx [[shex]], available in shex format.
295 |
296 |
297 |
298 |
299 |
300 |
301 |
302 |
303 |
304 |
305 |
--------------------------------------------------------------------------------
/index.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | Decentralized Identifier Extensions
6 |
7 |
12 |
13 |
15 |
141 |
169 |
170 |
171 |
172 |
173 | This document serves as a repository for all known global parameters,
174 | properties, and values used by the Decentralized Identifier ecosystem.
175 |
176 |
177 |
178 |
179 |
180 |
181 | This repository is under active development and implementers are advised
182 | against using the repository unless they are directly involved with the
183 | W3C DID Working Group.
184 |
185 |
186 |
187 | Comments regarding this document are welcome. Please file issues
188 | directly on
189 | GitHub,
190 | or send them
191 | to public-did-wg@w3.org (
192 | subscribe,
193 | archives).
194 |
195 |
196 |
197 | Portions of the work on this specification have been funded by the
198 | United States Department of Homeland Security's Science and Technology
199 | Directorate under contracts HSHQDC-16-R00012-H-SB2016-1-002, 70RSAT20T00000010,
200 | and HSHQDC-17-C-00019. The content of this specification does not
201 | necessarily reflect the position or the policy of the U.S. Government
202 | and no official endorsement should be inferred.
203 |
204 |
205 |
206 | Work on this repository has also been supported by the Rebooting the
207 | Web of Trust community facilitated by Christopher Allen, Shannon
208 | Appelcline, Kiara Robles, Brian Weller, Betty Dhamers, Kaliya Young,
209 | Kim Hamilton Duffy, Manu Sporny, Drummond Reed, Joe Andrieu, and
210 | Heather Vescent, Dmitri Zagidulin, and Dan Burnett.
211 |
212 |
213 |
214 |
226 |
227 |
228 | The Registration Process
229 |
230 | Software implementers might find that the existing Decentralized Identifier Core
231 | specification [[DID-CORE]] is not entirely capable of addressing their use case
232 | and might need to add a new parameters, properties, or values to this repository
233 | in order to achieve their use case in a globally interoperable fashion. In order
234 | to add a new parameter, property, or value to this repository, an implementer MUST
235 | submit a modification request for this repository, as a pull request on the
236 | repository where this repository is hosted, where the modification request adheres
237 | to the following policies:
238 |
239 |
240 |
241 | -
242 | Any addition to the DID Extensions MUST specify a human readable
243 | description of the addition.
244 |
245 | -
246 | Any name or value of a property or parameter MUST be indicative of
247 | its function. Avoid generic terms such as "myProperty" or "foo".
248 |
249 | -
250 | Any method name SHOULD avoid generic terms such as "mymethod" or "registry".
251 |
252 | -
253 | Any DID Method submission MUST not impose any concerns about copyright,
254 | trademark, or intellectual property rights on the W3C, DID Method
255 | implementers, or users. To that end, the following apply:
256 |
257 | -
258 | DID Method submitters affirm to the best of their knowledge that their
259 | submission will not infringe upon or otherwise violate the rights of any third
260 | party.
261 |
262 | -
263 | If there are any known concerns about copyright, trademark, or intellectual
264 | property rights, the addition and use of a DID Method MUST be authorized in
265 | writing by the holder of the intellectual property rights under an
266 | F/RAND
267 | license.
268 |
269 | -
270 | If a DID Method is subsequently alleged to violate any copyright, trademark,
271 | or intellectual property rights, those making the allegation MUST provide
272 | documentation of their granted legal rights or an order from a court or
273 | arbitral tribunal, in each case of competent jurisdiction.
274 |
275 | -
276 | Should documentation of legally valid and enforceable copyright, trademark,
277 | or intellectual property rights be presented, then, at the discretion of the
278 | rights holder, the DID Method in question MUST be removed.
279 |
280 |
281 |
282 | -
283 | Any addition MUST NOT create unreasonable legal, security, moral, or privacy
284 | issues that will result in direct harm to others. Examples of unacceptable
285 | additions include any containing racist language, technologies used to
286 | persecute minority populations, and unconsented pervasive tracking.
287 |
288 | -
289 | Any addition to the DID Extensions MUST link, via at least a URL,
290 | preferably a content-integrity protected one, to the defining specification so
291 | that implementers can implement the property.
292 |
293 | -
294 | Any addition to the DID Extensions that is a property or value, MUST
295 | specify a machine readable JSON-LD Context for the addition.
296 |
297 | -
298 | The JSON-LD Context MUST be included in full as part of the submission.
299 |
300 | -
301 | A namespace URI MUST be provided for the JSON-LD Context so that consumer
302 | implementations can consistently map a URI to the full context.
303 |
304 | -
305 | The URI provided MUST be persistent, and link all terms to their associated
306 | human readable descriptions.
307 |
308 | -
309 | The URI provided SHOULD resolve or link to the full context contents.
310 |
311 | -
312 | JSON-LD Contexts MUST be versioned and MUST NOT be date stamped.
313 |
314 | -
315 | JSON-LD Contexts SHOULD use scoped terms and MUST use the
@protected
316 | feature to eliminate the possibility of term conflicts.
317 |
318 |
319 |
320 | -
321 | Properties in the DID Extensions MUST NOT be removed, only deprecated.
322 |
323 |
324 |
325 |
326 | The Editors of the DID Specification Registries MUST consider all of the
327 | policies above when reviewing additions to the repository and MUST reject repository
328 | entries if they violate any of the policies in this section. Entities
329 | registering additions can challenge rejections first with the W3C DID Working
330 | Group and then, if they are not satisfied with the outcome, with the W3C Staff.
331 | W3C Staff need not be consulted on changes to the DID Specification Registries,
332 | but do have the final authority on repository contents. This is to ensure that W3C
333 | can adequately respond to time sensitive legal, privacy, security, moral, or
334 | other pressing concerns without putting an undue operational burden on W3C
335 | Staff.
336 |
337 |
338 |
339 | Entries that are identified to cause interoperability problems MAY be marked as
340 | such at the discretion of the maintainers of this repository, and if possible,
341 | after consultation with the entry maintainer.
342 |
343 |
344 |
345 | Any submission to the registries that meet all the criteria listed above will be
346 | accepted for inclusion. These registries enumerate all known mechanisms that
347 | meet a minimum bar, without choosing between them.
348 |
349 |
350 |
351 |
352 | Extensions
353 |
354 |
355 | The following documents list known extensions to the DID Ecosystem:
356 |
357 |
358 |
359 |
360 | | Document |
361 | Description |
362 |
363 |
364 |
365 | |
366 | Property and Value Extensions
367 | |
368 | Extensions to DID Document properties and values. |
369 |
370 |
371 | |
372 | Resolution Extensions
373 | |
374 | Extensions to DID Resolution parameters and results. |
375 |
376 |
377 | |
378 | DID Methods
379 | |
380 |
381 | Ephemeral, distributed, and fully decentralized mechanisms for supporting
382 | Decentralized Identifiers across a variety of technology platforms.
383 | |
384 |
385 |
386 |
387 |
388 |
389 |
390 |
391 |
392 |
--------------------------------------------------------------------------------