Tracking Issue from TPAC: What does JSON-LD compatible JSON mean?

[brentzundel]

Tracking Issue from TPAC: What does JSON-LD compatible JSON mean?

Please use comments to make concrete proposals.

[dlongley]

First attempt at getting things started...

The core data model should be RDF, but serialized using a profile of JSON-LD that is idiomatic JSON. This should be a contextualized, compact form that could be easily checked against a JSON schema and then consumed by JSON developers that are otherwise unfamiliar with JSON-LD.

[nadalin]

First attempt at getting things started...

The core data model should be RDF, but serialized using a profile of JSON-LD that is idiomatic JSON. This should be a contextualized, compact form that could be easily checked against a JSON schema and then consumed by JSON developers that are otherwise unfamiliar with JSON-LD.

What would be the requirement for RDF from a data model perspective, I don't see anything in the data model that would require RDF

[dlongley]

The data model today is essentially subject-property-value statements -- and containers / wrappers around those statements (aka "graphs"). This is essentially RDF so we should just reuse it, it's a standard (if this buys us having to write some text).

[msporny]

A cut at some language that might provide some clarity around what "JSON-LD compatible JSON" means. The Verifiable Credentials Data Model is "JSON-LD compatible JSON", which means the following:

• All Verifiable Credentials expressed MUST utilize the @context parameter where the values SHOULD be URLs. That is, in-line JSON-LD Contexts are strongly discouraged (we might even want to go as far as forbidding them).
• JSON-LD Compact Form is the only allowed form of JSON-LD. JSON-LD expanded form is disallowed to eliminate the requirement to always perform JSON-LD processing in processing pipelines where its not needed.
• The underlying data model is JSON-LD, which is a superset of (and round-trippable to/from) RDF.

In order to make development easier for developers coming from a JSON background, we might consider:

• The Verifiable Credentials specification will provide an "experimental" JSON-LD Context (https://www.w3.org/ns/credentials/experimental/v1, with an @vocab value set to https://www.w3.org/2018/credentials/undefined# such that developers need not define a JSON-LD Context or Vocabulary semantics as an initial step in the development process.
• Implementations SHOULD reject verification of any VC that utilizes the https://www.w3.org/ns/credentials/experimental/v1 JSON-LD Context in a production environment.

The above makes the data model crystal clear, is compatible with all known JSON-LD processors, helps developers coming from a purely JSON background to get started quickly, and retains JSON-only processing modes that are compatible with JSON-LD. Some concrete proposals that we could put in front of the group are:

PROPOSAL: Verifiable Credentials MUST utilize the @context parameter where the values SHOULD be URLs.

PROPOSAL: Verifiable Credentials SHOULD NOT utilize inline JSON-LD Contexts (objects as values) for the @context.

PROPOSAL: Verifiable Credentials MUST be expressed in JSON-LD Compact form.

PROPOSAL: The underlying data model for Verifiable Credentials is JSON-LD.

And the proposals to help make development easier for developers coming from a JSON background:

PROPOSAL: As an initial iteration on the idea, the Verifiable Credentials specification will define an "experimental" JSON-LD Context (https://www.w3.org/2018/credentials/experimental/v1, with an @vocab value set to https://www.w3.org/2018/credentials/undefined# such that developers need not define a JSON-LD Context or Vocabulary semantics as an initial step in the development process.

PROPOSAL: A conforming processor SHOULD raise an error if a VC utilizes the https://www.w3.org/ns/credentials/experimental/v1 JSON-LD Context in a production environment. The definition of "production environment" is left as an exercise to the implementer.

/cc @OR13 @tplooker @mprorock @peacekeeper @philarcher @mkhraisha @dlongley @brentzundel @Sakurann

[OR13]

@msporny Thank you for taking the time to write this up!

That is, in-line JSON-LD Contexts are strongly discouraged (we might even want to go as far as forbidding them).

-1 to this guidance... it also contradicts conversations with schema.org / google regarding usage of JSON-LD on web pages.

• https://twitter.com/danbri/status/1577350999852843011
• https://twitter.com/danbri/status/1571246982538067973

Suggest the working group NOT provide guidance of this form in a W3C TR.

JSON-LD Compact Form is the only allowed form of JSON-LD. JSON-LD expanded form is disallowed to eliminate the requirement to always perform JSON-LD processing in processing pipelines where its not needed.

+1 to this.

The underlying data model is JSON-LD, which is a superset of (and round-trippable to/from) RDF.

+1 to this.

The Verifiable Credentials specification will provide an "experimental" JSON-LD Context (https://www.w3.org/ns/credentials/experimental/v1, with an @vocab value set to https://www.w3.org/2018/credentials/undefined# such that developers need not define a JSON-LD Context or Vocabulary semantics as an initial step in the development process.
Implementations SHOULD reject verification of any VC that utilizes the https://www.w3.org/ns/credentials/experimental/v1 JSON-LD Context in a production environment.

-1 to this, counter offer:

{
  "@context": [
    // "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/ns/credentials/v2",
    // "https://www.w3.org/2018/credentials/examples/v1"
    { "@vocab": "https://www.w3.org/ns/credentials#" } 
  ],
  "id": "http://example.edu/credentials/1872",
  "type": ["VerifiableCredential", "NewCredentialType"],
  "issuer": { 
    "id": "did:example:123", 
     "type": ["Organization", "OrganizationType"] 
   },
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:456", 
    "type": ["Person", "JobType"],
    "claimName": "claimValue"
  }
}

#935

PROPOSAL: Verifiable Credentials MUST utilize the @context parameter where the values SHOULD be URLs.

+1

PROPOSAL: Verifiable Credentials SHOULD NOT utilize inline JSON-LD Contexts (objects as values) for the @context.

-1 (with serious concerns about how this will cripple adoption in certain use cases).

Suggest the working group NOT provide guidance of this form in a W3C TR.

PROPOSAL: Verifiable Credentials MUST be expressed in JSON-LD Compact form.

+1

PROPOSAL: The underlying data model for Verifiable Credentials is JSON-LD.

+1 (noting that we don't need to propose this, @context is required in v1.1 and the data model is JSON).

PROPOSAL: As an initial iteration on the idea, the Verifiable Credentials specification will define an "experimental" JSON-LD Context (https://www.w3.org/2018/credentials/experimental/v1, with an @vocab value set to https://www.w3.org/2018/credentials/undefined# such that developers need not define a JSON-LD Context or Vocabulary semantics as an initial step in the development process.

-1 to "experimental"... but this proposal could probably be restructured in a way that I would accept... see my counter offer.

Suggest the working group NOT provide guidance of this form in a W3C TR.

PROPOSAL: A conforming processor SHOULD raise an error if a VC utilizes the https://www.w3.org/ns/credentials/experimental/v1 JSON-LD Context in a production environment. The definition of "production environment" is left as an exercise to the implementer.

-1 to this.

Suggest the working group NOT provide guidance of this form in a W3C TR.

[msporny]

@OR13 (and anyone else that weighs in) could you please re-edit your comment above and 1) explain your -1s in more depth, and ideally, 2) provide counter-proposals for all -1s. It will help us figure out areas where it might be possible to reach consensus. Like the @vocab / "experimental" thing seems close... but the schema.org thing feels like it needs a lot more discussion (there's history there that much of the WG is probably missing).

[OR13]

edited, mostly my counter proposals are "don't say this in a W3C TR."... leave the power in the hands of the developers / system builders and users.

[dlongley]

+1 to all the proposals in #929 (comment).

[selfissued]

It’s time to let JSON be JSON

The Verifiable Credentials spec currently has conflicting guidance about the use of @context when the VC is not JSON-LD. On one hand, Section 6.1 (JSON) describes the pure JSON representation without making any requirements to use @context. On the other hand, Section 4.1 (Contexts) says “Verifiable credentials and verifiable presentations MUST include a @context property.” Later in the same section it says “Though this specification requires that a @context property be present, it is not required that the value of the @context property be processed using JSON-LD. This is to support processing using plain JSON libraries”.

Yes, it’s clear what @context means when the VC is JSON-LD. It’s also very unclear what @context means when the VC is pure JSON.

Now that we have experience with deployments of Verifiable Credentials, it’s clear that many developers don’t know how to use @context. As a result, they’ve deployed non-interoperable VCs. As Joe Andrieu said during TPAC in Vancouver, “If we didn’t have Dave Longley as a resource to help us, we wouldn’t have known how to get @context right.” Joe’s far from alone.

Proposal

Modify Section 4.1 (Contexts) to say that @context MUST be present when the VC is JSON-LD and that @context MUST NOT be present when the VC is JSON but not JSON-LD. This has multiple benefits for developers:

1. When @context is present, it’s an unmistakable indication that the VC is JSON-LD and all JSON-LD processing rules apply.
2. When @context is not present, it’s an unmistakable indication that the VC is not JSON-LD and no JSON-LD processing rules apply.
3. When @context is not present, developers do not bear the complexity burden of JSON-LD.

Answering the Issue Question

The tracking issue asked the question “What does JSON-LD compatible JSON mean?”. Given the proposal above, the answer is crystal clear: JSON-LD compatible JSON means JSON-LD; JSON that is not compliant with JSON-LD is not JSON-LD compatible JSON.

[TallTed]

@selfissued -- It's time to let @context be @context. Please edit your latest comment, and wrap all 13 occurrences of @context in code fences. That GitHub user is not part of any relevant groups, and does not need to be pinged every time a comment is made on this thread.

Also, please note that, in fact, JSON that uses URIs for all terms, thus requiring no mapping from "simple" term literals to URIs via @context, is also "JSON-LD compatible JSON". I think this "JSON-LD compatible JSON" would impose no "complexity burden of JSON-LD" (by which I think you actually mean a "complexity burden of @context") because there is no @context and no term mapping; each term URI should be interpreted and maintained exactly as written.

[nadalin]

There is absolutely no reason to have or process a “@ context” when dealing with JWTs, it requires extra work for parsers that ONLY process JSON to process the “@ context”, its time to remove this requirement and let JSON be JSON and not force these processing rules on deployments that don’t want to use JSOON-LD, lets make things simple. From: Ted Thibodeau Jr ***@***.***> Sent: Tuesday, October 4, 2022 5:22 PM To: w3c/vc-data-model ***@***.***> Cc: Anthony Nadalin ***@***.***>; Comment ***@***.***> Subject: Re: [w3c/vc-data-model] Tracking Issue from TPAC: What does JSON-LD compatible JSON mean? (Issue #929) @selfissued <https://github.com/selfissued> -- It's time to let @context be @context. Please edit your latest comment, and wrap all 13 occurrences of @context in code fences. That GitHub user is not part of any relevant groups, and does not need to be pinged every time a comment is made on this thread. Also, please note that, in fact, JSON that uses URIs for all terms, thus requiring no mapping from "simple" term literals to URIs via @context, is also "JSON-LD compatible JSON". I think this "JSON-LD compatible JSON" would impose no "complexity burden of JSON-LD" (by which I think you actually mean a "complexity burden of @context") because there is no @context and no term mapping; each term URI should be interpreted and maintained exactly as written. — Reply to this email directly, view it on GitHub <#929 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4R4Y5OQE6E7VT3K4DPQ5DWBTC2VANCNFSM6AAAAAAQNWBJHE> . You are receiving this because you commented. <https://github.com/notifications/beacon/AB4R4Y4B7IDYRWTUJKSOGJLWBTC2VA5CNFSM6AAAAAAQNWBJHGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSLSB2S4.gif> Message ID: ***@***.*** ***@***.***> >

[nadalin]

-1 to this approach From: Manu Sporny ***@***.***> Sent: Tuesday, October 4, 2022 6:49 AM To: w3c/vc-data-model ***@***.***> Cc: Anthony Nadalin ***@***.***>; Comment ***@***.***> Subject: Re: [w3c/vc-data-model] Tracking Issue from TPAC: What does JSON-compatible JSON-LD mean? (Issue #929) A cut at some language that might provide some clarity around what "JSON-LD compatible JSON" means. The Verifiable Credentials Data Model is "JSON-LD compatible JSON", which means the following: * All Verifiable Credentials expressed MUST utilize the <https://www.w3.org/TR/vc-data-model/#contexts> @context parameter where the values SHOULD be URLs. That is, in-line JSON-LD Contexts are strongly discouraged (we might even want to go as far as forbidding them). * JSON-LD Compact Form <https://www.w3.org/TR/json-ld11/#compacted-document-form> is the only allowed form of JSON-LD. JSON-LD expanded form is disallowed to eliminate the requirement to always perform JSON-LD processing in processing pipelines where its not needed. * The underlying data model is JSON-LD <https://www.w3.org/TR/json-ld11/#data-model> , which is a superset of (and round-trippable to/from) RDF. In order to make development easier for developers coming from a JSON background, we might consider: * The Verifiable Credentials specification will provide an "experimental" JSON-LD Context (https://www.w3.org/ns/credentials/experimental/v1, with an @vocab value set to https://www.w3.org/2018/credentials/undefined# such that developers need not define a JSON-LD Context or Vocabulary semantics as an initial step in the development process. * Implementations SHOULD reject verification of any VC that utilizes the https://www.w3.org/ns/credentials/experimental/v1 JSON-LD Context in a production environment. The above makes the data model crystal clear, is compatible with all known JSON-LD processors, helps developers coming from a purely JSON background to get started quickly, and retains JSON-only processing modes that are compatible with JSON-LD. Some concrete proposals that we could put in front of the group are: PROPOSAL: Verifiable Credentials MUST utilize the @context parameter where the values SHOULD be URLs. PROPOSAL: Verifiable Credentials SHOULD NOT utilize inline JSON-LD Contexts (objects as values) for the @context. PROPOSAL: Verifiable Credentials MUST be expressed in JSON-LD Compact form. PROPOSAL: The underlying data model for Verifiable Credentials is JSON-LD. And the proposals to help make development easier for developers coming from a JSON background: PROPOSAL: As an initial iteration on the idea, the Verifiable Credentials specification will define an "experimental" JSON-LD Context (https://www.w3.org/2018/credentials/experimental/v1, with an @vocab value set to https://www.w3.org/2018/credentials/undefined# such that developers need not define a JSON-LD Context or Vocabulary semantics as an initial step in the development process. PROPOSAL: A conforming processor SHOULD raise an error if a VC utilizes the https://www.w3.org/ns/credentials/experimental/v1 JSON-LD Context in a production environment. The definition of "production environment" is left as an exercise to the implementer. — Reply to this email directly, view it on GitHub <#929 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4R4Y42AMW43ADTSYEBWUDWBQYT7ANCNFSM6AAAAAAQNWBJHE> . You are receiving this because you commented. <https://github.com/notifications/beacon/AB4R4Y6PS7DGDK2A6CNMY4TWBQYT7A5CNFSM6AAAAAAQNWBJHGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSLQVNUK.gif> Message ID: ***@***.*** ***@***.***> >