1K/ Digital Identity with LEIs - Update on the Verifiable LEI (vLEI)
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
Discussion
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
GLEIF has been working ‘security-first’
Note: German government weak security article in Der Spiegel today - not good for the overall ecosystem
https://www.spiegel.de/netzwelt/apps/id-wallet-was-nach-dem-fehlstart-mit-dem-digitalen-fuehrerschein-passiert-a-f4bc10bc-08ab-42b4-9325-5de5cdc66e05Should have interoperable security before interoperability semantics
A problem is that we have many security models - and they are not necessarily compatible
The security model should be transparent and inspectable
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