Re: Outcome of 2023 Miami Verifiable Credentials WG Meeting

On Tue, Feb 21, 2023 at 5:09 PM Kristina Yasuda <
Kristina.Yasuda@microsoft.com> wrote:

> 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.
>       1. Another media type MUST identify if this transformation is
>       one-directional or bi-directional.
>       2. Bi-directional transformation MUST preserve @context.
>       3. 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”.
>
> >>> Although not formally announced yet, on March 8th I will be hosting a
> mathematician specializing in data transformations with the DIF Interop WG.
> I will run this by him.
>
>
>
> 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. 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
>
> +1(805)705-8651
>
> http://blog.joeandrieu.com
>
>
>