RE: Outcome of 2023 Miami Verifiable Credentials WG Meeting

Hi,

Below is the actual text that the WG reached consensus on during the F2F:

RESOLVED:

  1.  The base media type for the VCDM is credential+ld+json. @context is required (MUST) in the base media type;
  2.  other media types MAY choose to include @context.
  3.  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.

It is a direction that the WG agreed to work towards and a lot will depend on the concrete text that goes into the specification. For example, we did not discuss in depth or pass any resolution regarding "parameterizing the proof type".

Best,
Kristina

From: Joe Andrieu <joe@andrieu.net>
Sent: Tuesday, February 21, 2023 9:55 AM
To: Credentials Community Group <public-credentials@w3.org>
Subject: Re: Outcome of 2023 Miami Verifiable Credentials WG Meeting

You don't often get email from joe@andrieu.net<mailto:joe@andrieu.net>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Thanks, Manu.

Just a few additional notes (one of which I shared on the CCG call today)

On Sat, Feb 18, 2023, at 7:54 AM, Manu Sporny wrote:
* There will be ONE base media type for a credential:
application/credential+ld+json.

It's not clear that this is a "credential". There's some semantic debate about whether the base media type of the VCWG is *secured* or *securable*. This is a quagmire of definitions as we currently define a credential as not secured. But the notion of the base media type for the VCWG suggests to me that application/credential+ld+json is the base media type for all Verifiable Credentials.

FWIW, I think there's some challenging nuance to tease out here and I don't think we had clear guidance from our conversation.

* There might be more than one content type for verifiable credentials
such as application/vc+ld+json, application/vc+jwt,
application/vc+SOME_SECURING_MECHANISM, OR

* We might parameterize the proof type so we can reduce the number of
media types like so: application/vc;proof=jwt|di|acdc|gordian (instead
of application/vc+jwt).

I was surprised to see that the base of these media types were not the base media type as resolved by the group. This is almost certainly because "base media type" was not formally defined.

My understanding led to an expectation that the VCWG might register a parameterized form of the base media type,
application/credential+ld+json; proof=di
application/credential+ld+json; proof=jwt
application/credential+ld+json; proof=none
.
(It's not clear if the shift to application/vc was important in your note or if you effectively meant the same thing).
It might be smarter to have a base media type of application/vc+ld+json. That would save some bytes. But it would require adjusting the informal term definition of credential and verifiable credential.

...
Other VC Securing Mechanisms
-------------------------------------------

* In order to make an attempt at a "big tent" approach, other securing
mechanisms can say that they are "verifiable credentials" if there is
a transformation mechanism defined to map the values back to
application/credential+ld+json. This opens the door to ACDC, Gordian
Envelope, and pure binary formats that have data payloads that secure
information that, after transformation, can be represented in the
Verifiable Credentials Data Model.

This framing surprised me and I would push back against the literal language here.

The VCWG's resolutions were only taken with regard to media types defined by the VCWG. The flexibility of a base media type combined with proof mechanisms to secure that base media in no way restricts or blesses what other organizations might create or produce. It certainly does NOT open the door for TOIP or DIF or anyone else to define W3C Verifiable Credentials as anything other than what is in the VCDM.

There **is** a nuance in the approach that enables other organizations to define the transformation rules for a particular proof profile. That is, the VCWG could bless any media types that transform to the VCDM, even if the transformation from those media types is defined by an outside organization.

For consensus-based interoperability, it is vital that anything that is called a W3C Verifiable Credential has been vetted and approved to W3C's consensus and IPR process.

This gives us a route to adopting any number of integrity mechanisms, but it does not mean that media types of a particular pattern, e.g., application/credential+ld+json; proof=XYZ, are by definition Verifiable Credentials.

The definition of a Verifiable Credential is the set of normative requirements defined in the W3C Verifiable Credentials Data Model. This was, IMO, one of the key points of the face to face meeting. The definition of what is a VC is the set of normative requirements in the W3C VC Data Model specification itself.

-j

--
Joe Andrieu, PMP
joe@andrieu.net<mailto:joe@andrieu.net>
+1(805)705-8651
http://blog.joeandrieu.com