1K/ Digital Identity with LEIs - Update on the Verifiable LEI (vLEI)

From IIW

Digital Identity with LEIs - Update on the Verifiable LEI (vLEI)

Tuesday 1K

Convener: Karla McKenn, Christoph Schneider

Notes-taker(s): Andrew Hughes

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

  • Slide deck: https://github.com/WebOfTrust/vLEI/blob/main/docs/2021-10-12_Update-vLEI-IIW_v1.1_final.pdf

  • Overview of vLEI progress from GLEIF

  • Presently LEI require manual verification - vLEI is an attempt to use decentralized identification and verification instead

  • vLEI represents Organization/Legal entity & Person & Role

  • [[File:./media/image1.jpeg|624x358px]]

  • Waiting for ISO 5009 to be published - Financial Services - Official Organizational Roles

  • [[File:./media/image4.jpeg|624x357px]]

  • [[File:./media/image2.jpeg|624x357px]]

  • [[File:./media/image6.jpeg|624x357px]]

  • LEI Issuers can be any organization that passes the qualifications - not just financial institutions or governments - e.g. Bloomberg, Corporate Registries, banks, etc

  • Generally attempting to set up a similar governance structure for vLEI Issuers

  • [[File:./media/image5.jpeg|624x357px]]

  • [[File:./media/image3.jpeg|596x341px]]

  • Have worked with TOIP to develop initial versions of the ecosystem governance framework

  • Pilots start 4Q2021


  • GS1 comments - GS1 Identifier is very similar to GLEIF/vLEI - doing their own POC and moving forward

    • Question about the data model used - seeking to share code and models

  • Deeper dive will happen in Session 2K

  • Self-Addressing IDentifier (SAID)

  • Verifiable Credential chaining spec - VC spec variant

  • Lots of the work is happening in the TOIP ACDC WG

  • https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force

  • vLEI is based on KERI for key management infrastructure

    • Look for more KERI sessions this IIW

  • Key Event Receipt Infrastructure ( https://Keri.one <— everything about KERI )

    • Provenances the key state

    • Provenance logs - Witwicki session today

    • Cryptographic root of trust then all changes to key state are visible

    • Duplicity-evident key state (to determine if there’s duplicity in the key state for any Identifier)

  • vLEI governance includes specification of how entities are managing their keys - and KERI allows visibility

  • Discussion about security perceptions about SSI - must put security first

  • Self-addressing Identifier

    • If all the major parts of a VC are labeled with a SAID then if any part of that VC are changed, then it’s detectable.

    • SAID is content-addressable identifier for VC (so changes to content are obvious)

    • SAID is embedded and bound to the VC content - guarantees no-tamper

    • And now, the reasoning about SAIDs does not rely on the content of the VC - you can work with the SAIDs - like “hidden signatures” in Ricardian Contract literature

    • THis allows the existence of “chained credentials” - hash chained data structure

    • Means that an ACDC is a fragment of a tree of credentials - which can be assembled into a graph of credentials - and allows reasoning on the graph

    • https://weboftrust.github.io/ietf-said/draft-ssmith-said.html

  • Privacy - who participates in an exchange (i.e. metadata exposure)

    • Confidentiality - what was exchanged

    • Can protect confidentiality with strong legal guarantees

    • The SAID allows chaining/binding to any legal constraints (boilerplate and contract text)

    • Allows high authenticity and high confidentiality