Media types other than vc+ld+json

[m00sey]

Coming out of a series of related issues:

#1048
w3c/vc-extensions#14
w3c/vc-jose-cose#73

The hope is to continue the discussion the discussion to arrive at consensus for transformations/other media types.

---

Preview | Diff

[TallTed]

This seems to define Unidirectional, rather than Bidirectional.

[m00sey]

I feel this is resolved.

[TallTed]

I think this will be much clearer to the reader if the paragraph breaks in this HTML source are preserved for final rendering, so this should get a few more instances of </p><p>.

[m00sey]

@TallTed thanks, I have updated the formatting.

[msporny]

+1 to this PR for the following reasons:

• It starts to establish what is expected from the "transformation" rules in media type specifications (demonstrate interop).
• It's aligned w/ the direction we seem to be going in for reserved extension points, which might be a good signal.
• It's how we approached "rules" for DID Methods, which have been rules that we've been able to consistently apply (more or less) across DID Method registrations. I am a bit concerned that the media types section might need to be policed (because of these rules), but I don't expect we'll end up with over 150 media types (as we did for DID Methods).

With that, a few change requests:

• @TallTed's paragraph suggestions should be applied.
• I've also tried to align the language with the specification text, but there might be other variations that are better.

+1 to merge after that.

[selfissued]

The statement about testing is ambiguous.

[selfissued]

It's ambiguous what you're saying should be testable. Is it the transformed representation that is tested (in which case a VC Data Model test suite could be used). Or are you also asking for testing of the additional media type representation?

[selfissued]

It's also not clear to me what the "MUST result" language means. The day 3 resolution says that a transformation must exist. It doesn't say that particular deployments must use transformations.

[OR13]

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

Informative reference, followed by a MUST feels a bit off here.

If this is guidance to the registry maintainers, to gate entries I think this goes against our intention to keep the "vc specs directory", lightweight and not a registry.

This sentence also goes beyond the day 3 resolution, which only required this level of rigor for representations defined by this working group, but this would apply to all registered entries in the informative note.

[m00sey]

It's ambiguous what you're saying should be testable. Is it the transformed representation that is tested (in which case a VC Data Model test suite could be used). Or are you also asking for testing of the additional media type representation?

The transformed representation should be testable against the VC Data Model test suite, yes.

[OR13]

This is not testable, and the details matter regarding claims of "losslessness".

CBOR-LD conversions destroy field ordering, and can have weird interactions with date formats... It would probably be better to leave the details regarding what "bidirectional mapping" means, to the spec that defines it.

[decentralgabe]

agree, without an example of how this could be tested we should remove it

[OR13]

I feel pretty strongly about reworking the phrasing of the first sentences.

And I think #1100

Is a better approach to start with.

I don't think the normative guidance regarding testing is acceptable, in any format.

Resolution #1: The base media type for the VCDM is credential+ld+json. @context is required (MUST) in the base media type; other media types MAY choose to include @context. 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 @context. Transformation rules MUST be defined, but not necessarily by this WG..

• https://www.w3.org/2017/vc/WG/Meetings/Minutes/2023-02-16-vcwg#resolution1

Resolution #2: VC spec directory will have an entry for documents that define a mapping to VCDM and these documents can be defined outside W3C VCWG..

• https://www.w3.org/2017/vc/WG/Meetings/Minutes/2023-03-15-vcwg#resolution2

If the core data model is testable, a mapped representation is testable.

Serializations in other media types (defined by the VCWG) MUST be able to be transformed into the base media type.

If you want to test this ^ you will need to apply the core data model test to the result of the mapping.

If those tests pass, your mapping is conformant.

This is why the resolution ends with:

Transformation rules MUST be defined, but not necessarily by this WG..

I buy the argument about normative tests, if the "vc specs directory" is a "formal registry" and "vc+" media types was a recognized extension point for verifiable credentials, but then this section of our charter would apply:

"Registries for extension points that are mandatory to use, for any of the above normative deliverables [], must have at least one standardized entry."

Are media types an extension point?

Are they mandatory to use?

Answers to these questions and clarity on the normative requirements of the vc specs directory would help make our options here a bit clearer.

I'm not objecting to the spirit of the PR, but I find the new language adds more questions than it answers, I feel it is not necessary to address #1048

[m00sey]

I don't think the normative guidance regarding testing is acceptable, in any format.

The intent is to provide implementers at least a modicum of direction with regard to additional representations once the spec is published and the WG moves on.

It is meant in the same spirit of the DID Core spec regarding methods:
https://www.w3.org/TR/did-core/#methods

I think it is important guidance.

[awoie]

The language on conformance testing is not clear and i'd personally prefer having no conformance test suite required in the W3C test suite repo.

[awoie]

I would rather not have that requirement.

• Does it mean we must have tests in the W3C Test Suite repo?
• Or is it ok if the conformance tests are somewhere else?
• What should those tests test, ie input file in the media type and then spitting out a JSON-LD VC?

[m00sey]

What should those tests test, ie input file in the media type and then spitting out a JSON-LD VC?

Yes, that would at least point to some interop potential.
Every media type can at least "get to" the base media type.

Conceptually, the relationship between this (VCDM2.0) specification and a Media Type Representation specification (VC-JWT/Gordian/ACDC/Any) is similar to the relationship between DID-Core and a specific DID Method specification.

By defining a Media Type section we acknowledge there will be other media types wanting to be consumed as VCs, we should be defining a minimal number of steps/spec/transform that allows someone to produce something of the base media type and know it's going to be interoperable with others.

Happy to rework the language if its too constrained

[Sakurann]

Prefer #1101. VCDM is not a place to put any requirements for "anything" that is in the [VC-SPECS] which I think is the directory we have

[jandrieu]

VCDM is not a place to put any requirements for "anything" that is in the [VC-SPECS] which I think is the directory we have

Agreed. The directory only has the requirement that the editors agree that the entry is "related". There are no other requirements to be in the directory other than using the appropriate JSON and that requirement is in the directory itself.

No need to say anything in the VCDM.

[iherman]

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

• no resolutions were taken

View the transcript

1.1. Media types other than vc+ld+json (pr vc-data-model#1100)

See github pull request vc-data-model#1100.

Dave Longley: We are missing key players to discuss today. Probably should not discuss today.

Orie Steele: +1 people are not here.

Brent Zundel: Agreed we are missing key players, moving on.
… beginning the HR process. Preparing documents to engage other groups.

Ted Thibodeau Jr.: I don't know why those key players are absent today, but I might suggest including mention of these PRs in the next agenda, so there's advance warning that they will be discussed (and so encouraging those folks to prioritize attendance)?

[iherman]

The issue was discussed in a meeting on 2023-07-11

• no resolutions were taken

View the transcript

1.1. Media types other than vc+ld+json (pr vc-data-model#1100)

See github pull request vc-data-model#1100.

Brent Zundel: this first one is media types + ld + json.
… buidling on some of the miami resolutions. Four requests for changes currently.
… how can we move this P.R forward?

Phil Feairheller: kevin opened this P.R. Seems this P.R will not be able to move forward. No objections to closing.

Orie Steele: +1 PhilF.

Brent Zundel: and objections to marking pending close?
… no objections, labelling pending close. Will close in 7 days if no objections.

[brentzundel]

No clear path to consensus, no objections raised to closing since marked pending close, closing.