Re: Outcome of 2023 Miami Verifiable Credentials WG Meeting

Other details or misinterpretations aside, this is a super helpful summary, Manu.

Thank you for consistently keeping the broader community and shared context front of mind.

Taylor Kendal
www.learningeconomy.io<http://www.learningeconomy.io>
<http://www.learningeconomy.io>
www.ethdenver.com<https://www.ethdenver.com>
________________________________
From: Manu Sporny <msporny@digitalbazaar.com>
Sent: Saturday, February 18, 2023 8:57 AM
To: W3C Credentials CG <public-credentials@w3.org>
Subject: Outcome of 2023 Miami Verifiable Credentials WG Meeting

Hey all,

I thought it might be useful to summarize the outcomes from the VCWG
meeting during this past week. Others that were there should feel free
to chime in as some resolutions could be interpreted differently based
on one's world view:

Content Types
-------------------

* There will be ONE base media type for a credential:
application/credential+ld+json.

* The base media type will be in JSON-LD format and @context is mandatory.

* 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).

* A verifiable credential DOES NOT need to include @context but MUST
be able to provide a transformation that can get back to
application/credential+ld+json. This was the biggest outcome of the
F2F and makes an attempt at a "big tent" approach without going down
the slippery slope of defining an abstract data model (as we did in
the DID WG).

Holder Binding
--------------------

* There was consensus that "Holder Binding" was the wrong terminology
and the group does not want to use it going forward. There seemed to
be consensus forming around the term "assurance" plus another word
like "identity assurance" or "assurance method"... further
bikeshedding will be done on this terminology.

* For use cases where the issuer would like to convey the mechanism
that it used to perform identity proofing, the `evidence` field could
be used. Expressing statements like: "I checked a passport that had
these fields and a photo against the individual standing in front of
me, in person, before I issued this credential" seemed like a bad fit
for`credentialSubject`, but a good fit for `evidence`.

* For use cases where the issuer would like to shift liability or
constrain what the verifier does, such as "If you don't check the
individual's passport before you accept this VC, then you accept all
liability" were identified as problematic to support as we'd need a
lot of input from legal counsel and there were doubts that the sort of
liability shifting some were expecting was possible.

* There will be a concrete pull request offered based on the
discussions at the F2F.

Data Integrity Securing Mechanisms
------------------------------------------------

* The jws-2020 specification has been abandoned in favor of using VC-JWT.

* The existing VC Data Integrity spec will be expanded to include JSON
Canonicalization Scheme as an alternative canonicalization mechanism
to the Universal RDF Dataset Canonicalization Algorithm. The first
canonicalizes pure JSON (not syntax agnostic, locked to JSON), the
second canonicalizes the information model to RDF (syntax agnostic,
but at the expense of more complexity).

* The EdDSA Cryptosuite will continue on it's current global standard
trajectory.

* The need for an ECDSA Data Integrity Cryptosuite to meet
governmental use cases that require the use of hardware security
modules is now more pressing, though the charter enables us to pull
the CCG work item in on this and it is a simple variation of the EdDSA
Cryptosuite. There didn't seem to be objections to doing so as long as
we can do this before the group closes the door on feature freeze.

* The group will continue to hold the door open for the BBS Data
Integrity Cryptography suite.

JOSE-based Securing Mechanisms
------------------------------------------------

* There will be a breaking change between VC-JWT v1.1 and VC-JWT v2.0,
but the ability to identify a VC-JWT v1.1 from future versions of
VC-JWT via the use of media types.

* VC-JWT v2.0 will utilize a better encapsulating mechanism where the
outer envelope used for security the VC (the JWT) will specify it's
inner payload content type, which will be
application/credential+ld+json. This approach follows practices used
in other WGs at IETF.

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 decision took more than a full day of debate and resulted in
the resolution of the "Make @context optional" and "big tent"
megathread (290+ comments) by opening up the aperture that allows
@context to not be used in a VC as long as @context can be
reconstituted in a way that is compatible, and ideally without losing
important semantics, with the Verifiable Credentials data model. There
was concern that this mechanism might be abused, so the WG will be
monitoring how this mechanism is used throughout the standardization
process.

Registries vs. Directories
---------------------------------

* There seems to be increasing opposition for the WG to maintain a
registry for the VC ecosystem based on our experiences with the DID
Specification Registries.

* An alternative proposal to provide a Verifiable Credential
Specifications Directory that points to other known work in the space,
such as extensions to proofs, schemas, evidence, terms of use, etc.
did not seem to have opposition. This will allow us to point to work
happening in places like the CCG, DIF, ToIP, IETF, ACDC, W3C, and
weekend projects performed by individuals. A PR will be raised shortly
to create such a directory. The difference between a directory and a
registry is that the former puts less decision making authority with
the DID WG on whether or not an entry should be included.

Hope that helps and is a fair summary of the outcomes. I'm sure I
missed some important stuff or misinterpreted some details here or
there, so others that were present should jump in and correct things
as they see fit.

-- manu

--
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/