Re: Outcome of 2023 Miami Verifiable Credentials WG Meeting

I find the term "Identity Assurance" quite interesting. I've come across IDQA (Identity Quality Assurance) which uses eight metrics to attache a score to an identity credential. The metrics used are: 



- Protects personal assets?

- Rigor of enrollment methods

- Quality of Asserion

- Quality of Attesting Authority

- Quality of Other Attestations

- Quality of Protection of the PEN

- Assumption of Liability

- Track Record of Credential 



Each of the metrics are scored on a scale of 0-9 and an overall score is attached to the identity credential. 








Dan Kioria 








---- On Sat, 18 Feb 2023 18:54:08 +0300 Manu Sporny <msporny@digitalbazaar.com> wrote ---



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/