Feature: vc-jwt context

[mprorock]

I do not believe that this context is correct (as in where we want to end up), but i believe that it is a good start for discussion

---

Preview | Diff

[mkhraisha]

This is a clear path forward on the @context issue, allowing you to interoperate cleanly.

Might need some language around how to process if @context is present in the jwt

[mprorock]

Might need some language around how to process if @context is present in the jwt

agreed - we could add an issue and reference from this PR, or add to this - happy to take suggestions

the top case i see there is for when multiple contexts are used and not suggested by a cty or similar

[mkhraisha]

What happens if a context is used that breaks the implied context, for example, if I define a context that makes iss only ever to be a string?
I'm assuming the answer is you use the embedded context over the implied one but we should be clear.

[OR13]

this stuff needs to be in the @context, but I think the intention is clear.

[mprorock]

made some adjustments - still working through a double check on n-quads bc json-ld is hard

[decentralgabe]

👏 great demonstration of the concept

[mprorock]

i believe there is an implied update in the core data model "Verifiable credentials define terms in a JSON-LD context at https://www.w3.org/ns/credentials/v2. Implementers SHOULD include the verifiable credential context in their object definitions. Implementers MAY include additional context as appropriate."

[selfissued]

I understand the intent of this PR and it may not be harmful but it also may not be helpful. It isn't necessary to apply a mapping to VC-JWTs to be able to successfully define and use them. Adding this to the spec might confuse some people into thinking that it is necessary or recommended.

[bumblefudge]

I'm not sure I understand the risk of confusion, is this about the word "implies"? Would it be more precise to mirror the language of the resolution recorded here and word it as a requirement for "bidirectional transformation" rather than an... implication? Happy to straw-man a more explicit (although verbose) version if anyone thinks it might be less confusing.

[bumblefudge]

I.e.

If bidirectional transformation to RDF-based proof types is desired, implementers MUST use the content type vc+jwt and each verifiable credential MUST include an @context property set to the appropriate data model version's base context. Doing so provides semantic interoperability and deterministic conversion to RDF via the [[vc-data-model]] and its base context without compromising the integrity guarantees of either expression or requiring re-issuance or re-signing.

Im happy to cease and desist if I'm misinterpreting what helpful looks like (having not been at the F2F), or continue bikeshedding with further input.

[mprorock]

@bumblefudge that topic is a whole nother can of worms. Intent on this PR is to get a starting point to demonstrate how to link a JWT using only registered and private claims back into the graph model and semantics afforded us by the core data model context. It could for sure, serve as a building block in helping towards the direction indicated by the wg

[OR13]

We are not required to add this PR here, just showing that it is possible is enough.

A few options:

1. A link to this in the appendix
2. An informative comment in the appendix

I agree it could be confusing if not introduced carefully.

[mprorock]

Closing in favor of #56