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

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 <https://www.leiroc.org/index.htm> 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  <kevin.griffin@gleif.org>
> +1 551 223-4337  <+15512234337>
> GLEIF, 2500 Plaza 5, 25th Floor, Harborside Financial Center,
> Jersey City, NJ, 07311
>
> [image: GLEIF || Enabling global identity | Protecting digital trust]
> <https://gleif.org/>
>
> *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  <https://gleif.org>*
>
> [image: youtube]
> <https://www.youtube.com/channel/UCP2xdWOFG7dWNaFIBKyejhg>
>
> [image: twitter] <https://twitter.com/GLEIF>
>
> [image: linkedin]
> <https://www.linkedin.com/company/global-legal-entity-identifier-foundation-gleif-?trk=biz-companies-cym>
>
> [image: Blog] <https://www.gleif.org/en/newsroom/blog>
>
> [image: Newsletters]
> <https://www.gleif.org/en/newsroom/gleif-and-lei-news/subscribe-to-gleif-newsletter>
>
>
>
>
>
> 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

<https://www.transmute.industries>