2K/ GLEIF vLEI: Distributed Multi-Sig Delegated Credential Issuance with KERI & ACDC

GLEIF vLEI: Distributed Multi-Sig Delegated Credential Issuance with KERI & ACDC

Tuesday 2K

Convener: Phillip Feairheller, Kevin Griffin

Notes-taker(s): Charles Lanahan

Tags for the session - technology discussed/ideas considered:

GLEIF, vLEI, multi-sig, KERI, ACDC, delegated credentials, chained credentials

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: 

Presentation Slides

Qualified vLEI Issuer vLEI Credential => QVI

Legal Entity vLEI Credential => LE

Legal Entity Organization Role vLEI Credential => OOR

Legal Entity Engagement Context Role vLEI Credential => ECR

• Demo

  • Need something that is always on. Witness Network.

  • Need an identifier.

    • Transferable identifier in keri (means we can rotate the keys). The witnesses in the network are picked, we then derive a key from the witnesses’ keys

  • Agent then has multi-sig group identifier

• ACDC Feature overview

• Overview of ACDC Credential compact field labels.

• Overview of how an LEI - Chain of trust is laid out.

  • GLEIF -> issues -> Qualified vLEI Issuer -> issues -> vLEI

• Overview of various credentials produced in above chain

• KERI features

  • Autonomic, transferable, non-transferable ids

  • Witness/watcher networks

  • Async distributed multi-sig protocols

  • Delegation

  • Public transaction event logs

• vLEI arch overview

Q&A / Comments

• Store and forward capabilities will exist via witness networks because not all agents will always be online.

• There is a trade off between authentic communication and irrefutable communication

• Management of keys in a decentralized world will always be a problem to solve for the user in regards to usability.

• Is multi-sig really necessary in the real world?

  • For entities operating as roots of trust probably, for individuals probably not.

• Is there “vendor lock in” in regards to keri?

  • Not so much, KERI is attempting to become an IETF spec without vendor lock in.

• Comment: Multi-sig as a term means something different from what cryptographers mean. Everyone has to trust each delegator. By using a cryptographically defined “threshold signature” we gain features in the protocol that don’t need governance frameworks.

  • Delegation and issuance is different.

  • KERI was implemented with an objective to be able to plug and play various protocols and cryptography that may arise in the future so its very generic and built to be extensible. These types of schemes could (and probably will) be added in the future.

Presentation deck can be can be found here:

GLEIF vLEI: Distributed Multi-Sig Delegated Credential Issuance with KERI and ACDC