From a8018cd9411c21bdc6af4d750ac54285e5adc096 Mon Sep 17 00:00:00 2001 From: Bruno Hivert Date: Fri, 24 Jan 2025 15:11:37 -0500 Subject: [PATCH] fix(wcd_host_to_user): typo + spec chapter references --- docs/w3c_vcdm/vcdm_how_to_use.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/w3c_vcdm/vcdm_how_to_use.md b/docs/w3c_vcdm/vcdm_how_to_use.md index 7f44f94..2b7b9bb 100644 --- a/docs/w3c_vcdm/vcdm_how_to_use.md +++ b/docs/w3c_vcdm/vcdm_how_to_use.md @@ -22,16 +22,16 @@ DTT relies on the context provided in a Verifiable Credential payload to determi ## Using the optional validation options {#using_the_options} -**Background:** There are a number of properties defined in the W3C Veriable Credential Data Model specification that are not defined as required in order to support a wide variety of use cases and levels of assurance requirements. For example, the date defining when a credential becomes valid is optional. While this might enable the bulk creation of temporary/preliminary VC that don't yet have a validy period defined at that time, for a number of ecosystems this is a key required fields. +**Background:** There are a number of properties defined in the W3C Verifiable Credential Data Model specification that are not defined as required in order to support a wide variety of use cases and levels of assurance requirements. For example, the date defining when a credential becomes valid is optional. While this might enable the bulk creation of temporary/preliminary VC that don't yet have a validy period defined at that time, for a number of ecosystems this is a key required fields. **Selecting your options:** By default, DTT will treat these properties as if they were required, which will impact the conformance test results. If you want a property to be validated as optional, as per the specification, simply change 'true' to 'false' before clicking on **Validate JSON**. | Option name | Data model reference | Explanation | | ----------- | -------------------- | ----------- | -| `require_proof` | VCDM 2.0 [4.12](https://www.w3.org/TR/vc-data-model-2.0/#securing-mechanisms)| The specication recognizes two classes of securing mechanismes, including *enveloping proofs*, making this *embedded proof* property optional | -| `require_expiration_date` | VCDM 1.1 [4.8](https://www.w3.org/TR/vc-data-model/#expiration) | Note that this has been replaced by the `valid_until` property in v2.0 | -| `require_credential_status` | VCDM 2.0 [4.10](https://www.w3.org/TR/vc-data-model-2.0/#status) | The `credentialStatus` property can define one ore more status associated with the credential, including a *revocation* status, but it is optional. | -| `require_holder` | VCDM 2.0 [4.13](https://www.w3.org/TR/vc-data-model-2.0/#verifiable-presentations) | A *verifiable presentation* can define a `holder`, which can be a key part of the validation process for a *Verifier*, but is an optional property. | -| `require_valid_from` and `require_valid_until` | VCDM 2.0 [4.9](https://www.w3.org/TR/vc-data-model-2.0/#validity-period) | If a validity period is not defined, the VC is assumed to be valid indefinitely from the time it was created. | -| `require_dereferencing` | VCDM 2.0 [4.2](https://www.w3.org/TR/vc-data-model/#identifiers) | It is recommended that the URI used for identifiers be one that can be dereferenced into a document containing machine-readable information about the *id*. When set to `true`, this will for example attempt to resolve the **DID** used to define the *Issuer* of a VC. Note that a bit of extra time is required to perform this additional validation. | +| `require_proof` | [VCDM 2.0 ch. 4.12](https://www.w3.org/TR/vc-data-model-2.0/#securing-mechanisms)| The specification recognizes two classes of securing mechanismes, including *enveloping proofs*, making this *embedded proof* property optional | +| `require_expiration_date` | [VCDM 1.1 ch. 4.8](https://www.w3.org/TR/vc-data-model/#expiration) | Note that this has been replaced by the `valid_until` property in v2.0 | +| `require_credential_status` | [VCDM 2.0 ch. 4.10](https://www.w3.org/TR/vc-data-model-2.0/#status) | The `credentialStatus` property can define one ore more status associated with the credential, including a *revocation* status, but it is optional. | +| `require_holder` | [VCDM 2.0 ch. 4.13](https://www.w3.org/TR/vc-data-model-2.0/#verifiable-presentations) | A *verifiable presentation* can define a `holder`, which can be a key part of the validation process for a *Verifier*, but is an optional property. | +| `require_valid_from` and `require_valid_until` | [VCDM 2.0 ch. 4.9](https://www.w3.org/TR/vc-data-model-2.0/#validity-period) | If a validity period is not defined, the VC is assumed to be valid indefinitely from the time it was created. | +| `require_dereferencing` | [VCDM 2.0 ch. 4.2](https://www.w3.org/TR/vc-data-model/#identifiers) | It is recommended that the URI used for identifiers be one that can be dereferenced into a document containing machine-readable information about the *id*. When set to `true`, this will for example attempt to resolve the **DID** used to define the *Issuer* of a VC. Note that a bit of extra time is required to perform this additional validation. |