update section on storage, content integrity protection #191
Conversation
|
removed |
index.html
Outdated
| before processing. When making use of the <code>JsonSchemaCredential2023</code> representation | ||
| of a schema, the credential's associated integrity protection mechanism can act | ||
| as mutability detection since digital signatures break with content changes. |
There was a problem hiding this comment.
I don't quite follow this sentence. What are you trying to say?
Separately, we already have a normative section about this above; what's the value of this informative section?
There was a problem hiding this comment.
simply: a digital signature provides information that lets you know if content has been tampered with
the section above is on processing this is intended to be guidance on using schemas
There was a problem hiding this comment.
I think I get what you're trying to say. Making a suggestion on wording below.
index.html
Outdated
| As an alternative, the aforementioned [[SRI]] scheme may be used to | ||
| provide content integrity protection, ensuring that the underlying <a>credential schema</a> | ||
| resource has not been tampered with. |
There was a problem hiding this comment.
An issuer of the credential schema may modify the contents of the JsonSchemaCredential, and integrity protection would still pass. Validation of the schema on a credential may fail for some credentials for which it used to pass.
I think it's worth clarifying that may be the case here, and that the mechanism to prevent against that is [[SRI]] (regardless of the type of credential schema being used).
There was a problem hiding this comment.
An issuer of the credential schema may modify the contents of the JsonSchemaCredential, and integrity protection would still pass
If they re-sign the credential this is true, but not otherwise which is the main concern...
I think this raises a larger question -- are VCs immutable? and I'm not sure...I think the answer is no. The secured form of these credentials are immutable at least
There was a problem hiding this comment.
My concern is the verifiers need the ability to run validation with the same data that the original credential was issued with. Otherwise a credential's validity may change unexpectedly.
I think this raises a larger question -- are VCs immutable? and I'm not sure...I think the answer is no. The secured form of these credentials are immutable at least
That's a good question. I'm not sure either, I also lean towards no. The secured form is immutable, but it's easy to mutate the value that results from dereferencing a @id by simply changing what the URL points to.
My suggestion is to let implementers know that they should:
- Use the
digestSRIin the original credential when they want to ensure that the contents have not been changed since issuance. - Not use it and accept that they're trusting the publisher of the schema to mutate it in a backwards compatible way.
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com> Co-authored-by: Andres Uribe <andresuribe87@gmail.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Preview | Diff