From 3de855a3f5df3d86b3111b4130016be7fb61572f Mon Sep 17 00:00:00 2001
From: Michael Jones Use Cases and Requirements
Web Signature of a JSON Web Token for proofing a key holder), are an essential
part of processing verifiable credentials and
verifiable presentations. At the time of publication, Working Group
-members had implemented such protection using at least three proof mechanisms:
+members had implemented such protection using at least two proof mechanisms:
below shows a more complete depiction of a -verifiable presentation, which is normally composed of at least four +verifiable presentation +secured with Data Integrity Proofs [[VC-DATA-INTEGRITY]]. +Verifiable presentations, secured in this manner are +normally composed of at least four information graphs. The first of these graphs, the verifiable presentation graph (which is the default graph), expresses the verifiable presentation itself, and contains presentation @@ -1175,7 +1180,7 @@
-This specification requires for a @context
property
+This specification requires a @context
property
to be present; this property is defined by [[JSON-LD]].
@@ -1194,8 +1199,7 @@@@ -1417,16 +1421,6 @@Contexts
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1", "name": "Example University" } - }, - "proof": { ... } + } }
"type": "DataIntegrityProof"
-
Methods of securing verifiable credentials or
-verifiable presentations that embed a proof in the data model MUST use
-the proof
property.
+verifiable presentations that embed a proof in the data model MAY use a
+the proof
property,
+when specified by the securing mechanism.
Methods of securing verifiable credentials or verifiable
-presentations that use an external proof MAY use the proof
+presentations that use an external proof MAY include a proof
property.
-One or more cryptographic proofs that can be used to detect tampering and verify
-the authorship of a verifiable credential or a verifiable
-presentation. Each proof is a separate named graph
-(referred to as a proof graph) containing a single
-proof. The specific method used for an embedded proof MUST be identified
-using the type
property.
-
A proof for a verifiable credential covers all claims included in the corresponding verifiable credential graph. See for the case when the property is used for a verifiable presentation.
-
-Because the method used for a mathematical proof varies by representation
-language and the technology used, the set of name-value pairs that is expected
-as the value of the proof
property will vary accordingly.
-For example, if digital signatures are used for the proof mechanism, the
-proof
property is expected to have name-value pairs that
-include a signature, a reference to the signing entity, and a representation of
-the signing date. The example below uses Ed25519 digital signatures.
-
-{
- "@context": [
- "https://www.w3.org/ns/credentials/v2",
- "https://www.w3.org/ns/credentials/examples/v2"
- ],
- "id": "http://example.gov/credentials/3732",
- "type": ["VerifiableCredential", "ExampleDegreeCredential"],
- "issuer": "https://university.example",
- "validFrom": "2010-01-01T19:23:24Z",
- "credentialSubject": {
- "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
- "degree": {
- "type": "ExampleBachelorDegree",
- "name": "Bachelor of Science and Arts"
- }
- },
- "proof": {
- "type": "Ed25519Signature2020",
- "created": "2021-11-13T18:19:39Z",
- "verificationMethod": "https://university.example/issuers/14#key-1",
- "proofPurpose": "assertionMethod",
- "proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndSayn1PzZs6ZjWp1CktyGesjuTSwRdo
- WhAfGFCF5bppETSTojQCrfFPP2oumHKtz"
- }
-}
-
As discussed in Section , there are multiple viable @@ -2308,26 +2253,18 @@
The verifiable presentation MAY include a proof
- property, which refers to a separate named graph containing a single proof.
- The specific method used for the MUST be
- identified using the type
property.
-
- The proof covers of all claims in the following graphs:
+ property
+ when its use is specified by the securing mechanism used.
verifiableCredential
property of the presentation, as well as their corresponding proof graphs.-The example below shows a verifiable presentation: +The example below shows a verifiable presentation +secured with Data Integrity Proofs [[VC-DATA-INTEGRITY]]:
-+{ "@context": [ "https://www.w3.org/ns/credentials/v2", @@ -2475,7 +2412,7 @@Presentations Including Holder Claims
mechanism as the verifiable presentation. -+{ "@context": [ "https://www.w3.org/ns/credentials/v2", @@ -2502,7 +2439,7 @@Presentations Including Holder Claims
verifiable presentation. -+{ "@context": [ "https://www.w3.org/ns/credentials/v2", @@ -2664,8 +2601,7 @@@@ -2843,7 +2779,8 @@Data Schemas
"credentialSchema": { "id": "https://example.org/examples/degree", "type": "ZkpExampleSchema2018" - }, - "proof": { ... } + } }Trust Model
it received. To establish this trust, a credential is expected to either:
The evidence
property provides different and complementary
-information to the proof
property. The evidence
+information to the securing mechanism utlized. The evidence
property is used to express supporting information, such as documentary
evidence, related to the integrity of the verifiable credential. In
-contrast, the proof
property is used to express
+contrast, the securing mechanism is used to express
machine-verifiable mathematical proofs related to the authenticity of the
issuer and integrity of the verifiable credential. For more
-information about the proof
property, see Section
+information about securing mechanisms, see Section
.
verifiableCredential
and proof
properties
-are defined as
-JSON-LD 1.1 graph containers.
-This means the creation of named graphs used to isolate sets of data
+The verifiableCredential
property
+is defined as
+a JSON-LD 1.1 graph container.
+This means the creation of named graphs can be used to isolate sets of data
asserted by different entities. This ensures, for example, proper cryptographic
separation between the data graph provided by each issuer
and the one provided by the holder presenting the verifiable
@@ -4648,7 +4582,7 @@
-The contents of verifiable credentials are secured using the
-credential.proof
field. The properties in this field
+The contents of verifiable credentials are secured using a securing method.
+Values used to represent the securing method
create a greater risk of correlation when the same values are used across more
-than one session or domain and the value does not change. Examples include the
-verificationMethod
, created
,
-proofPurpose
, and jws
fields.
+than one session or domain and the value does not change.
@@ -5893,8 +5819,7 @@
-This specification allows credentials to be produced that do not contain +This specification allows credentials to be produced that are not secured by signatures or proofs of any kind. These types of credentials are often useful for intermediate storage, or self-asserted information, which is analogous to filling out a form on a web page. Implementers should be aware that @@ -6554,11 +6478,6 @@
proofPurpose
property,
-it is expected to exist and be a valid value, such as
-assertionMethod
.
- @@ -6568,15 +6487,7 @@
verificationMethod
property specifies, for example, the
-public key that can be used to verify the digital signature. Dereferencing a
-public key URL reveals information about the controller of the key, which can
-be checked against the issuer of the credential. The
-proofPurpose
property clearly expresses the purpose for
-the proof and ensures this information is protected by the signature. A proof is
-typically attached to a verifiable presentation for authentication
-purposes and to a verifiable credential as a method of assertion.
+The JWT iat
claim likewise provides the time that the signature was made.
diff --git a/terms.html b/terms.html
index 052a962ab..d3775289d 100644
--- a/terms.html
+++ b/terms.html
@@ -116,7 +116,7 @@
-The `evidence` [=property=] provides different and complementary
+The `evidence` [=property=] provides information that is different from and
information to the securing mechanism utlized. The `evidence`
[=property=] is used to express supporting information, such as documentary
evidence, related to the integrity of the [=verifiable credential=]. In
From 1be081b10a53c787cdd1cc0297879f1f2133475f Mon Sep 17 00:00:00 2001
From: "Michael B. Jones"
The `evidence` [=property=] provides information that is different from and
-information to the securing mechanism utlized. The `evidence`
+information to the securing mechanism utilized. The `evidence`
[=property=] is used to express supporting information, such as documentary
evidence, related to the integrity of the [=verifiable credential=]. In
contrast, the `proof` [=property=] is used to express
From 57f8238f04b2f663f4b6aa4b4b7e4b7dbc6a2ced Mon Sep 17 00:00:00 2001
From: "Michael B. Jones"
-The contents of a [=credential=] are secured using a securing method.
+The contents of a [=credential=] are secured using a securing mechanism.
Values used to represent the securing method
create a greater risk of correlation when the same values are used across more
than one session or domain and the value does not change.
From f4148b3d0679dfb5cf699a859fec91ee51d8047d Mon Sep 17 00:00:00 2001
From: "Michael B. Jones"
An embedded proof is a mechanism where the proof is
-included in the serialization of the data model. One such embedded
+included in the serialization of the data model. One such RECOMMENDED embedded
proof mechanism is defined in [[[VC-DATA-INTEGRITY]]] [[VC-DATA-INTEGRITY]].
Evidence
Evidence
information to the securing mechanism utilized. The `evidence`
[=property=] is used to express supporting information, such as documentary
evidence, related to the integrity of the [=verifiable credential=]. In
-contrast, the `proof` [=property=] is used to express
+contrast, the securing mechanism is used to express
machine-verifiable mathematical proofs related to the authenticity of the
[=issuer=] and integrity of the [=verifiable credential=]. For more
information about securing mechanisms, see Section
From 349c53f8ab9c3a3d97df7ddb70474650239bd1b7 Mon Sep 17 00:00:00 2001
From: "Michael B. Jones" Syntactic Sugar
The `verifiableCredential` [=property=]
is defined as a
JSON-LD 1.1 graph
-container. This means the creation of [=named graphs=] used to isolate
+container. This requires the creation of [=named graphs=], used to isolate
sets of data asserted by different entities. This ensures, for example, proper
cryptographic separation between the data graph provided by each [=issuer=]
and the one provided by the [=holder=] presenting the verifiable
From b5f633d51551a64981248f8f58b6a2e5319a7812 Mon Sep 17 00:00:00 2001
From: "Michael B. Jones" Identifier-Based Correlation
Signature-Based Correlation
Proofs (Signatures)
The cryptographic signature is expected to verify.
Proofs (Signatures)
distinct from the validity period of the credential. This property describes the
validity of the proof, not of the credential.
The JWT iat
claim likewise provides the time that the signature was made.
+
+The `verificationMethod` [=property=] specifies, for example, the
+public key that can be used to verify the digital signature. Dereferencing a
+public key URL reveals information about the controller of the key, which can
+be checked against the issuer of the [=credential=]. The
+`proofPurpose` [=property=] clearly expresses the purpose for
+the proof and ensures this information is protected by the signature. A proof is
+typically attached to a [=verifiable presentation=] for authentication
+purposes and to a [=verifiable credential=] as a method of assertion.
Securing Mechanisms
Evidence
machine-verifiable mathematical proofs related to the authenticity of the
[=issuer=] and integrity of the [=verifiable credential=]. For more
information about securing mechanisms, see Section
-.
+.
Presentations
The example below shows a [=verifiable presentation=]:
+{ "@context": [ "https://www.w3.org/ns/credentials/v2", From 1dc53197cf96dc30551378ffacc0d474ad8ea5ab Mon Sep 17 00:00:00 2001 From: "Michael B. Jones"Date: Fri, 12 Jan 2024 13:11:22 -0800 Subject: [PATCH 12/14] Applied Manu's suggestion Co-authored-by: Manu Sporny --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 6e1ae1221..82e5352b7 100644 --- a/index.html +++ b/index.html @@ -4984,7 +4984,7 @@ Signature-Based Correlation
The contents of a [=credential=] are secured using a securing mechanism. -Values used to represent the securing method +Values used to represent the securing mechanism create a greater risk of correlation when the same values are used across more than one session or domain and the value does not change.
From c52fd5304c70241f9ddc4f26b8b44630b85753e9 Mon Sep 17 00:00:00 2001 From: "Michael B. Jones"Date: Fri, 12 Jan 2024 13:14:41 -0800 Subject: [PATCH 13/14] Applied Manu's suggestion to delete controller DT --- index.html | 1 - 1 file changed, 1 deletion(-) diff --git a/index.html b/index.html index 82e5352b7..64645750a 100644 --- a/index.html +++ b/index.html @@ -4044,7 +4044,6 @@ Securing Mechanism Specifications
A media type as defined in [[RFC6838]]. -[=string=] |controller| Date: Fri, 12 Jan 2024 13:15:55 -0800 Subject: [PATCH 14/14] Applied Manu's suggestion Co-authored-by: Manu Sporny
--- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 64645750a..aef86b14f 100644 --- a/index.html +++ b/index.html @@ -2834,7 +2834,7 @@ Trust Model
it received. To establish this trust, a [=credential=] is expected to either:
- -Secure the [=credential=] with a proof establishing that the +Secure the [=credential=] with a securing mechanism establishing that the [=issuer=] generated the [=credential=] (that is, it is a [=verifiable credential=]), or