Awesome-Mirrors/decentralized-id.github.io
1
0
Fork 0
mirror of https://github.com/Decentralized-ID/decentralized-id.github.io.git synced 2024-10-01 01:05:54 -04:00
Code Issues Packages Projects Releases Wiki Activity
8608e7a62e
decentralized-id.github.io/_posts/identosphere-dump/open-standards/keri.md
⧉ infominer a11ac125cf exchange protocols
2022-12-02 03:40:42 -05:00

12 KiB
Raw Blame History

published
false

KERI

This the link to the 20 minute introductory presentation in pdf:

We at Jolocom strongly believe that DIDComm is a crucial infrastructure element for the broader and future-proof SSI stack, and current work on DIDComm v2 includes Jolocom’s implementation of the specification with authcrypt (authenticated encrypted) and most of the low level of the protocol.

It has lots of relevant links in it to start your journey in KERI.

What is KERI?

  • Key Event Receipt Infrastructure
  • Intends to repair the Internet
  • KERI = CT with decentralized CA
  • NOT a coin, token…

Why KERI? (and not something else)

  • Strong autonomous identifiers
  • Abiding to privacy (laws and good habits)
  • Portability, delegation, rotatable keys
  • Direct & Indirect method
  • <there’s more>

With my notes:

The Three KERI Security Sessions have the same set of Slides it just 3 hours to get through them.

*Q: What are the security risks of KERI with regard to the identity protocol?

Harm that can be done to the a controller: Unavailability, loss of control authority, externally forced duplicity

Harm that can be done to a validator: Inadvertent acceptance of verifiable - but forged or duplicitous events

Breaking the promise of global consistemcy by a controller is a provable liability. However, global consistency may only matter after members of that community need to interact, not before.

(SamMSmith)

Q: How secure is the KERI infrastructure?

KERI changes the discussion about security. From a discussion about the security of infrastructure to a discussion about the security of your key management infrastructure. Most people when they think security, the think “oh, blockchain!”: permissioned or permissionless, how hard is it to get 51% attack, etc.Non of that matters for KERI. KERI is all about “are your private keys private?!” And if yes, that drastically slims down the security discussion to brute force attacks to public keys. And because the next public keys are in fact protected by a hash, you have to brute force the hash algorithm, that is post-quantum secure. So that is a very high level of infrastructural security.

So private key management and protection is the root of your security in KERI.

*Q: You are arguing KERI affords greater security than a decentralized linear event system like Bitcoin?

…you would be fundamentally arguing that you can record a singular, immutable linear event history more securely than Bitcoin, and I see nothing in KERI that would indicate that.

Read the answer to this first.

If you read Szabo’s paper on threshold structures, you get security of the same type when ever you use a threshold structure, be it MFA, Multi-Sig, or Distributed consensus. They all are using a combination of multiple relatively weak attack surfaces that must be simulatenously compromised for a successful attack. So multiplying simulatneous weak surfaces = functional equivalent of a stronger attack surface. So when you look at KERI you see that the security is primarily due to cryptographic strength and the witnesses are not the primary source of security but merely secure one thing, that is the availability of the KEL for an identifier. Not the KEL itself. The KEL iteself is secured by signatures.

From a Validator perspective their security is due to duplicity detection. Successful attack against duplicity detection requires an eclipse attack. Ledgers such as bitcoin are also susceptible to eclipse attacks. So in an apples to apples (resistance to eclipse attack) a KERI watcher network of comparable reach (1000’s of watchers) would have comparable resistance to an eclipse attack.

Q: Differences between blockchain-based security and KERI security

  • Where KERI doesn’t need total ordering in its logs, blockchain do need that. What KERI needs is watchers that construct string of event in the relative order of reception of the KEL {TBW please explain or improve this: what is this, why is it important?}
  • Another characteristic is that KERI identifiers are transferable and blockchain-based identifiers are not, they are bound to their ledger.

This was a meeting of the minds between myself and Sam Smith and Adrian Gropper that was hugely successful. We all decided to use the term "endorser" for what we all called "registrar"/"witness"/"notary". We also realized that the KERI proposal for encoding is good enough for authentic data provenance logs and we will be using the KERI encoding. Sam has modified the spec for KERI key event logs to include scripting capabilities needed in the authentic data economy for doing things like cross-chain atomic swaps for selling non-fungible authentic data (NFADs).

The result is that there is grand convergence on the encoding and file format for key event provenance logs that will be supported by both KERI networks and the broader authentic data economy.

The Global Legal Entity Identifier Foundation (GLEIF) proposes that the Legal Enitity Identifier (LEI) can be used to establish a chain of trust for organizational identity.

In this session, GLEIF shares plans and progress regarding its development program to create an ecosystem and credential governance framework, together with a technical supporting infrastructure, for a verifiable LEI (vLEI), a digitally verifiable credential containing the LEI.

Link to presentation available until April 2022:

Agnostic to any network

  • Development of the capabilities needed for GLEIF to issue and verify vLEIsfor vLEI Issuers does not need to operate on blockchain or distributed ledger technology.
  • GLEIF can implement KERI (Key Event Receipt Infrastructure) to support fully decentralized portable secure key management operations on self-certifying identifiers.
  • GLEIF is undertaking development of the capabilities based on KERI during 1Q to 3Q of 2021 and aim for initial live beta implementation with an SSI Network starting in 4Q.

Interoperability

  • This would allow GLEIF to connect to any blockchain or distributed ledger technology SSI network without the need for custom implementation, cost and overhead of operation.
  • KERI is Quantum Safe. It is resistant to attacks by both classical and quantum computers.

ACDC

Datum is, from its Latin origin, a singular form of “data”, and may refer to a single item of data.