-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add language clarifying multiple data schemas #1023
Conversation
The value of the <code>credentialSchema</code> <a>property</a> MUST be a single | ||
data schema object which provides <a>verifiers</a> with enough information |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, this makes it not possible to provide more than one type of schema... for example, one schema to do data validation (e.g., JSON Schema) and another schema to do data transformation (e.g., CL Signatures, Gordian Envelopes, etc.).
Limiting to ONE and only one schema is probably not a good idea.
Limiting to one schema type in the list of credentialSchema
s is probably better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Limiting to ONE and only one schema is probably not a good idea.
If we don't limit to one, we must provide examples that make use of more than one, and tests...
I suggest limiting to one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - suggest limiting to one schema type in the list of credential schema, which when resolved can contain multiple schemas
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't limit to one, we must provide examples that make use of more than one, and tests...
I agree with this, we need to weigh up the complexity that supporting multiple schemas introduces against possible usecases, every feature can also be a bug. I also don't think using a schema to do data transformation is the right use of a schema and doesn't really match what this feature is described as being for in the current standard.
index.html
Outdated
data schema object which provides <a>verifiers</a> with enough information | ||
to determine if the provided data conforms to the provided schema object. Each | ||
<code>credentialSchema</code> MUST specify its <code>type</code> (e.g., | ||
<code>JsonSchemaValidator2018</code>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should remove JsonSchemaValidator2018
since it never existed in practice and was just suggested as an example, IIRC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
100% agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will remove.
index.html
Outdated
to determine if the provided data conforms to the provided schema object. Each | ||
<code>credentialSchema</code> MUST specify its <code>type</code> (e.g., | ||
<code>JsonSchemaValidator2018</code>, | ||
<code><a href="https://w3c-ccg.github.io/vc-json-schemas/">CredentialSchema2022</a></code>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should link to this one non-normatively.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need a normative link, or the feature needs to be removed from the specification.
It could be this one, or the one I proposed to the list which the traceability community uses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How can I link to this non-normatively?
What about keeping it non-normative until v2 is shored up (in progress).
index.html
Outdated
or <code><a href="https://transmute-industries.github.io/vc-credential-schema-open-api-specification/"> | ||
OpenApiSpecificationValidator2022</a></code>), and an <code>id</code> <a>property</a> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't link to vendor organization Github repos in standards-track specs because 1) not all vendor organizations stick around for as long as these specs do and the links break over time, and 2) competing vendors complain of low-key favoritism when we do this.
Ideally, all external links should point to stable documents that we expect to last for a decade or more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I proposed this item for the group to consider on the mailing list, perhaps we can pull the work item into the group?
Then the W3C can manage hosting of the document, and the references would be internal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other reference is to the W3C CCG which also relies on "GitHub" for hosting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additional context, there are at least 4 companies using this approach today, its the same approach used by
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@OR13 can you move it into the CCG and I'll add it back then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@decentralgabe we are not required to "move things to CCG" by W3C Process.
We can adopt them directly as work items, as a working group.
I suggest adding a note saying it will be removed in future draft if its not adopted as a work item, to both links.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Waiting for you and @msporny to have consensus before proceeding here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly editorial changes requested. The one item that's concerning is the limitation of only being able to associate a single schema with a VC, which removes composability of the credentialSchema
feature.
Assuming issues are filed for disagreements, this is an improvement and should be accepted. |
Co-authored-by: Manu Sporny <msporny@digitalbazaar.com>
Co-authored-by: Manu Sporny <msporny@digitalbazaar.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
The issue was discussed in a meeting on 2023-02-01
View the transcript3.5. Add language clarifying multiple data schemas (pr vc-data-model#1023)See github pull request vc-data-model#1023. Manu Sporny: New one PR 1023 from yesterday, about credential schemas. This PR says you can have only one credential schema, and then there's some clarifying language. Please jump in if you have opinions on credential schema..
Manu Sporny: Moving on to vc-status-list-2021 PRs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Delegating composability to an hypothetic future implementation type of schema validation seems ok to me.
I’m not sure it requires an entire paragraph (since cardinality is clear, I think it would be ok to remove that note/the second paragraph altogether).
The cardinality of 1 schema is clear to me.
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
I believe the PR is blocked until we resolve whether schemas can be a single (and solve multiple in the type) or multiple (and add language here on how to process multiple). I believe the former approach is simpler. Shall we aim to discuss this on an upcoming call? |
yes happy to |
The issue was discussed in a meeting on 2022-09-15
View the transcript5.4. Verification of multiple credential schemas (issue vc-data-model#950)See github issue vc-data-model#950. Gabe Cohen: There is a PR. See github pull request vc-data-model#1023. |
After today's call I'm ready to close this PR and move back to discussion in the issue #950 Do you think that's reasonable - @dlongley @dmitrizagidulin @OR13 ? |
The issue was discussed in a meeting on 2023-05-03
View the transcript3.2. Add language clarifying multiple data schemas (pr vc-data-model#1023)See github pull request vc-data-model#1023. Brent Zundel: nobody wanted to speak to that.
Gabe Cohen: some discussion whether there should be a single credential schema possible per credential. Dave Longley: we already have mechanism for starting a set.
Dave Longley: if not, if different credential schema types can become multitype schemas then i would expect that somebody creates a multi purpose mechanism. Gabe Cohen: not exactly an accurate representation. Orie Steele: agree with gabe. Brent Zundel: if i understand correctly if multiple schemas are present and the processing rules that then apply that we limit schemas to a single schema differentiated by types, so processing rules for single schema can be defined by the type and we also recognize that multiple schemas can be developed by having a composed schema.
Dave Longley: i don't know where i am at on this issue in particular.
Dave Longley: whether or not schemas are used is up to verifier.
Oliver Terbu: I am in favor of keeping complexity on the Dmitri Zagidulin: my initial thought was that multiple items in cred schema was initially confusing. but then realized that.
Dmitri Zagidulin: shacl schema or json schema or whatever schema language other come up with.
Dmitri Zagidulin: question is if we need to specify and or or semantic for that field.
Brent Zundel: encourage folks to have that conversation.
Brent Zundel: we would like to have this PR to move forward. |
I going to mark this as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR has conflicts and based on the discussion in the last working group call, it seems better to just let JSON-LD norms build how this property can be used.
This means the following will all remain valid:
"credentialSchema": "IRI",
"credentialSchema": [ { "id": "IRI", "type": "Class", ...}, { "id": "IRI-2", "type": "Class-2", ...} ],
"credentialSchema": { "id": "IRI", "type": "Class", ...},
@OR13 I'm open to this change but then I believe we need to add language such as
|
@decentralgabe we don't need to add that language, because it's already assumed people understand how JSON-LD works. We say the base media type is JSON-LD and the the standard uses compact form. If people don't understand what that means, they cannot implement the spec. If they understand it, they can do anything that is legal to a parser that processes the contexts |
Also member order is never preserved in JSON-LD, so there is no way to assure the order without adding additional details to the context. |
@OR13 I'm not sure I fully understand how JSON-LD works. If we cannot guarantee processing order, will we still need to state how to interpret the results of processing multiple credential schemes? If not - how will we make sure verifiers have consistent results? |
While this works and is correct, I am not sure it is the best choice. The usage of We may, instead, use a different key there ( |
I am not sure I understand this remark. JSON-LD is oblivious to this, which also means that it does not provide any guidance per se. If (That being said, do we really want such a strong requirement, @decentralgabe? Alternatively, we could say that if any of the schema validate, we are good...) |
@iherman wrote:
There is also the option that proof chains took in the Data Integrity spec via the https://w3c.github.io/vc-data-integrity/#example-a-proof-chain-in-a-data-document That said, don't know if anyone has such use cases today. |
Closing since there isn't consensus. Let's please continue the discussion here #950 (comment) |
Addresses #950
💥 Error: 500 Internal Server Error 💥
PR Preview failed to build. (Last tried on Feb 6, 2023, 6:15 PM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
🚨 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.
🔗 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.