From 2f8eabc990bd9cdca51206e76b11eda41cd95487 Mon Sep 17 00:00:00 2001 From: Mike Prorock Date: Tue, 27 Jun 2023 15:21:42 -0600 Subject: [PATCH] Add context integrity capabilities. Co-authored-by: Orie Steele Co-authored-by: Ted Thibodeau Jr Co-authored-by: Dmitri Zagidulin Co-authored-by: Manu Sporny Co-authored-by: David I. Lehn --- index.html | 128 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 128 insertions(+) diff --git a/index.html b/index.html index 1eff1ac44..fc1fbf981 100644 --- a/index.html +++ b/index.html @@ -2599,6 +2599,134 @@

Data Schemas

+
+

Integrity of Related Resources

+

+ When including a link to an external resource in a + verifiable credential, it is desirable to know whether + the resource that is pointed to is the same at signing time as + it is at verification time. This applies to cases where there + is an external resource that is remotely retrieved as well as + to cases where the issuer and/or + verifier may have local cached copies of a resource. +

+

+ It is also desirable to know that the contents of the JSON-LD + context(s) used in the verifiable credential are the + same when used by both the issuer and verifier. +

+

+ To validate that a resource referenced by a verifiable + credential is the same at verification time as it is at + issuing time, an implementer MAY include a property named + relatedResource that stores an array of objects + that describe additional integrity metadata about each + resource referenced by the verifiable credential. If + relatedResource + is present, there MUST be an object in the array for each remote + resource for each context used in the verifiable credential. +

+

+The requirement that contexts be listed in `relatedResource` is currently being debated in the VCWG. This requirement might be removed in future iterations of the specification. +

+

+ Each object in the + relatedResource array MUST contain the following: + the [[URL]] to the resource named id and the + digestSRI information for the resource + constructed using the method specified in Subresource + Integrity. +

+

+The Working Group is currently attempting to determine if cryptographic hash expression formats can be unified across all of the VCWG core specifications. Candidates for this mechanism include `digestSRI` and `digestMultibase`. There are arguments for and against unification that the WG is currently debating. +

+ There MUST NOT be more than one object in the + relatedResource per id. +

+

+ An object in the relatedResource array MAY + contain a property named mediaType that indicates + the expected media type for the indicated + resource. If a mediaType is included + it SHOULD be a valid media type as listed in the + + IANA Media Types + registry. +

+

+ Any object in the verifiable credential + that contains an `id` [[URL]] property MAY be annotated with + integrity information as specified in this section by inclusion + of digestSRI in the object. +

+

+ Any objects for which selective disclosure is desired SHOULD + NOT be included as an object in the + relatedResource array. +

+

+ Implementers are urged to consult appropriate sources, such as + the + + FIPS 180-4 Secure Hash Standard and the + + Commercial National Security Algorithm Suite 2.0 + to ensure that they are chosing a current and reliable hash + algorithm. At the time of this writing `sha384` SHOULD be + considered the minimum strength hash algorithm for use by + implementers. +

+

+ The working group is discussing if we will adopt more aspects + of subresource integrity as defined in [[SRI]] is adopted into + the [[JSON-LD]] specification as noted in that specifications + current + security considerations of that specification, this hash + in the VC can serve as an additional check towards ensuring + that a cached context used when issuing the VC matches the + remote resource. +

+

+

+

+

+

+

+
+

Refreshing