Re: Outcome of 2023 Miami Verifiable Credentials WG Meeting

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
+1(805)705-8651
http://blog.joeandrieu.com