W3C Spec Scrapper

spec_srapper_output.json

{
  "vc-data-model-2.0": {
    "introduction": [],
    "conformance": [
      "A conforming processor is any algorithm realized as software and/or hardware that generates and/or consumes a conforming secured document according to the relevant normative statements in Section 4. Algorithms. Conforming processors MUST produce errors when non-conforming documents are consumed."
    ],
    "basic-concepts": [
      "The type property MUST be present. It is used to express the type of verifiable presentation. One value of this property MUST be VerifiablePresentation, but additional types MAY be included. The related normative guidance in Section 4.5 Types MUST be followed."
    ],
    "contexts": [],
    "identifiers": [],
    "types": [
      "When processing encapsulated objects defined in this specification, such as objects associated with the credentialSubject object or deeply nested therein, software systems SHOULD use the type information specified in encapsulating objects higher in the hierarchy. Specifically, an encapsulating object, such as a credential, SHOULD convey the associated object types so that verifiers can quickly determine the contents of an associated object based on the encapsulating object type."
    ],
    "names-and-descriptions": [],
    "issuer": [],
    "credential-subject": [],
    "validity-period": [],
    "status": [],
    "data-schemas": [],
    "securing-mechanisms": [],
    "verifiable-presentations": [
      "The verifiableCredential property MAY be present. The value MUST be one or more verifiable credential and/or enveloped verifiable credential objects (the values MUST NOT be non-object values such as numbers, strings, or URLs). These objects are called verifiable credential graphs and MUST express information that is secured using a securing mechanism. See Section 5.12 Verifiable Credential Graphs for further details.",
      "A verifiable presentation that includes a self-asserted verifiable credential, which is secured only using the same mechanism as the verifiable presentation, MUST include a holder property."
    ],
    "advanced-concepts": [
      "A conforming document SHOULD NOT use the @vocab feature in production as it can lead to JSON term clashes, resulting in semantic ambiguities with other applications. Instead, to achieve proper interoperability, a conforming document SHOULD use JSON-LD Contexts that define all terms used by their applications, as described earlier in Section 5.2 Extensibility. If a conforming document does not use JSON-LD Contexts that define all terms used, it MUST include the https://www.w3.org/ns/credentials/undefined-terms/v2 as the last value in the @context property.",
      "Specification authors that write algorithms that fetch a resource based on the id of an object inside a conforming document need to consider whether that resource's content is vital to the validity of that document. If it is, the specification MUST produce a validation error unless the resource matches the expected media type and cryptographic digest.",
      "A property used for specifying one or more methods to render a credential into a visual, auditory, haptic, or other format. The associated vocabulary URL MUST be https://www.w3.org/2018/credentials#renderMethod.",
      "Securing mechanism specifications SHOULD provide integrity protection for any information referenced by a URL that is critical to validation. Mechanisms that can achieve this protection are discussed in Section 5.3 Integrity of Related Resources and Section B.1 Base Context."
    ],
    "extensibility": [
      "It is RECOMMENDED to also publish the collection of all new terms as a machine-readable vocabulary using RDF Schema 1.1."
    ],
    "integrity-of-related-resources": [
      "If a mediaType is listed, implementations that retrieve the resource identified by the id property using HTTP Semantics SHOULD:"
    ],
    "refreshing": [],
    "terms-of-use": [],
    "evidence": [],
    "zero-knowledge-proofs": [],
    "representing-time": [],
    "reserved-extension-points": [
      "An unofficial list of specifications that are associated with the extension points defined in this specification, as well as the reserved extension points defined in this section, can be found in the Verifiable Credential Extensions. Items in the directory that refer to reserved extension points SHOULD be treated as experimental."
    ],
    "ecosystem-compatibility": [
      "SHOULD provide a test suite that demonstrates that the specified transformation algorithm to the data model in this specification results in a conforming document."
    ],
    "securing-mechanism-specifications": [
      "The securing mechanism MUST define all terms used by the proof graph. For example, the mechanism could define vocabulary specifications and @context files in the same manner as they are utilized by this specification."
    ],
    "syntaxes": [],
    "json-ld": [],
    "media-types": [],
    "algorithms": [
      "Implementers MAY implement reasonable defaults and safeguards in addition to the algorithms below, to help mitigate developer error, excessive resource consumption, newly discovered attack models against which there is a particular protection, etc. The algorithms provided below are the minimum requirements for an interoperable implementation, and developers are urged to include additional measures that could contribute to a safer and more efficient ecosystem.",
      "If options has a non-null domain item, it MUST be equal to proof.domain or an error MUST be raised and SHOULD convey an error type of PROOF_GENERATION_ERROR.",
      "If options has a previousProof item that is an array, add each element from allProofs with an id attribute that matches an element of that array. If any element of previousProof array has an id attribute that does not match the id attribute of any element of allProofs, an error MUST be raised and SHOULD convey an error type of PROOF_GENERATION_ERROR.",
      "If one or more of proof.type, proof.verificationMethod, and proof.proofPurpose does not exist, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR.",
      "The title value SHOULD provide a short but specific human-readable string for the error."
    ],
    "verification": [],
    "problem-details": [
      "The value associated with a particular property is malformed. The name of the property and the path to the property SHOULD be provided in the ProblemDetails object. See Section 7.1 Verification."
    ],
    "internationalization-considerations": [],
    "language-and-base-direction": [],
    "providing-default-language-and-direction": [],
    "contexts-vocabularies-types-and-credential-schemas": [],
    "base-context": [],
    "vocabularies": [],
    "data-model": [
      "The reason the proof was created MUST be specified as a string that maps to a URL [URL]. The proof purpose acts as a safeguard to prevent the proof from being misused by being applied to a purpose other than the one that was intended. For example, without this value the creator of a proof could be tricked into using cryptographic material typically used to create a Verifiable Credential (assertionMethod) during a login process (authentication) which would then result in the creation of a Verifiable Credential they never meant to create instead of the intended action, which was to merely logging into a website.",
      "The expires property is OPTIONAL and, if present, specifies when the proof expires. If present, it MUST be an [XMLSCHEMA11-2] dateTimeStamp string, either in Universal Coordinated Time (UTC), denoted by a Z at the end of the value, or with a time zone offset relative to UTC. A conforming processor MAY chose to consume time values that were incorrectly serialized without an offset. Incorrectly serialized time values without an offset are to be interpreted as UTC.",
      "An OPTIONAL string value or unordered list of string values. Each value identifies another data integrity proof that MUST verify before the current proof is processed. If an unordered list, all referenced proofs in the array MUST verify. This property is used in Section 2.1.2 Proof Chains.",
      "Implementations MAY load application-specific JSON-LD context files from the network during development, but SHOULD permanently cache JSON-LD context files used by conforming secured documents in production settings, to increase their security and privacy characteristics. Goals of processing speed MAY be achieved through caching approaches such as those described above or functionally equivalent mechanisms."
    ],
    "proofs": [
      "An optional identifier for the proof, which MUST be a URL [URL], such as a UUID as a URN (urn:uuid:6a1676b8-b51f-11ed-937b-d76685a20ff5). The usage of this property is further explained in Section 2.1.2 Proof Chains.",
      "A verification method is the means and information needed to verify the proof. If included, the value MUST be a string that maps to a [URL]. Inclusion of verificationMethod is OPTIONAL, but if it is not included, other properties such as cryptosuite might provide a mechanism by which to obtain the information necessary to verify the proof. Note that when verificationMethod is expressed in a data integrity proof, the value points to the actual location of the data; that is, the verificationMethod references, via a URL, the location of the public key that can be used to verify the proof. This public key data is stored in a controller document, which contains a full description of the verification method.",
      "The date and time the proof was created is OPTIONAL and, if included, MUST be specified as an [XMLSCHEMA11-2] dateTimeStamp string, either in Universal Coordinated Time (UTC), denoted by a Z at the end of the value, or with a time zone offset relative to UTC. A conforming processor MAY chose to consume time values that were incorrectly serialized without an offset. Incorrectly serialized time values without an offset are to be interpreted as UTC.",
      "A string value that SHOULD be included in a proof if a domain is specified. The value is used once for a particular domain and window of time. This value is used to mitigate replay attacks. Examples of a challenge value include: 1235abcd6789, 79d34551-ae81-44ae-823b-6dadbab9ebd4, and ruby.",
      "An OPTIONAL string value supplied by the proof creator. One use of this field is to increase privacy by decreasing linkability that is the result of deterministically generated signatures."
    ],
    "resource-integrity": [],
    "contexts-and-vocabularies": [
      "Implementations that perform RDF processing MUST treat the JSON-LD serialization of the vocabulary URL as already dereferenced, where the dereferenced document matches the corresponding hash value below."
    ],
    "validating-contexts": [
      "While the algorithm described in Section 4.6 Context Validation provides one way of checking context values, and one optional way of safely processing unknown context values, implementers MAY use alternative approaches, or a different ordering of the steps, that provide the same protections."
    ],
    "context-injection": [],
    "securing-data-losslessly": [
      "Similarly, since conforming secured documents can be transferred from one security domain to another, conforming processors that process the conforming secured document cannot assume any particular base URL for the document. When deserializing to RDF, implementations MUST ensure that the base URL is set to null."
    ],
    "cryptographic-suites": [
      "The specification MUST identify a cryptographic suite type and any parameters that can be used with the suite.",
      "The specification MUST detail the hashing algorithms parameters, and other necessary details used to perform cryptographic hashing to the data to be protected.",
      "The specification MUST detail the proof verification algorithms, parameters, and other necessary details used to perform cryptographic verification of the data.",
      "An algorithm that takes a secured data document (map securedDocument) as input, and produces a cryptosuite verification result or an error. The cryptosuite verification result is a struct that contains the following items: verified A boolean that is true if the verification succeeded, or false otherwise. verifiedDocument A map that represents the secured data document with the verified proofs removed if verified is true, or null otherwise. The structure MAY contain other implementation-specific information that is useful for developers, such as debugging information. If an error is produced, the verification process failed to complete. An error, such as a network error, does not mean that a future attempt at verification would fail.",
      "The specification MUST contain a Security Considerations section detailing security considerations specific to the cryptographic suite.",
      "The JSON-LD context associated with the cryptographic suite MUST have its terms protected from unsafe redefinition, by use of the @protected keyword.",
      "The specification MUST provide a link to an interoperability test report to document which implementations are conformant with the cryptographic suite specification.",
      "Cryptographic suite designers MUST use mandatory proof value properties defined in Section 2.1 Proofs, and MAY define other properties specific to their cryptographic suite."
    ],
    "dataintegrityproof": [
      "The value of the cryptosuite property MUST be a string that identifies the cryptographic suite. If the processing environment supports subtypes of string, the type of the cryptosuite value MUST be the https://w3id.org/security#cryptosuiteString subtype of string.",
      "One of the design patterns seen in Data Integrity cryptosuites from 2012 to 2020 was use of the type property to establish a specific type for a cryptographic suite; the Ed25519Signature2020 cryptographic suite was one such specification. This led to a greater burden on cryptographic suite implementations, where every new cryptographic suite required specification of a new JSON-LD Context, resulting in a sub-optimal developer experience. A streamlined version of this design pattern emerged in 2020, such that a developer would only need to include a single JSON-LD Context to support all modern cryptographic suites. This encouraged more modern cryptosuites \u2014 such as the EdDSA Cryptosuites [DI-EDDSA] and the ECDSA Cryptosuites [DI-ECDSA] \u2014 to be built based on the streamlined pattern described in this section. To improve the developer experience, authors creating new Data Integrity cryptographic suite specifications SHOULD use the modern pattern \u2014 where the type is set to DataIntegrityProof; the cryptosuite property carries the identifier for the cryptosuite; and any cryptosuite-specific cryptographic data is encapsulated (i.e., not directly exposed as application layer data) within proofValue. A list of cryptographic suite specifications that are known to follow this pattern is provided in the Proof types section of the Verifiable Credentials Specifications Directory."
    ],
    "add-proof": [
      "Let proof be the result of calling the createProof algorithm specified in cryptosuite.createProof with inputDocument and options passed as a parameters. If the algorithm produces an error, the error MUST be propagated and SHOULD convey the error type.",
      "If options has a non-null challenge item, it MUST be equal to proof.challenge or an error MUST be raised and SHOULD convey an error type of PROOF_GENERATION_ERROR."
    ],
    "add-proof-set-chain": [
      "If options has a previousProof item that is a string, add the element from allProofs with an id attribute matching previousProof to matchingProofs. If a proof with id equal to previousProof does not exist in allProofs, an error MUST be raised and SHOULD convey an error type of PROOF_GENERATION_ERROR."
    ],
    "verify-proof": [
      "When a step says \"an error MUST be raised\", it means that a verification result MUST be returned with a verified of false and a non-empty errors list.",
      "If expectedProofPurpose was given, and it does not match proof.proofPurpose, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR.",
      "If challenge was given, and it does not match proof.challenge, an error MUST be raised and SHOULD convey an error type of INVALID_CHALLENGE_ERROR."
    ],
    "verify-proof-sets-and-chains": [
      "If proof contains a previousProof attribute and that attribute is a string, add the element from allProofs with an id attribute matching previousProof to matchingProofs. If a proof with id does not exist in allProofs, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR. If the previousProof attribute is an array, add each element from allProofs with an id attribute that matches an element of that array. If any element of previousProof array has an id attribute that does not match the id attribute of any element of allProofs, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR."
    ],
    "context-validation": [],
    "processing-errors": [
      "The type value of the error object MUST be a URL that starts with the value https://w3id.org/security# and ends with the value in the section listed below.",
      "The detail value SHOULD provide a longer human-readable string for the error."
    ]
  },
  "vc-data-integrity": {
    "introduction": [],
    "conformance": [
      "A conforming processor is any algorithm realized as software and/or hardware that generates and/or consumes a conforming secured document according to the relevant normative statements in Section 4. Algorithms. Conforming processors MUST produce errors when non-conforming documents are consumed."
    ],
    "basic-concepts": [
      "The type property MUST be present. It is used to express the type of verifiable presentation. One value of this property MUST be VerifiablePresentation, but additional types MAY be included. The related normative guidance in Section 4.5 Types MUST be followed."
    ],
    "contexts": [],
    "identifiers": [],
    "types": [
      "When processing encapsulated objects defined in this specification, such as objects associated with the credentialSubject object or deeply nested therein, software systems SHOULD use the type information specified in encapsulating objects higher in the hierarchy. Specifically, an encapsulating object, such as a credential, SHOULD convey the associated object types so that verifiers can quickly determine the contents of an associated object based on the encapsulating object type."
    ],
    "names-and-descriptions": [],
    "issuer": [],
    "credential-subject": [],
    "validity-period": [],
    "status": [],
    "data-schemas": [],
    "securing-mechanisms": [],
    "verifiable-presentations": [
      "The verifiableCredential property MAY be present. The value MUST be one or more verifiable credential and/or enveloped verifiable credential objects (the values MUST NOT be non-object values such as numbers, strings, or URLs). These objects are called verifiable credential graphs and MUST express information that is secured using a securing mechanism. See Section 5.12 Verifiable Credential Graphs for further details.",
      "A verifiable presentation that includes a self-asserted verifiable credential, which is secured only using the same mechanism as the verifiable presentation, MUST include a holder property."
    ],
    "advanced-concepts": [
      "A conforming document SHOULD NOT use the @vocab feature in production as it can lead to JSON term clashes, resulting in semantic ambiguities with other applications. Instead, to achieve proper interoperability, a conforming document SHOULD use JSON-LD Contexts that define all terms used by their applications, as described earlier in Section 5.2 Extensibility. If a conforming document does not use JSON-LD Contexts that define all terms used, it MUST include the https://www.w3.org/ns/credentials/undefined-terms/v2 as the last value in the @context property.",
      "Specification authors that write algorithms that fetch a resource based on the id of an object inside a conforming document need to consider whether that resource's content is vital to the validity of that document. If it is, the specification MUST produce a validation error unless the resource matches the expected media type and cryptographic digest.",
      "A property used for specifying one or more methods to render a credential into a visual, auditory, haptic, or other format. The associated vocabulary URL MUST be https://www.w3.org/2018/credentials#renderMethod.",
      "Securing mechanism specifications SHOULD provide integrity protection for any information referenced by a URL that is critical to validation. Mechanisms that can achieve this protection are discussed in Section 5.3 Integrity of Related Resources and Section B.1 Base Context."
    ],
    "extensibility": [
      "It is RECOMMENDED to also publish the collection of all new terms as a machine-readable vocabulary using RDF Schema 1.1."
    ],
    "integrity-of-related-resources": [
      "If a mediaType is listed, implementations that retrieve the resource identified by the id property using HTTP Semantics SHOULD:"
    ],
    "refreshing": [],
    "terms-of-use": [],
    "evidence": [],
    "zero-knowledge-proofs": [],
    "representing-time": [],
    "reserved-extension-points": [
      "An unofficial list of specifications that are associated with the extension points defined in this specification, as well as the reserved extension points defined in this section, can be found in the Verifiable Credential Extensions. Items in the directory that refer to reserved extension points SHOULD be treated as experimental."
    ],
    "ecosystem-compatibility": [
      "SHOULD provide a test suite that demonstrates that the specified transformation algorithm to the data model in this specification results in a conforming document."
    ],
    "securing-mechanism-specifications": [
      "The securing mechanism MUST define all terms used by the proof graph. For example, the mechanism could define vocabulary specifications and @context files in the same manner as they are utilized by this specification."
    ],
    "syntaxes": [],
    "json-ld": [],
    "media-types": [],
    "algorithms": [
      "Implementers MAY implement reasonable defaults and safeguards in addition to the algorithms below, to help mitigate developer error, excessive resource consumption, newly discovered attack models against which there is a particular protection, etc. The algorithms provided below are the minimum requirements for an interoperable implementation, and developers are urged to include additional measures that could contribute to a safer and more efficient ecosystem.",
      "If options has a non-null domain item, it MUST be equal to proof.domain or an error MUST be raised and SHOULD convey an error type of PROOF_GENERATION_ERROR.",
      "If options has a previousProof item that is an array, add each element from allProofs with an id attribute that matches an element of that array. If any element of previousProof array has an id attribute that does not match the id attribute of any element of allProofs, an error MUST be raised and SHOULD convey an error type of PROOF_GENERATION_ERROR.",
      "If one or more of proof.type, proof.verificationMethod, and proof.proofPurpose does not exist, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR.",
      "The title value SHOULD provide a short but specific human-readable string for the error."
    ],
    "verification": [],
    "problem-details": [
      "The value associated with a particular property is malformed. The name of the property and the path to the property SHOULD be provided in the ProblemDetails object. See Section 7.1 Verification."
    ],
    "internationalization-considerations": [],
    "language-and-base-direction": [],
    "providing-default-language-and-direction": [],
    "contexts-vocabularies-types-and-credential-schemas": [],
    "base-context": [],
    "vocabularies": [],
    "data-model": [
      "The reason the proof was created MUST be specified as a string that maps to a URL [URL]. The proof purpose acts as a safeguard to prevent the proof from being misused by being applied to a purpose other than the one that was intended. For example, without this value the creator of a proof could be tricked into using cryptographic material typically used to create a Verifiable Credential (assertionMethod) during a login process (authentication) which would then result in the creation of a Verifiable Credential they never meant to create instead of the intended action, which was to merely logging into a website.",
      "The expires property is OPTIONAL and, if present, specifies when the proof expires. If present, it MUST be an [XMLSCHEMA11-2] dateTimeStamp string, either in Universal Coordinated Time (UTC), denoted by a Z at the end of the value, or with a time zone offset relative to UTC. A conforming processor MAY chose to consume time values that were incorrectly serialized without an offset. Incorrectly serialized time values without an offset are to be interpreted as UTC.",
      "An OPTIONAL string value or unordered list of string values. Each value identifies another data integrity proof that MUST verify before the current proof is processed. If an unordered list, all referenced proofs in the array MUST verify. This property is used in Section 2.1.2 Proof Chains.",
      "Implementations MAY load application-specific JSON-LD context files from the network during development, but SHOULD permanently cache JSON-LD context files used by conforming secured documents in production settings, to increase their security and privacy characteristics. Goals of processing speed MAY be achieved through caching approaches such as those described above or functionally equivalent mechanisms."
    ],
    "proofs": [
      "An optional identifier for the proof, which MUST be a URL [URL], such as a UUID as a URN (urn:uuid:6a1676b8-b51f-11ed-937b-d76685a20ff5). The usage of this property is further explained in Section 2.1.2 Proof Chains.",
      "A verification method is the means and information needed to verify the proof. If included, the value MUST be a string that maps to a [URL]. Inclusion of verificationMethod is OPTIONAL, but if it is not included, other properties such as cryptosuite might provide a mechanism by which to obtain the information necessary to verify the proof. Note that when verificationMethod is expressed in a data integrity proof, the value points to the actual location of the data; that is, the verificationMethod references, via a URL, the location of the public key that can be used to verify the proof. This public key data is stored in a controller document, which contains a full description of the verification method.",
      "The date and time the proof was created is OPTIONAL and, if included, MUST be specified as an [XMLSCHEMA11-2] dateTimeStamp string, either in Universal Coordinated Time (UTC), denoted by a Z at the end of the value, or with a time zone offset relative to UTC. A conforming processor MAY chose to consume time values that were incorrectly serialized without an offset. Incorrectly serialized time values without an offset are to be interpreted as UTC.",
      "A string value that SHOULD be included in a proof if a domain is specified. The value is used once for a particular domain and window of time. This value is used to mitigate replay attacks. Examples of a challenge value include: 1235abcd6789, 79d34551-ae81-44ae-823b-6dadbab9ebd4, and ruby.",
      "An OPTIONAL string value supplied by the proof creator. One use of this field is to increase privacy by decreasing linkability that is the result of deterministically generated signatures."
    ],
    "resource-integrity": [],
    "contexts-and-vocabularies": [
      "Implementations that perform RDF processing MUST treat the JSON-LD serialization of the vocabulary URL as already dereferenced, where the dereferenced document matches the corresponding hash value below."
    ],
    "validating-contexts": [
      "While the algorithm described in Section 4.6 Context Validation provides one way of checking context values, and one optional way of safely processing unknown context values, implementers MAY use alternative approaches, or a different ordering of the steps, that provide the same protections."
    ],
    "context-injection": [],
    "securing-data-losslessly": [
      "Similarly, since conforming secured documents can be transferred from one security domain to another, conforming processors that process the conforming secured document cannot assume any particular base URL for the document. When deserializing to RDF, implementations MUST ensure that the base URL is set to null."
    ],
    "cryptographic-suites": [
      "The specification MUST identify a cryptographic suite type and any parameters that can be used with the suite.",
      "The specification MUST detail the hashing algorithms parameters, and other necessary details used to perform cryptographic hashing to the data to be protected.",
      "The specification MUST detail the proof verification algorithms, parameters, and other necessary details used to perform cryptographic verification of the data.",
      "An algorithm that takes a secured data document (map securedDocument) as input, and produces a cryptosuite verification result or an error. The cryptosuite verification result is a struct that contains the following items: verified A boolean that is true if the verification succeeded, or false otherwise. verifiedDocument A map that represents the secured data document with the verified proofs removed if verified is true, or null otherwise. The structure MAY contain other implementation-specific information that is useful for developers, such as debugging information. If an error is produced, the verification process failed to complete. An error, such as a network error, does not mean that a future attempt at verification would fail.",
      "The specification MUST contain a Security Considerations section detailing security considerations specific to the cryptographic suite.",
      "The JSON-LD context associated with the cryptographic suite MUST have its terms protected from unsafe redefinition, by use of the @protected keyword.",
      "The specification MUST provide a link to an interoperability test report to document which implementations are conformant with the cryptographic suite specification.",
      "Cryptographic suite designers MUST use mandatory proof value properties defined in Section 2.1 Proofs, and MAY define other properties specific to their cryptographic suite."
    ],
    "dataintegrityproof": [
      "The value of the cryptosuite property MUST be a string that identifies the cryptographic suite. If the processing environment supports subtypes of string, the type of the cryptosuite value MUST be the https://w3id.org/security#cryptosuiteString subtype of string.",
      "One of the design patterns seen in Data Integrity cryptosuites from 2012 to 2020 was use of the type property to establish a specific type for a cryptographic suite; the Ed25519Signature2020 cryptographic suite was one such specification. This led to a greater burden on cryptographic suite implementations, where every new cryptographic suite required specification of a new JSON-LD Context, resulting in a sub-optimal developer experience. A streamlined version of this design pattern emerged in 2020, such that a developer would only need to include a single JSON-LD Context to support all modern cryptographic suites. This encouraged more modern cryptosuites \u2014 such as the EdDSA Cryptosuites [DI-EDDSA] and the ECDSA Cryptosuites [DI-ECDSA] \u2014 to be built based on the streamlined pattern described in this section. To improve the developer experience, authors creating new Data Integrity cryptographic suite specifications SHOULD use the modern pattern \u2014 where the type is set to DataIntegrityProof; the cryptosuite property carries the identifier for the cryptosuite; and any cryptosuite-specific cryptographic data is encapsulated (i.e., not directly exposed as application layer data) within proofValue. A list of cryptographic suite specifications that are known to follow this pattern is provided in the Proof types section of the Verifiable Credentials Specifications Directory."
    ],
    "add-proof": [
      "Let proof be the result of calling the createProof algorithm specified in cryptosuite.createProof with inputDocument and options passed as a parameters. If the algorithm produces an error, the error MUST be propagated and SHOULD convey the error type.",
      "If options has a non-null challenge item, it MUST be equal to proof.challenge or an error MUST be raised and SHOULD convey an error type of PROOF_GENERATION_ERROR."
    ],
    "add-proof-set-chain": [
      "If options has a previousProof item that is a string, add the element from allProofs with an id attribute matching previousProof to matchingProofs. If a proof with id equal to previousProof does not exist in allProofs, an error MUST be raised and SHOULD convey an error type of PROOF_GENERATION_ERROR."
    ],
    "verify-proof": [
      "When a step says \"an error MUST be raised\", it means that a verification result MUST be returned with a verified of false and a non-empty errors list.",
      "If expectedProofPurpose was given, and it does not match proof.proofPurpose, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR.",
      "If challenge was given, and it does not match proof.challenge, an error MUST be raised and SHOULD convey an error type of INVALID_CHALLENGE_ERROR."
    ],
    "verify-proof-sets-and-chains": [
      "If proof contains a previousProof attribute and that attribute is a string, add the element from allProofs with an id attribute matching previousProof to matchingProofs. If a proof with id does not exist in allProofs, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR. If the previousProof attribute is an array, add each element from allProofs with an id attribute that matches an element of that array. If any element of previousProof array has an id attribute that does not match the id attribute of any element of allProofs, an error MUST be raised and SHOULD convey an error type of PROOF_VERIFICATION_ERROR."
    ],
    "context-validation": [],
    "processing-errors": [
      "The type value of the error object MUST be a URL that starts with the value https://w3id.org/security# and ends with the value in the section listed below.",
      "The detail value SHOULD provide a longer human-readable string for the error."
    ]
  }
}