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

mesur.io will continue to firmly object until this work item points to and
references work that is standardized at a TR or RFC or equivalent level.

Has something changed to where the work is moving towards that level?  I
would recommend incubation of the work elsewhere until there is a clear
path to standardization.


Mike Prorock
mesur.io

On Mon, Mar 13, 2023, 13:39 Kevin Griffin <Kevin.Griffin@gleif.org> wrote:

> 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  <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.
>
>
>
>
>
> *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 <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
>
>
>
> [image: Image removed by sender.] <https://www.transmute.industries/>
>
>