Re: [EXT] Work item suggestion: VC-ACDC

I’d like to thank everyone for their feedback on the call, and for the comments and suggestions received since then.

I have notified the chairs I would like to re-propose the inclusion of vc-acdc as a work item for the group. 

We have updated the language for the proposal after input from the community:


DRAFT PROPOSAL: Adopt the W3C vc-acdc transformation specification with the acknowledgement that the underlying normative references will need to progress to Last Call in IETF Working Groups (or other equivalent) before the vc-acdc specification can progress to W3C Candidate Recommendation which would include normative references to the KERI, ACDC and CESR specifications.

 

The hope being that the proposal clarifies:
We only ask the normative statements regarding the _transformation_ be a work item for the group.
We acknowledge that the underlying technology and their specifications need to progress substantially in an official standards body, and that they are not a concern for this charter.
Non-normative/informative references in the VC DM 2.0 specification to vc-acdc would be acceptable given the caveats.
 

We feel this language reflects better the consensus reached in Miami and matches the commitment to a “big tent” approach without exploding the scope of working groups deliverables.

 

Kind regards,
Kevin Griffin
Software Developer 
kevin.griffin@gleif.org 
+1 551 223-4337 
GLEIF, 2500 Plaza 5, 25th Floor, Harborside Financial Center, Jersey City, NJ, 07311

GLEIF Americas a NJ Nonprofit Corporation 
2500 Plaza 5, 25th Floor, Harborside Financial Center, Jersey City, NJ, 07311 
Chairman of the Board: Stephan Wolf 
Managing Director: Karla McKenna 
NJ State Registration No.: 0450486330 
LEI: 2549000PPU84GM83MG36 
gleif.org 
 

 

This message may contain confidential and/or privileged information. If you are not the intended recipient or if you have received this message in error, please 
notify the sender and delete this message. Any unauthorized copying, disclosure or distribution of this message is strictly forbidden. 

 

 

From: Daniel Hardman <daniel.hardman@gmail.com>
Date: Saturday, March 4, 2023 at 5:49 AM
To: Orie Steele <orie@transmute.industries>
Cc: Drummond Reed <Drummond.Reed@gendigital.com>, Kevin Griffin <Kevin.Griffin@Gleif.org>, "public-vc-wg@w3c.org" <public-vc-wg@w3c.org>
Subject: Re: [EXT] Work item suggestion: VC-ACDC

 

I support the work item and am willing to work on it. I have a telecom use case. 

 

Since ACDCs use only simple and very widely deployed crypto, and since they are already used in production by more than one org, I don't think the bar for vetting in an external venue needs to be particularly high. However, i agree with Orie that work on them could also be done outside VCWG.

 

On Fri, Mar 3, 2023, 10:20 PM Orie Steele <orie@transmute.industries> wrote:

Data Integrity Proofs and JSON Web Tokens have been developed, tested, refined and reviewed for many, many years prior to their inclusion in the VCWG as mechanisms to secure the JSON-LD core data model.

I would prefer to see ACDCs complete, or at least advance substantially in the journey they started at IETF before being added as an official work time to the VCWG.

This approach is similar to how we have supported JWT, SD-JWT and have planned support for JWP.

The challenge with work items is getting enough contribution and expert review to raise the quality of the item to the standard that the working group would desire to publish the document.

I have concerns about how realistic that is for a work item such as ACDCs given that the current working group is struggling to even address the quality issues with the core data model, data integrity and jwt.

Are there enough experts on ACDCs who plan to contribute to the work item if it were adopted by the VCWG? 

Is Gen committed to the many hours of review and editorial work that it will take to produce a quality draft that the working group would agree to publish?

Which other organizations are going to commit the resources necessary to make this potential work item a success?

Speaking as an editor / contributor to the existing documents the working group has adopted, I cannot commit time to another security specification for the core data model, and I would prefer to not expand the scope of the current working group, based on how the current items are progressing.

That being said, the resolutions passed on day 3 of the Face to Face do not require a work item to be completed at the VCWG in order to provide a mapping to the core data model, 
nor do they require the foundational cryptography for a VC format to survive a trial by fire at IETF or elsewhere... and if there is sufficient commitment from working group members for the item, I don't see any way to block the work from being accepted per the W3C process, but I am probably less of a process expert than others on the list.

A note about the draft - https://weboftrust.github.io/vc-acdc/

"issuer.id" needs to be a valid URL / IRI... The rest of the mapping concept seems to be on track for the resolutions taken at the face to face.

Regards,

OS




 

On Fri, Mar 3, 2023 at 2:27 PM Drummond Reed <Drummond.Reed@gendigital.com> wrote:

Gen supports this new work item. The chaining capabilities of ACDCs are badly needed by certain classes of credential use cases, for example the organizational identity use cases that are the focus of GLEIF. Given that GLEIF’s LEI and vLEI (verifiable LEI) infrastructure is backed by a Regulatory Oversight Committee consisting of 65 of the world’s financial regulatory authorities, the addition of ACDC support would be an excellent addition the W3C Verifiable Credentials 2.0 family.

 

=Drummond 

 

From: Kevin Griffin <Kevin.Griffin@Gleif.org>
Date: Friday, March 3, 2023 at 10:39 AM
To: public-vc-wg@w3c.org <public-vc-wg@w3c.org>
Subject: [EXT] Work item suggestion: VC-ACDC

Hey VCWG folks,

Quick thanks (again) for the guest status in Miami, I will in future be voting for “The Pirate“ as Mayor of Miami.

Thank you chairs for giving me two minutes on the last call to introduce the prospect of a new work item.

Advance apologies if this is too much information, I know GLEIF is new to the working group so I wanted to provide some additional background.

I’d like to propose/discuss the addition of VC-ACDC (https://weboftrust.github.io/vc-acdc) to the working group. It expands on the normative description of external proofs under Section 4.7 Proofs (Signatures) alongside the embedded proof format described in VC-DATA-INTEGRITY. Currently the section on external proofs refers to the VC-JWT specification and it was used to help model VC-ACDC.

Why include an additional external proof format?

JWT discussions usually revolve around two fronts, Authorization, and Information Exchange but I think it is fair to say their application is as broad (and valuable) as the Internet is wide with many use cases and implementations.

ACDCs are not designed to compete in the same spaces that JWTs do. Rather they offer a simple yet secure method of verifiable proofs when combined with CESR for a given payload. The VC-ACDC specification details the unidirectional transformation to the VCDM base media type, and will include an informative section for bi-directional transformations, with given security caveats.

Why not just use JWTs?

A tl;dr history.
GLEIF (a non-profit) is in a unique position within the European Union being mandated to bring transparency to the financial sector. Any digital solution involving traditional DLTs would have potentially meant endorsing one blockchain for all EU financial transactions.

We opted to invest in and build out Key Event Receipt Infrastructure (KERI) and subsequent technologies (ACDC, CESR) as an alternative.

ACDCs satisfy a requirement for GLEIF that vLEIs maintain a proof-of-authorship (authenticity) of their contained data via a tree or chain of linked ACDCs (technically a directed acyclic graph (DAG)).

JSON-LD is closely associated with the VCDM (base media type credential+ld+json) and with the inclusion of VC-DATA-INTEGRITY as an embedded proof format in the specification subsequently, albeit indirectly, supports RDF/JSON-LD as a preferred connected data approach.

Inclusion of VC-ACDC results in the VCDM fostering two approaches (LPG and RDF), to connected data and we think that speaks directly to the reach and intent of the W3C.

ACDCs are a special type of container that directly normatively provides provable provenance of its payload via chaining in the form of a labeled property graph. Nested JWTs can provide a form of provenance or chaining but the semantics are non-normative. This normative provenance of a payload via a container is one of the unique properties of ACDCs.

The provenance can be used to provide a chain-of-custody of the information payload, or a chain-of-authority for an entitlement that is the type of payload, or a chain-of-authority for an authoritative attestation that is the payload.

The work is primarily authored by myself, Philip Feairheller also from GLEIF and Dr Samuel Smith (invited expert). 

My request would be (if this is the appropriate point in the process), to identify other members of this WG that would support the addition of VC-ACDC as an external proof alongside VC-JWT and help deliver the specification.

Kind regards,
Kevin Griffin
Software Developer 
kevin.griffin@gleif.org 
+1 551 223-4337 
GLEIF, 2500 Plaza 5, 25th Floor, Harborside Financial Center, Jersey City, NJ, 07311

GLEIF Americas a NJ Nonprofit Corporation 
2500 Plaza 5, 25th Floor, Harborside Financial Center, Jersey City, NJ, 07311 
Chairman of the Board: Stephan Wolf 
Managing Director: Karla McKenna 
NJ State Registration No.: 0450486330 
LEI: 2549000PPU84GM83MG36 
gleif.org 
 

 

This message may contain confidential and/or privileged information. If you are not the intended recipient or if you have received this message in error, please 
notify the sender and delete this message. Any unauthorized copying, disclosure or distribution of this message is strictly forbidden. 

 


 

-- 

ORIE STEELE 

Chief Technical Officer

www.transmute.industries