226
226
restrictRefs ,
227
227
window . respecVc . createVcExamples
228
228
] ,
229
- xref : [ "INFRA" , "MIMESNIFF" , "VC-DATA-MODEL-2.0" , "CONTROLLER-DOCUMENT " ] ,
229
+ xref : [ "INFRA" , "MIMESNIFF" , "VC-DATA-MODEL-2.0" , "CID-1.0 " ] ,
230
230
otherLinks : [ {
231
231
key : "Related Specifications" ,
232
232
data : [ {
@@ -618,11 +618,11 @@ <h3>Terminology</h3>
618
618
[[[#cryptographic-suites]]] for further detail.
619
619
</ dd >
620
620
621
- < dt > < dfn > controller document</ dfn > </ dt >
621
+ < dt > < dfn > controlled identifier document</ dfn > </ dt >
622
622
623
623
< dd >
624
624
A document that contains public cryptographic material as defined in the
625
- [[[CONTROLLER-DOCUMENT ]]] specification.
625
+ [[[CID-1.0 ]]] specification.
626
626
</ dd >
627
627
628
628
< dt > < dfn data-lt ="verifier|verifiers|verifier's "> verifier</ dfn > </ dt >
@@ -657,7 +657,7 @@ <h3>Terminology</h3>
657
657
< p >
658
658
An expression of the relationship between the [=subject=] and a
659
659
[=verification method=]. An example of a verification relationship is
660
- < a data-cite ="CONTROLLER-DOCUMENT #authentication "> authentication</ a > .
660
+ < a data-cite ="CID-1.0 #authentication "> authentication</ a > .
661
661
</ p >
662
662
</ dd >
663
663
@@ -763,7 +763,7 @@ <h3>Proofs</h3>
763
763
expressed in a [=data integrity proof=], the value points to the actual location
764
764
of the data; that is, the `verificationMethod` references, via a URL, the
765
765
location of the [=public key=] that can be used to verify the proof. This
766
- [=public key=] data is stored in a [=controller document=], which contains a
766
+ [=public key=] data is stored in a [=controlled identifier document=], which contains a
767
767
full description of the verification method.
768
768
</ dd >
769
769
@@ -823,8 +823,8 @@ <h3>Proofs</h3>
823
823
A [=string=] value that expresses base-encoded binary data necessary to verify the
824
824
digital proof using the `verificationMethod` specified. The value MUST use a
825
825
header and encoding as described in Section
826
- < a data-cite ="CONTROLLER-DOCUMENT #multibase-0 "> 2.4 Multibase</ a > of the
827
- [[[CONTROLLER-DOCUMENT ]]] specification to express the binary data.
826
+ < a data-cite ="CID-1.0 #multibase-0 "> 2.4 Multibase</ a > of the
827
+ [[[CID-1.0 ]]] specification to express the binary data.
828
828
The contents of this value are determined by a specific cryptosuite and set
829
829
to the < em > proof value</ em > generated by the < a href ="#add-proof "> Add Proof Algorithm</ a >
830
830
for that cryptosuite. Alternative properties with different encodings specified by the
@@ -1157,8 +1157,8 @@ <h2>Resource Integrity</h2>
1157
1157
property named < dfn class ="lint-ignore "> `digestMultibase`</ dfn > in any object
1158
1158
that includes an `id` property. If present, the `digestMultibase` value MUST be
1159
1159
a single [=string=] value, or an [=list=] of [=string=] values, each of which is a
1160
- < a data-cite ="CONTROLLER-DOCUMENT #multibase "> Multibase</ a > -encoded
1161
- < a data-cite ="CONTROLLER-DOCUMENT #multihash "> Multihash</ a > value.
1160
+ < a data-cite ="CID-1.0 #multibase "> Multibase</ a > -encoded
1161
+ < a data-cite ="CID-1.0 #multihash "> Multihash</ a > value.
1162
1162
</ p >
1163
1163
< p >
1164
1164
JSON-LD context authors are expected to add `digestMultibase` to contexts that
@@ -1259,7 +1259,7 @@ <h2>Contexts and Vocabularies</h2>
1259
1259
< p class ="note ">
1260
1260
Beyond the security terms defined by this specification, the
1261
1261
< a href ="https://w3id.org/security "> https://w3id.org/security#</ a > namespace
1262
- also includes the terms defined in the [[[CONTROLLER-DOCUMENT ]]] [[CONTROLLER-DOCUMENT ]]
1262
+ also includes the terms defined in the [[[CID-1.0 ]]] [[CID-1.0 ]]
1263
1263
specification, with the corresponding mappings in the context files listed above.
1264
1264
</ p >
1265
1265
@@ -1641,11 +1641,11 @@ <h2>Relationship to Verifiable Credentials</h2>
1641
1641
< p >
1642
1642
Finally, implementers are also urged to understand that there is a difference
1643
1643
between the revocation information associated with a [=verifiable credential=],
1644
- and the < a data-cite ="CONTROLLER-DOCUMENT #dfn-revoked "> revocation</ a >
1645
- and < a data-cite ="CONTROLLER-DOCUMENT #defn-vm-expires "> expiration</ a > times
1644
+ and the < a data-cite ="CID-1.0 #dfn-revoked "> revocation</ a >
1645
+ and < a data-cite ="CID-1.0 #defn-vm-expires "> expiration</ a > times
1646
1646
for a [=verification method=]. The
1647
- < a data-cite ="CONTROLLER-DOCUMENT #dfn-revoked "> revocation</ a > and
1648
- < a data-cite ="CONTROLLER-DOCUMENT #defn-vm-expires "> expiration</ a > times for a
1647
+ < a data-cite ="CID-1.0 #dfn-revoked "> revocation</ a > and
1648
+ < a data-cite ="CID-1.0 #defn-vm-expires "> expiration</ a > times for a
1649
1649
[=verification method=] are expressed using the `revocation` and `expires`
1650
1650
properties, respectively; are related to events such as a [=secret key=] being
1651
1651
compromised or expiring; and can provide timing information which might reveal
@@ -2874,10 +2874,10 @@ <h3>Verification Method Binding</h3>
2874
2874
< p >
2875
2875
Implementers ensure that a [=verification method=] is bound to a particular
2876
2876
controller by going from the definition of the [=verification method=] to the
2877
- [=controller document=], and then ensuring that the [=controller document=] also
2877
+ [=controlled identifier document=], and then ensuring that the [=controlled identifier document=] also
2878
2878
contains a reference to the [=verification method=]. This process is described
2879
2879
in the algorithm for
2880
- < a data-cite ="?CONTROLLER-DOCUMENT #retrieve-verification-method ">
2880
+ < a data-cite ="?CID-1.0 #retrieve-verification-method ">
2881
2881
retrieving a verification method</ a > .
2882
2882
</ p >
2883
2883
</ section >
@@ -2888,15 +2888,15 @@ <h3>Verification Relationship Validation</h3>
2888
2888
< p >
2889
2889
When an implementation is < a href ="#verify-proof "> verifying a proof</ a > , it is
2890
2890
imperative that it verify not only that the [=verification method=] used to
2891
- generate the proof is listed in the [=controller document=], but also that it
2891
+ generate the proof is listed in the [=controlled identifier document=], but also that it
2892
2892
was intended to be used to generate the proof that is being verified. This process
2893
2893
is known as "verification relationship validation".
2894
2894
</ p >
2895
2895
< p >
2896
2896
The process of validating a verification relationship is outlined in
2897
2897
Section
2898
- < a data-cite ="CONTROLLER-DOCUMENT #retrieve-verification-method ">
2899
- 3.3 Retrieve Verification Method</ a > of the [[[CONTROLLER-DOCUMENT ]]]
2898
+ < a data-cite ="CID-1.0 #retrieve-verification-method ">
2899
+ 3.3 Retrieve Verification Method</ a > of the [[[CID-1.0 ]]]
2900
2900
specification.
2901
2901
</ p >
2902
2902
< p >
@@ -3507,7 +3507,7 @@ <h2>Revision History</h2>
3507
3507
Various editorial changes in algorithms and descriptions to improve readability.
3508
3508
</ li >
3509
3509
< li >
3510
- Moved Multikey definitions to Controller Document .
3510
+ Moved Multikey definitions to controlled identifier document .
3511
3511
</ li >
3512
3512
< li >
3513
3513
Unify error handling between all Data Integrity cryptosuites.
0 commit comments