added clarifying note to credentialSchema section #533
Conversation
Signed-off-by: Brent <[email protected]>
dlongley
changed the title
| The <code>credentialSchema</code> provides an opportunity to annotate type | ||
| definitions or lock them to specific versions of the vocabulary. Authors of VCs | ||
| can include a static version of their vocabulary via credentialSchema that is | ||
| locked to some content integrity protection mechanism. |
There was a problem hiding this comment.
You may also want to make a point about doing syntactic checking on the credential as well using stuff like JSON Schema. Just reminding folks that this property has at least two uses.
There was a problem hiding this comment.
In any case, I approve of the change whether or not you take the above comment into account.
There was a problem hiding this comment.
Made some changes in cd62b44
There was a problem hiding this comment.
I think this text is digging a bigger hole for @contexts. The phrase "lock them to specific versions of the vocabulary" implies that the @context, which was previously deemed to be sufficient and satisfactory (before credentialSchema was added), was in fact a bed of shifting sand that could change during the lifetime a VC. This hardly gives people confidence in @context. There should be no need for this locking if the definitions in @context are immutable, and all that can happen is new properties be added to it (new properties that cannot occur in the current VC because the type property should also be fixed and not subject to dynamic change).
So in summary, I do not think this text adds clarity, but rather, further confusion.
There was a problem hiding this comment.
Primarily, @context serves a different purpose from credentialSchema. The former provides mappings from JSON keys to vocabulary terms and expected value types. These mappings can be integrity protected via technologies such as hashlinks. The latter allows a VC issuer to make additional arbitrary statements about the vocabulary terms, including restricting or making immutable their meaning.
Secondarily, as we've stated with other concepts in the VC data model spec (e.g. anonymity), there is a sliding scale of risk inherently involved in this work. The greater the risk and value of a VC, the more an issuer may be willing to increase their cost and implementation burden to protect their statements. On one end of the spectrum, a low value VC issuer may be happy to use a very popular (and unlikely to change in a substantive way) vocabulary such as schema.org to make some statements in their VC and leave it at that. On the other end of the spectrum, a high value VC issuer may be willing to create or pay to use decentralized ledger technology that will store immutable copies of vocabularies for all time -- and then reference those copies in their VC.
Using credentialSchema allows a VC issuer to independently lock down the vocabulary terms in a VC to something specific. It also allows them to lock down the structure of the JSON, if desired, to something specific via technologies such as json-schema.
Signed-off-by: Brent <[email protected]>
|
I forget where we got to here. I think we agreed that we can add lots of non-normative text to this section, and @David-Chadwick said he'd do it... but are we:
|
|
@msporny As I recall, you said you would write this text since you are more intimately knowledgeable about JSON-LD and its nuances. I said I would write the refresh text (which I did) |
There was a problem hiding this comment.
Alright, given @David-Chadwick's response, I'm going to merge @brentzundel's PR since it has general agreement now, and then submit a new PR that will build on @brentzundel's PR.
This PR is intended to address issue #474
Signed-off-by: Brent [email protected]