Add context integrity approach for VC-JWTs #90
Conversation
|
What are the benefits of putting this in vc-jwt, as opposed to putting them in the VCDM? |
this absolutely could go in the core data model if it is desired there - at minimum, having this in VC-JWT to address the security considerations notes around contexts in JSON-LD etc will be required. |
|
thanks @andresuribe87 - i added a few things based on your careful reading. very very much appreciated. |
There was a problem hiding this comment.
This is not at all JWT-like. For instance, it uses a long-form timestamp rather than a numeric time value.
I also believe that, should we decide that we want this functionality, it belongs in the data model rather than VC-JWT, because that's where the context stuff is. We shouldn't be doing anything to add to context semantics in this spec.
index.html
Outdated
| <section> | ||
| <h2>Context Integrity</h2> | ||
| <p> | ||
| In some cases is is desireable to know that the contents of the |
There was a problem hiding this comment.
In some cases, it is desirable
index.html
Outdated
| <h2>Context Integrity</h2> | ||
| <p> | ||
| In some cases is is desireable to know that the contents of the | ||
| context(s) utilized in the verifiable credential is the same as |
I think the core data model is likely a better place for this.... Will want bring it up on the next VCWG call @Sakurann @brentzundel |
This is because this is a core data model "extension" that just happens to be being defined here... which... seems wrong. This should be handled like all the other "core data model extensions", in the core spec. And I would object there a well, unless a similar bar to what has been met for |
Co-authored-by: Orie Steele <[email protected]>
|
opened this pr on core data model that would permit us to not handle this in vc-jwt as it is really across teh board an issue for VC securing formats and should be handled consistently |
| As noted in [[rfc7515]] when utilizing JSON [[rfc7159]], strict validation is a security | ||
| requirement. If malformed JSON is received, it may be impossible to reliably interpret the |
There was a problem hiding this comment.
| As noted in [[rfc7515]] when utilizing JSON [[rfc7159]], strict validation is a security | |
| requirement. If malformed JSON is received, it may be impossible to reliably interpret the | |
| As noted in [[rfc7515]], strict validation is a security requirement when using | |
| JSON [[rfc7159]]. If malformed JSON is received, it may be impossible to reliably interpret the |
| producer's intent, potentially leading to ambiguous or exploitable situations. | ||
| To prevent these risks, it is essential to use a JSON parser that strictly validates the syntax | ||
| of all input data. It is essential that any JSON inputs that do not conform to the JSON-text syntax defined in [[rfc7159]] | ||
| be rejected in their entirety by JSON parsers. Failure to reject invalid input could compromise |
There was a problem hiding this comment.
| be rejected in their entirety by JSON parsers. Failure to reject invalid input could compromise | |
| be rejected in their entirety by JSON parsers. Failure to reject such invalid input could compromise |
| <h2>Context Integrity</h2> | ||
| <p> | ||
| In some cases it is desirable to know that the contents of the | ||
| context(s) utilized in the verifiable credential are the same as |
There was a problem hiding this comment.
| context(s) utilized in the verifiable credential are the same as | |
| context(s) used in the verifiable credential are the same as |
| Follow all security considerations outlined in [[rfc7515]] and [[rfc7519]]. | ||
| </p> | ||
| <p> | ||
| When utilizing JSON-LD, take special care around remote retrieval of contexts and follow the |
There was a problem hiding this comment.
| When utilizing JSON-LD, take special care around remote retrieval of contexts and follow the | |
| When using JSON-LD, take special care around remote retrieval of contexts and follow the |
| </p> | ||
| <p> | ||
| To validate that a context included in a Verifiable Credential is | ||
| the same at verification time as at issuing time an implementer |
There was a problem hiding this comment.
| the same at verification time as at issuing time an implementer | |
| the same at verification time as at issuing time, an implementer |
| the URL to the context named <code>context</code>, a | ||
| <code>timestamp</code> | ||
| that indicates the time at which the hash was computed, the | ||
| <code>hash</code> | ||
| of the context, and the <code>method</code> which indicates what |
There was a problem hiding this comment.
It might be better to use an <ul> for these. If making that switch, there should be no punctuation at the end of any list item (i.e., delete the semicolons here as well as the . after Registry).
| the URL to the context named <code>context</code>, a | |
| <code>timestamp</code> | |
| that indicates the time at which the hash was computed, the | |
| <code>hash</code> | |
| of the context, and the <code>method</code> which indicates what | |
| the URL to the context named <code>context</code>; a | |
| <code>timestamp</code> | |
| that indicates the time at which the hash was computed; the | |
| <code>hash</code> | |
| of the context; and the <code>method</code> which indicates what |
| href="https://www.iana.org/assignments/named-information/named-information.xhtml">IANA | ||
| Named Information Hash Algorithm Registry</a> to ensure that they | ||
| are chosing a current and reliable hash algorithm. At the time of | ||
| this writing `sha-256` should be considered the minimum strength |
There was a problem hiding this comment.
| this writing `sha-256` should be considered the minimum strength | |
| this writing, `sha-256` is considered the minimum strength |
| If at a later date subresource integrity as defined in [[SRI]] is | ||
| adopted into the [[JSON-LD]] specification as noted in that | ||
| specifications <a | ||
| href="https://www.w3.org/TR/json-ld11/#security">current security | ||
| considerations</a> 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. |
There was a problem hiding this comment.
| If at a later date subresource integrity as defined in [[SRI]] is | |
| adopted into the [[JSON-LD]] specification as noted in that | |
| specifications <a | |
| href="https://www.w3.org/TR/json-ld11/#security">current security | |
| considerations</a> 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. | |
| If subresource integrity as defined in [[SRI]] is adopted into | |
| the [[JSON-LD]] specification at a later date, as noted in the | |
| <a href="https://www.w3.org/TR/json-ld11/#security">current security | |
| considerations</a> 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. |
|
This PR should be closed, because w3c/vc-data-model#1140 has been opened. |
With verifiable credentials, or any signed JSON-LD it is often a desirable property to know that the context you are working with is the same on both ends, or if there has been a change. This PR adds an optional ability to provide the hash of contexts used at issuance time.
Preview | Diff