You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a variety of deployed systems that process VCs as JSON today.
The v1.0 and v1.1 specification provided clear guidance on how to process a VC using only JSON tooling and a little extra logic (from the latest published VCDM v1.1 global standard):
NOTE: Though this specification requires that a @contextproperty be present, it is not required that the value of the @contextproperty be processed using JSON-LD. This is to support processing using plain JSON libraries, such as those that might be used when the verifiable credential is encoded as a JWT. All libraries or processors MUST ensure that the order of the values in the @contextproperty is what is expected for the specific application. Libraries or processors that support JSON-LD can process the @contextproperty using full JSON-LD processing as expected.
This guidance was removed in PR #1182 and it is leading to confusion in the ecosystem; people are starting to believe that you can't process a VC in "pure JSON" mode, and that does not reflect the reality that organizations are doing just that today. Here are the use cases where VCs are processed in "pure JSON" mode today:
When using the VC-JOSE-COSE specification to sign, processing performed is purely JSON-based.
When performing JSON Schema validation (via vc-json-schema), processing performed is purely JSON-based.
When serializing/deserializing VCs into document-oriented databases (or databases in general), processing performed is purely JSON-based (or text-based).
When operating on the data in a software application, after verification is performed, processing performed is often JSON-based.
The specification used to be clear about this, and after PR #1182 was merged, is no longer clear about this reality. What was in the specification before should be improved. We need to document that the ecosystem is performing this sort of processing today on VCs and that it's an entirely legitimate way to process this data. IOW, JSON-LD processing is optional in a number of cases, and is only mandatory when you want to ensure that the semantics are well formed (and there are a number of use cases where you don't need to do that).
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
There are a variety of deployed systems that process VCs as JSON today.
The v1.0 and v1.1 specification provided clear guidance on how to process a VC using only JSON tooling and a little extra logic (from the latest published VCDM v1.1 global standard):
This guidance was removed in PR #1182 and it is leading to confusion in the ecosystem; people are starting to believe that you can't process a VC in "pure JSON" mode, and that does not reflect the reality that organizations are doing just that today. Here are the use cases where VCs are processed in "pure JSON" mode today:
The specification used to be clear about this, and after PR #1182 was merged, is no longer clear about this reality. What was in the specification before should be improved. We need to document that the ecosystem is performing this sort of processing today on VCs and that it's an entirely legitimate way to process this data. IOW, JSON-LD processing is optional in a number of cases, and is only mandatory when you want to ensure that the semantics are well formed (and there are a number of use cases where you don't need to do that).
The text was updated successfully, but these errors were encountered: