ACDC (Authentic Chained Data Containers) in VC DM 2.0

[SmithSamuelM]

This is an issue to begin the discussion of how ACDCs might be acceptable as a compliant variant of VDDM 2.0.

For reference the current specification for ACDCs may be found here ACDC Spec

For those who are unfamiliar with ACDCs, these are a variant of the concept of a verifiable credential incubated at the ToIP Foundation. ACDCs have some innovative features such as normative support for chaining credentials, use of property graphs as the abstract data model, contractually protected disclosure, graduated disclosure, Ricardian contracts, simple selective disclosure, and unlinkability via hashes and bulk issued credentials, reliance on KERI, CESR and related specs from the KERI stack. see here KERI.

The first major adoption vector for ACDCs is the GLEIF vLEI. vLEI

The GLEIF vLEI provides a global cross-jurisdiction verifiable root-of-trust for the ISO standard LEI (Legal Entity Identifier). see LEI.

The KERI/ACDC stack is a modern take on the legacy concept of a web-of-trust based on PKI based DKMI (decentralized key managment infrastructure). It is fully decentralized in that it is based on independent verifiable data structures that provide the proofs of key state for each identifier. It does not require (but may leverage) shared distributed ledgers.

KERI solves the hard problem of PKI, that is secure verifiable key rotation, using something called key pre-rotation. This supports delegation and custodial key management among other features.

[talltree]

@SmithSamuelM I'm glad to see ACDC on the table here now for the VC 2.0 work. For WG members who may not familiar with Legal Entity Identifiers (LEIs) and GLEIF's verifiable LEI (vLEI) initiative, I recommend reviewing it. GLEIF's Regulatory Oversight Committee (ROC) consists of over 70 financial regulators around the world, and they are very bullish on using vLEIs for verifiability of all kinds of financial transactions and reporting. So they can have a tremendous impact on worldwide adoption of verifiable digital credentials.

vLEI infrastructure, like the existing infrastructure for issuing LEIs today, is based on a federation of issuers around the world. In addition, one of the main goals of vLEIs for legal entities (organizations) of any kind is for them to then be able to delegate credentials to officers, directors, employees, contractors, and so on. So vLEI credentials had many requirements that were not addressed by the VC 1.0 spec, especially regarding credential delegation and chaining. They also had very robust security and enterprise-grade key management requirements.

This is why GLEIF invested in KERI for identifier and key management infrastructure and subsequently in ACDC credentials that use KERI identifiers and security infrastructure.

For various reasons that Sam can explain in depth, the architecture is based on the labeled property graph model instead the RDF graph model. So one of the key questions that I'd like to see the VC 2.0 group address is how the second generation spec can accept this additional graph model.

[TallTed]

Without having read too deeply, so possibly missing some pieces, it seems to me that LEIs and vLEIs are more parallel to DIDs than to VCs, though certainly (v)LEIs could be used within VCs, if they are URIs.

I'm not understanding quite what is meant by delegation of (v)LEI credentials, nor how that is contemplated to relate to VCs (or DIDs).

[SmithSamuelM]

@TallTed

KERI is equivalent to DIDs. Indeed there is a did:keri method. Its just the KERI is built in a namespace agnostic way so its security and resolution properties are independent of a given namespace such as the did:keri namespace

ACDC is equivalent to VCs. It is like a VC+ because the ACDC includes an edge section that allows chaining which can be used for a delegated chain-of-authority. This generalizes the concept of a credential being a proof of an entitlement where that entitlement can be delegated. So instead of the proof coming from a single issuer, an ACDC allows a chain where each link in the chain is an issuer delegating authority to the issuee who then becomes the next issuer in the chain. With this construct, hierarchical chains or trees of authority can be expressed simply and normatively without requiring complex application level logic. Its baked into the verification including the schema. So now the structure of the chain or tree (multiple branches for multiple sources of authority) may be made explicit in the schema and verified cryptographically.

For example, The GLEIF vLEI is actually a set of credentials of different tpes that allow the delegation of authority down the a verifiable chain of command for any representative of an entity acting in either official roles or context defined roles.

[SmithSamuelM]

@TallTed. The chaining is not limited to merely chains or trees of delegated authority but includes any relationship. For example in a supply chain, multiple stops along the chain can be represented by attestation ACDCs (no issuee only an issuer) where each stop makes a verifiable confirmation of the prior status of the “chain” by linking back to it. Think of a data-flow diagram where an item of data is “seen” by each entity that processes it (including transformations, amendments, and additions) and makes an attestation to the resultant data after it processes it. Essentially a chain-of-custody of the data including any transformations.

[TallTed]

@SmithSamuelM -- From what you're saying, I gather that verifiable Legal Entity Identifiers (vLEIs) are not really identifiers at all. That naming is quite unfortunate.

In your last, "no issuee only an issuer" seems inaccurate. The issuee just happens to be the (new version of the) credential itself, or possibly "to whom it may concern" a/k/a future-reader a/k/a future-holder.

[SmithSamuelM]

@TallTed. I expect that there are some terminological differences. ACDCs are not bags of triples, they are property graph fragments consisting of a node with properties and zero or more edges with properties as well as some metadata about the graph fragment which includes for example the hash of the immutable JSON schema of the fragment. The structure of an ACDC is primarily based on ensuring secure verifiable non-repudiable attribution of the fragment to its issuer as well as identifiing any verifable data registries (AKA revocation registry).

In ACDC parlance the absence of an Issuee Identifier makes the ACDC an untargeted attestation which could be interpreted as to whom it may concern. Whereas the presence of an issuee identifier can have various semantics depending on the ecosystem governance rules for that type of ACDC. One of those is to designate the target of an authorization or delegation of authority.

I am not responsible for the name vLEI. ;). Your are correct that a vLEI it is is not an identifier in the sense of a DID but is a verifiable credential that grants the issuee identifier provided in the vLEI the exclusive right to use the included LEI attribute (which is an identifier). So to be clear, a vLEI is a verifiable proof of entitlement to use an LEI (however unfortunate. the naming may be).

One could argue, however, that a DID is not a very useful identifier in and of itself but requires a verifiable data structure AKA a DID doc to establish control authority over the DID identifier. In that sense, a DID doc acts as an ersatz verifiable credential for the included DID. Likewise control authority over any identifier requires some mechanism for verifying that authority. From a purely abstract point of view then every identifier that has verifiable proof of control authority either directly vis a vis the public/private keys pairs or indirectly via entries in a ledger that can only be made with some public private key pair that controls the ledger entries requires some verifiable artifact closely bound to the DID that is either a VC or the functional equivalent thereof (i.e. ersatz VC). But I do understand that it can be somewhat confusing to call it a vLEI.

[iherman]

The issue was discussed in a meeting on 2022-09-07

• no resolutions were taken

View the transcript

#### 2.4. ACDC (Authentic Chained Data Containers) in VC DM 2.0 (issue vc-data-model#895) _See github issue [vc-data-model#895](https://github.com/w3c/vc-data-model/issues/895)._ **Kristina Yasuda:** Authentic Chained Data Containers (ACDC). … Sam Smith will give us a presentation on ACDC on the first day of our TPAC meetings. … I'd like to move to issues without the tag Discuss.

[mark-moir]

Sam Smith will give us a presentation on ACDC on the first day of our TPAC meetings

@SmithSamuelM Hi, is there any recording or slideset available for this presentation? Thanks.

[brentzundel]

@mark-moir Minutes are here: https://www.w3.org/2017/vc/WG/Meetings/Minutes/2022-09-15-vcwg#section11 slides are here: https://docs.google.com/presentation/d/1hrqozY2EGZ8i8y40abyEuJmIb6hCiRS-37pdj6bhBLY/edit#slide=id.g1482ccb90af_0_100

[iherman]

The issue was discussed in a meeting on 2023-01-11

• no resolutions were taken

View the transcript

#### 3.4. ACDC (Authentic Chained Data Containers) in VC DM 2.0 (issue vc-data-model#895) _See github issue [vc-data-model#895](https://github.com/w3c/vc-data-model/issues/895)._ **Brent Zundel:** Authentication changes raised by Mike Smith. Discussed at TPAC.. … Not much has happened since the TPAC.. **Manu Sporny:** Work has to happen. General meta-comment about challenges related to the big tens.. … Can we address this problem by calling them digital credentials. There are several different digital credentials.. … Unless there is technical work, we can come to a resolution that the big tents are digital credentials.. **Joe Andrieu:** It's a conversion to be had. that issue 895 requires work to be done -- PRs to VCDM -- and it's not about "big tent" discussion. > *Manu Sporny:* I agree with Joe's take on the issue.. **Joe Andrieu:** The specific request is adjustment to the VCDM as opposed to the request on big tens.. … We have started the conversation.. … If there are any concrete proposals we can proceed.. **Michael Jones:** Naming is hard. Digital credentials name leaves out the verifiable part.. … You can call it digital verifiable credentials.. … In the OpenID world we can call it credentials. Subtype is W3C VCs.. > *Orie Steele:* +1 selfissued. **Michael Jones:** Prefer to keep the word VC.. **Manu Sporny:** Strong -1.. … Reusing terms is problematic.. > *Orie Steele:* There is no trademark on Verifiable Credentials, AFAIK.. > *Joe Andrieu:* @Orie, you should talk with a lawyer. I would wager good money there is, in fact, a trademark. No doubt is unregistered, but that is not how trademarks are established in fact.. **Manu Sporny:** This will lead to conflicts in the ecosystem. Please don't do that in OpenID.. **Michael Jones:** This is not only term for VC.. **David Chadwick:** Support Manu. The title is W3C VC Data Model. We have claimed term VC in the W3C VC spec.. > *Orie Steele:* Notice the search trends for "verifiable credentials"... [https://trends.google.com/trends/explore?date=all&geo=US&q=verifiable%20credentials](https://trends.google.com/trends/explore?date=all&geo=US&q=verifiable%20credentials). **Joe Andrieu:** Agree with Manu.. > *Phillip Long:* +1 to Manu's and David'd comments VC is known and connected to W3C in the public's mind.. **Joe Andrieu:** Inappropriate to reuse the term in other specs.. **Ted Thibodeau Jr.:** Agree that we cannot control other groups.. … There are people that can influence other groups. We minted the term VC..

[jandrieu]

Concrete proposals welcome.

[bumblefudge]

Not sure I understand what the proposal is, but it might help to incorporate it with #860 - it might make sense for a VP to be able to signal to a verifier that ACDC was used to produce it and should also be used to verify it (i.e. to traverse the chain rather that just verify the final VC, etc)

[iherman]

The issue was discussed in a meeting on 2023-02-08

• no resolutions were taken

View the transcript

#### 4.4. ACDC (Authentic Chained Data Containers) in VC DM 2.0 (issue vc-data-model#895) _See github issue [vc-data-model#895](https://github.com/w3c/vc-data-model/issues/895)._ **Brent Zundel:** have a couple more minutes. … going to spend this talking about ACDC. … glief recently joined w3c and intends to join this WG. … hopes to push for way to secure VCs using ACDC. … should talk about that possibility. > *Manu Sporny:* +1 for a concrete proposal on how ACDC secures the VC Data Model. **Brent Zundel:** my perspective is we need a way for the current 1.1 VCDM to be secured using ACDC without requiring significant changes to the data model. … Have an idea how it could work, but not necessarily the best way. **Orie Steele:** Been making progress together on this. … looking at media types and the requirements associated with a media type. … have one currently registered. > *Brent Zundel:* +1 I think media type have a lot of promise for clarifying these issues. **Orie Steele:** this might seem complicated but actually rel simple. … I have prepared slides for f2f to go over media types. … a media type is what we say a credential is.. … It describes the requirements of a credential - for this working group. **Michael Prorock:** would love to see concrete proposal. … WG still struggling how to properly support the existing standards for signing data. … stuff has been out and in broad usage for a long time. Well established standards. … welcome a proposal, but also want to see it turn into a properly incubated spec elsewhere. > *Brent Zundel:* +1 Mike. **Michael Prorock:** loathe to add more to our plate in this WH. … WG. … have plenty to be working on already in this WG. > *Orie Steele:* I'm not in favor of the working group picking up more work, given the current progress and challenges.. **Joe Andrieu:** agree with mprorock. Lot of approaches want to fit in with the VC work. … concrete proposal welcome. … not this working groups job to figure out how to support this work. > *Michael Prorock:* +1 Joe. > *Orie Steele:* +1 Joe. > *Dave Longley:* +1 Joe. > *Manu Sporny:* +1 Joe and mprorock. > *Shigeya Suzuki:* +1 Joe Mike. **Joe Andrieu:** open to tweaking the data model, but need concrete proposal. **Brent Zundel:** agree currently don't have capacity. … thanks all. See you in miami for those who can join. … will be able to participate remotely too for those who can't. ---

[Sakurann]

During Miami F2F WG agreed that

• ACDC is a way to secure a Credential
• there is an interest to explore vc-acdc, but not during this charter Also see direction in #947