Is a verifiable credential in JSON-LD expand form valid?

[kdenhartog]

We've recently been toying around with the idea of how to enable verifiable credential validation when it's not possible to retrieve arbitrary context files. One of the ways we've looked to get around this is to include the semantics by passing a VC in the expanded form and including a list of contexts so that the credentials can be mapped back to a valid compact form VC which matches many of the normative statements within the spec.

With this in mind, I think it may make sense for us to look at how we could identify versions of a context using a hash for example https://www.w3.org/2018/credentials/ab4ddd9a531758807a79a5b450510d61ae8d147eab966cc9a200c07095b0cdcc and then combining this with passing of the expanded form credential so that the semantics of the credential don't need to be resolved before verification.

Thoughts?

[iherman]

The issue was discussed in a meeting on 2022-08-03

• no resolutions were taken

View the transcript

6.1. Is a verifiable credential in JSON-LD expand form valid? (issue vc-data-model#779)

See github issue vc-data-model#779.

Brent Zundel: First one we are looking at is #779. I anticipate some of these may be a little less clear, because of the way the original data model was written..

Manu Sporny: The answer is no, an expanded document is not valid..
… But this has more to do with vc-data-model than data-integrity; would suggest leave it.

Brent Zundel: OK, anyone disagree?.
… Removing the "data-integrity?" label..

[jandrieu]

@kdenhartog said

We've recently been toying around with the idea of how to enable verifiable credential validation when it's not possible to retrieve arbitrary context files.

My answer: Don't.

Not to be snarky, but if the software doesn't recognize a context it should NOT process the VC. There is no time in a production system where you should dereference an unknown context. Either the software was written to handle the context, or it wasn't. You can't expect that the software can magically interpret a previously unseen context.

It is a known security failing to dereference contexts in production. If you follow that guidance, in production, you should never worry about "unretreivable contexts" because you shouldn't be retrieving them anyway.

[kdenhartog]

Generic wallets that are meant to store an arbitrary VC need to do this in order to understand the context of the data requested and to respond to it. Do people think wallet developers are meant to be defining every credential type they process? That seems like it's going to re-run into the scopes problem of OIDC.

[jandrieu]

Generic wallets should NOT do this.

If you don't understand the context, you should not process the VC.

Anything else is a bad security practice.

Because, yes, developers are meant to understand every credential type they process. Otherwise, how can you hope to believe that you are processing it correctly?

What I think you want is a generic wrapper that embeds claims which happen to use a different context. You can do that with an @context as a property of the credentialSubject or below, which should be best practices for VC design, but I think its so obscure, almost nobody uses it.

[dlongley]

Wallets can process all of the properties defined by the core VC context (presuming the wallet knows this context, as all VC wallets should). They should not be processing other values defined by other contexts unless those contexts are known to the wallet.

Though, I will say that I think one of the troubles we get into in these discussions is using the word "processing" without knowing if all the participants are using the same definition for it. The point here is that if you don't understand what a property in a VC means, you shouldn't use that property.

[TallTed]

@jandrieu -- Please edit your latest comment and wrap @context in a code fence, as that GitHub user continues not to be involved in our discussions ... except insofar as we keep pinging them with such un-fenced @ mentions.

[agropper]

We have some real-world examples of generic wallets to consider:
A - Apple, Google, Microsoft, etc... passkey as an example of accountable, context-neutral identifiers in a generic sense
B - Sign-in With Ethereum for a standardized way to shift the context processing issue through a human-readable presentation
C - ISO 18013-5 mDL as a specification that combines data model and protocol to address uses across dozens of different contexts.

I would think our data model discussion needs to start with these current examples rather than the assumptions we made years ago at the dawn of SSI.

[vongohren]

Though, I will say that I think one of the troubles we get into in these discussions is using the word "processing" without knowing if all the participants are using the same definition for it. The point here is that if you don't understand what a property in a VC means, you shouldn't use that property.

When one says use, what entitles use? As a wallet maker I would want to display the data potentially, but I should not display something that I dont know what is?

Or is use when you as wallet replies to a verification request and a property is asked for, but its not the same context, one does not mix and match
@dlongley

[kdenhartog]

Generic wallets should NOT do this.

If you don't understand the context, you should not process the VC.

Anything else is a bad security practice.

Because, yes, developers are meant to understand every credential type they process. Otherwise, how can you hope to believe that you are processing it correctly?

What I think you want is a generic wrapper that embeds claims which happen to use a different context. You can do that with an @context as a property of the credentialSubject or below, which should be best practices for VC design, but I think its so obscure, almost nobody uses it.

Sure, but then as you pointed out above these @context definitions need to be statically loaded in with the wallet code in order to process it. For example, let's say [email protected] contains the contexts for driver's license and green card, but not for degree. Now let's say the user of [email protected] receives a degree credential in their wallet, but since it doesn't have a degree context already bundled into the wallet as a context then the user can't present this credential to an employer now because they comprehend the context of the claims being requested by the employer so that they can present the correct credential. Instead, the user needs to wait for [email protected] so that the new context for degree can also be bundled in so that they can correctly resolve the VP request and identify all the credentials in their wallet to generate a VP.

This is why I was stating it would be more useful to use expanded form JSON-LD is because at this point the expanded IRIs can be processed without making a network request or having to rely on the developer to pre-validate each and every possible claims definition and bundle it into the wallet assets.

[msporny]

Related to #948 (comment), which would make expanded form VCs illegal.

[msporny]

PR #1050 has been raised to address this issue. Once that PR has been merged, this issue will be closed.

[msporny]

PR #1050 has been merged, closing.