Media types other than vc+ld+json

[Sakurann]

Out of the direction that was resolved during F2F, few things needs further clarification and PRs:

• The base media type for the VCDM is vc+ld+json. (Already in VCDM text)
• [at]context is required (MUST) in the base media type; (already in VCDM text)
• other media types MAY choose to include [at]context. (Needs PR)
• Serializations in other media types (defined by the VCWG) MUST be able to be transformed into the base media type. Another media type MUST identify if this transformation is one-directional or bi-directional. Bi-directional transformation MUST preserve [at]context. Transformation rules MUST be defined, but not necessarily by this WG. (Needs PR)

This issue can be broken down in multiple. Its purpose is to document next steps.

[m00sey]

@msporny do you think we can get started with then following wording within the https://w3c.github.io/vc-data-model/#media-types section?

Additional `application/vc+` media type transformation specifications can be 
defined to provide implementers with further options for producing objects 
compliant with the base media type.

Specifications are registered with the [[?VC-SPECS-DIR]] and
MUST result in a serialization
that is objectively testable via a test suite.

Transformations from other media types MUST state the directionality of the 
transformation from the options:

- Unidirectional
- Bidirectional

Bidirectional transformations MUST preserve the <code>@context</code> of the verifiable credential.

I think there is going to cross references from the vc-specs-dir where we can reference requirements such as " "demonstrably interoperable between at least two implementations" with the "how to add a specification" section.

[OR13]

This ticket is pretty stale.

We have requested registration of vc+ld+json.

other media types MAY choose to include [at]context. (Needs PR)

We don't need a PR for this in this repository, it is handled in the place where the mapping is defined... as it is required to satisfy the mapping, and each mapping might choose to be "smarter" when it comes to this... for example, JOSE might reference registry terms directly in JSON-LD... but not all JOSE mappings might care to support that.

Serializations in other media types (defined by the VCWG) MUST be able to be transformed into the base media type. Another media type MUST identify if this transformation is one-directional or bi-directional. Bi-directional transformation MUST preserve [at]context. Transformation rules MUST be defined, but not necessarily by this WG. (Needs PR)

The original intention of that text was to guide the working group, not recommend specific PR text.

I don't think we should raise a PR in the core data model for this, instead, any securing specification can simply define the mapping needed, and register it in vc specs directory.

I think a lighter touch will work for this, we add a PR to the vc specs directory on registering a new media type, and in that PR we comment on advising the registrant how to fill in the description, and refer to their spec.

Then we have their spec do all the hard work, and we don't add extraneous bloat to the core data model TR.

There is no sense adding a bunch of details about media types defined elsewhere, to the core spec which only defines 1 or maybe 2 media types.

If the goal is to attempt to add normative language to the core data model about mappings, I suspect that will not go well.

I suggest we split this issue up:

1. open an issue for changes to the vc data model media types section, including the proposal from Media types other than vc+ld+json #1048 (comment)
2. open an issue for the changes to the vc specs directory related to thread on Add "Media Type Extensions" category. vc-extensions#14
3. open an issue for the remaining items in the description
4. close this issue, and continue discussion on the more focused issues.

[m00sey]

Is the path forward that there should be no intention for anyone with an alternative transformation/format to be recognized by this W3C VCDM standard?

If the answer to this is yes, how can the working group believe that all use cases that will use W3C compliant verifiable credentials can be satisfied by credentials that comply with a single transformation to the base data model?

How can a recognized leader in this area of standards work address the needs of user communities that have additional requirements, such as for security, to be recognized as compliant with the standard?

Implementers need to know that their needs can be satisfied by the first and definitive standard for verifiable credentials which can adapt to both the continuing and changing needs of the user communities.

By including guiding language regarding transformations in the version that is within the scope of this working group, the working group can clear the path for the verifiable credential specification to support continuing and changing needs while not adding work to the remit of this working group.

[msporny]

@m00sey wrote:

@msporny do you think we can get started with then following wording within the https://w3c.github.io/vc-data-model/#media-types section?

Yes, I think this establishes good guidance for those that want to say that they have technologies that are compatible with the VCDM and can be mapped to/from the VCDM. Some additional thoughts on the language you're proposing:

Additional application/vc+ media type transformation specifications can be
defined to provide implementers with further options for producing objects
compliant with the base media type.

+1

Specifications are registered with the [[?VC-SPECS-DIR]] and
MUST result in a serialization
that is objectively testable via a test suite.

+1 (to the concept of defining something that's objectively testable).

The W3C standards track has a bar that states that you must demonstrate at least two independently written, interoperable implementations to have a global standard. I'd personally like us to hit that bar, though I expect others in the WG might disagree. If the goal here is to truly demonstrate objectively testable interop, there are a few things we COULD agree to (and then write spec text around it):

1. The transformation algorithm that goes from format X to application/vc+ld+json needs to be written down somewhere in a stable reference (a document published to the Web that is stable and expected to stick around for the forseeable future).
2. A test suite that is capable of testing the transformation algorithm defined in the previous step against implementations such that it can be objectively demonstrated that the transformation algorithm is implementable.
3. A conforming document test that demonstrates that the output of the transformation algorithm is a valid expression of the VCDM in the base media type.

There are people in the WG that are currently asserting that we should only do 3. I'm personally asserting that we should do 1 and 2, in addition to 3, to ensure that we actually get interop.

Transformations from other media types MUST state the directionality of the
transformation from the options:

• Unidirectional
• Bidirectional

+1

Bidirectional transformations MUST preserve the @context of the verifiable credential.

+1 (with a caveat that we might need to change the language slightly). I'll note that the conforming document definition in the spec will 1) probably have to change, and 2) might be useful wrt. the type of language we want to use for bidirectional transforms. That is, we might not say anything about @context and just say something to the effect of "you have to be able to round-trip the document in a way that results in no data loss". That is, use a more general statement instead of calling out @context explicitly.

I think there is going to cross references from the vc-specs-dir where we can reference requirements such as " "demonstrably interoperable between at least two implementations" with the "how to add a specification" section.

+1

[jandrieu]

This language seems to be an overreach:

Specifications are registered with the [[?VC-SPECS-DIR]] and
MUST result in a serialization
that is objectively testable via a test suite.

The point of the directory of related specs is to list any specs that are related. That should be the only criteria for inclusion. Adding additional criteria puts the directory more in the role of an "official registry" than an informational directory.

[iherman]

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

• no resolutions were taken

View the transcript

2.1. Media types other than vc+ld+json (issue vc-data-model#1048)

See github issue vc-data-model#1048.

Brent Zundel: starting with issue #1048.

Manu Sporny: Pre-CR ready for PR, on his plate and he'll do it.