Skip to content
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

Explain relationship between Presentations and Verifiable Credentials #910

Closed
msporny opened this issue Aug 17, 2022 · 2 comments
Closed

Comments

@msporny
Copy link
Member

msporny commented Aug 17, 2022

The topic of the relationship between presentations and verifiable credentials was raised in a PR regarding the vc/v2 JSON-LD Context. Specifically, this term definition:

"verifiableCredential": {
  "@id": "https://www.w3.org/2018/credentials#verifiableCredential",
  "@type": "@id", 
  "@container": "@graph"
}

can we get a "plain english" explanation of @type and @container?

In this specific case, "@type": "@id" means "Interpret the value that is associated with verifiableCredential as an IRI (effectively, a URI that supports international character sets)". That is, the value will not be a string or other typed value, but rather, a resource identifier of some kind. More on this feature here: https://w3c.github.io/json-ld-syntax/#example-type-coercion

The "@container": "@graph" bit means "The value that is associated with verifiableCredential is another graph of information that lives outside of the current graph of information". That is, we're referencing another bundle of information (the verifiable credential) from the current bundle of information (the verifiable presentation). In other words, Don't cross the streams. More on this feature here: https://w3c.github.io/json-ld-syntax/#named-graphs

None of that is really explained in the VC Data Model specification, and we probably should explain it in some sort of "Advanced Concepts" section. Co-mingling "the thing you're talking about" and "the thing you're digitally signing" lead to semantic ambiguity that we really should continue to avoid (we have successfully done so since the beginning of the VCWG).

So, the question is: Should we document this information model separation in the specification?

@TallTed

This comment was marked as resolved.

@brentzundel
Copy link
Member

closing this issue as it is a sub-case of #881

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants