Guidance on application/ld+json

[OR13]

We should beware of the existing behavior for ld+json and comment on if this media type is acceptable for credential+ld+json and verifiable-credential+ld+json

We had a similar challenge with did+json, did+ld+json and the default behavior for did.json in DID Web.

We should anticipate developers lagging behind adopting support for new media types.

[OR13]

I suggest we say that developers can do the following:

<script type="application/vc+ld+jwt">
eyJhbGciOiJFUzI1NiIsImlzcyI6ImRpZDpleGFtcGxlOjEyMyIsImtpZCI6IiMwIiwidHlwIjoidmMrbGQrand0IiwiY3R5IjoidmMrbGQranNvbiJ9.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3czaWQub3JnL3ZjL3N0YXR1cy1saXN0LzIwMjEvdjEiXSwiaWQiOiJodHRwczovL3ZlbmRvci5leGFtcGxlL2NyZWRlbnRpYWxzL3N0YXR1cy8zIiwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCIsIlN0YXR1c0xpc3QyMDIxQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJkaWQ6ZXhhbXBsZToxMjMiLCJ2YWxpZEZyb20iOiIyMDIxLTA0LTA1VDE0OjI3OjQwLjAwMFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6Imh0dHBzOi8vdmVuZG9yLmV4YW1wbGUvY3JlZGVudGlhbHMvc3RhdHVzLzMjbGlzdCIsInR5cGUiOiJTdGF0dXNMaXN0MjAyMSIsInN0YXR1c1B1cnBvc2UiOiJzdXNwZW5zaW9uIiwiZW5jb2RlZExpc3QiOiJINHNJQUFBQUFBQUFBMk1BQUkzdkF0SUJBQUFBIn19.eRnHulruzCNFAD4n3PlAkn7hPouynDvMZxmID8bP0hXCZN3_CswKyIOFSyndpD6EhJfET7j5vVEuVrZXnnC_2A
</script>
<script type="application/vc+ld+json">
{JSON.stringify(
  {
    '@context': [
      'https://www.w3.org/ns/credentials/v2',
      'https://w3id.org/vc/status-list/2021/v1',
    ],
    id: 'https://vendor.example/credentials/status/3',
    type: ['VerifiableCredential', 'StatusList2021Credential'],
    issuer: 'did:example:123',
    validFrom: '2021-04-05T14:27:40.000Z',
    credentialSubject: {
      id: 'https://vendor.example/credentials/status/3#list',
      type: 'StatusList2021',
      statusPurpose: 'suspension',
      encodedList: 'H4sIAAAAAAAAA2MAAI3vAtIBAAAA',
    },
  },
  null,
  2,
)}
</script>
<!-- VCs can use existing media types for JSON-LD -->
<script type="application/ld+json">
{JSON.stringify(
  {
    '@context': [
      'https://www.w3.org/ns/credentials/v2',
      'https://w3id.org/vc/status-list/2021/v1',
    ],
    id: 'https://vendor.example/credentials/status/3',
    type: ['VerifiableCredential', 'StatusList2021Credential'],
    issuer: 'did:example:123',
    validFrom: '2021-04-05T14:27:40.000Z',
    credentialSubject: {
      id: 'https://vendor.example/credentials/status/3#list',
      type: 'StatusList2021',
      statusPurpose: 'suspension',
      encodedList: 'H4sIAAAAAAAAA2MAAI3vAtIBAAAA',
    },
  },
  null,
  2,
)}
</script>
<!-- Example from https://schema.org/EducationalOccupationalCredential -->
<script type="application/ld+json">
{JSON.stringify(
  {
    '@context': 'https://schema.org',
    '@type': ['EducationalOccupationalCredential'],
    name: 'Certified Safety Professional',
    url: 'https://www.bcsp.org/CSP',
    description: `Certified Safety Professionals (CSP) are persons who 
perform at least 50% of professional level safety duties, 
including making worksite assessments to determine risks, 
assessing potential hazards and controls, 
evaluating risks and hazard control measures, 
investigating incidents, 
maintaining and evaluating incident and loss records, 
and preparing emergency response plans.`,
    credentialCategory: {
      '@type': 'DefinedTerm',
      '@id': 'http://purl.org/ctdl/terms/Certification',
      name: 'Certification',
      inDefinedTermSet: {
        '@type': 'DefinedTermSet',
        '@id': 'http://purl.org/ctdl/terms/',
        name: 'Credential Transparency Description Language',
      },
    },
  },
  null,
  2,
)}
</script>

[brentzundel]

I am not clever enough to understand what you are saying with the above code block and would appreciate if you could dumb it down for me.

[melvincarvalho]

I'd like to share an observation regarding the media type used here:

<script type="application/vc+ld+json">

Wouldn't it have been more intuitive and developer-friendly, easier to search, match regex, had standards developed in this way:

• application/json
• application/json+ld
• application/json+ld+did

Or even:

• json/ld
• json/ld+did

The use of "application/vc+ld+json" seems unconventional, even to someone experienced in standards. In general, developers tend to be more at ease with "application/ld+json." I recommend using that format if feasible.

This is merely an observation. Who knows, maybe the json/ld MIME type will gain traction in the future.

[OR13]

@melvincarvalho I suggest you send your comments regarding structured suffixes to IETF, before it is too late :)

IANA is not going to let us register any of these, unless IETF explains how to process them, and that is not going super well atm... which makes taking a dependency on multiple + media types... not advisable.

[OR13]

@brentzundel these script tags are processed by search engines as they crawl web pages... those engines are very unlikely to do anything with stuff that is not application/ld+json.

See:

• https://moz.com/blog/json-ld-for-beginners
• https://schema.org/docs/datamodel.html

[TallTed]

send your comments regarding structured suffixes to IETF, before it is too late

It is already too late. IANA long ago set media types to specialize inside-out.

Top level is application.
Second level is /json, making application/json.
Third level (first +) is ld+, making application/ld+json.
Fourth level (second +) is vc+, making application/vc+ld+json.

The hard lift for us right now is the last — the fourth — of the above, as we are the first to push hard on having two + because we want a specialization of application/ld+json, that being application/vc+ld+json.

[OR13]

Related open PR: w3c/json-ld-syntax#415

[iherman]

The issue was discussed in a meeting on 2023-06-28

• no resolutions were taken

View the transcript

2.6. Guidance on application/ld+json (issue vc-data-model#1040)

See github issue vc-data-model#1040.

Brent Zundel: #1040 next - Guidance on applications on application/ld+json.

Manu Sporny: will do this one, dup of another.

[msporny]

PR #1189 has been raised to address this issue. This issue will be closed once that PR has been merged.

[msporny]

PR #1189 has been merged, closing.