Re: Chairs' decision on VC-ACDC Proposal

On Wed, Mar 22, 2023 at 9:48 AM Personal Sam Smith <sam@samuelsmith.org>
wrote:

> > On Mar 22, 2023, at 10:31, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
> >
> > On Wed, Mar 22, 2023 at 11:15 AM Mike Jones wrote:
> >> The ACDC proponents can still define a mapping per the resolution that
> makes ACDCs VCs.
> >
> > "ACDC VCs" is the sort of vagueness that is probably going to get the
> > group into trouble. :)
> >
> > Per the resolution at the Miami F2F, the ACDC proponents can define a
> > mapping, through any process that they see fit, and publish it
> > anywhere on the Internet,  that converts an ACDC into an
> > `application/vc+ld+json` media type serialization that can then only
> > be called a "Verifiable Credential" if it conforms to the normative
> > rules in the VCDM. The same goes for JWTs, Gordian Enveloped, and Data
> > Integrity protected content.
>
> This was not the resolution.


> > We really need to clarify the above, because if we don't have
> > alignment on it, we'll continue to see  "strange PRs" raised in these
> > specifications (because we're not all on the same page about the
> > above) and, even worse, specifications defined outside of the VCWG
> > that call themselves "VCs", while not conforming to a variety of
> > statements in the VCDM.
>
> Yes, we do.

People are reading into the resolution a commitment that is absolutely NOT
in the words of the resolution, and those words matter.

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.

At no point did we make any commitment to recognizing any work done outside
the VCWG as "Verifiable Credentials".

I believe these are the foundational truths, today:

   1. What is or is not a VC is defined by the VCDM in the W3C VC Data
   Model Specification.
   2. The VCWG (and by extension the W3C) is the only organization that has
   the authority to change that specification, and hence to change the VCDM.
   3. At no point should it be construed that organizations other than the
   W3C have the authority to change the VCDM.

HOWEVER, what we did say is that any group can propose as VCWG work items
additional media types (beyond the base) if, and only if, those media types
map to the base media type.

This is the route that vc-jwt is already following and it serves as the
best route, imo, for other representations to receive the blessing of the
VCWG. Given time constraints, we simply won't be able to absorb all such
potential proposals, but there exists a reasonable path to any given
technology to earn the brand name "W3C Verifiable Credential".

IMO, if vc-acdc were standards ready, it would be a great candidate as a
work item for the VCWG. The primary problem is that it appears to depend on
external specifications that may settle in time relative to the WG expiry
and it is not clear that we have enough person-hours available within the
group to properly review the work.

At no point did we say that media types defined by other organizations are
going to be VCs. In fact, they can't be unless they literally present the
same media type. They will be another serialization that happens to have a
mapping to application/vc+ld+json. They certainly won't be using that media
type, which I think is the whole point of this debate, as it was the point
of the resolution.

What comes over the wire *as a VC* MUST have a standard representation that
is conformant with the VCDM, including such media types as may be
registered by the VCWG. I don't have a problem calling vc-jwts VCs if the
WG succeeds in publishing that specification (as I think it will). Other
digital artifacts defined by other organizatoins can be sent over the wire
and may be transformable into VCs, but what is going over the wire is not,
itself a VC unless it is of a media type that is either directly conformant
with the VCDM or blessed by the VCWG in the form of registering a new
mappable media type with IANA.

The fundamental here is that the VCWG has the final authority to decide if
particular properties or approaches are aligned with the specific approach
of Verifiable Credentials as defined within its own specification. It does
not make sense to allow third party organizations to define arbitrary
objects with unvetted features and properties and declare them VCs,
regardless of how it might map to any particular media type. It would
reduce the meaning of having a specification to nil. That's not
standardization, that's a free-for-all. We resolve that free-for-all by
embracing third party tech as potential work items, just like we did for
vc-jwt.


-j