Do we really need ledger for Sovrin to function as Identity service?


#1

I’m learning Sovrin. And consider its design goals the best among any other identity related initiatives. I’ve been questioning the need for a ledger in Sovrin’s ecosystem. The ‘Agents’ internalizes the very concept of DID/DDOs of an identity. The ledger contains the non-sensitive public part of identity transactions - also call “Identity Records”. However, the trust of an identity is not on the ledger but on the signature of the issuer of the claim. This signature lives off-chain on the DDO. The process of getting an endorsement (aka signature form issuer), is a peer to peer off-chain communication.

So, if we remove the ledger all together, what will we loose in terms of functionalities of Sovrin Identity service?

(I’m certainly missing something. Please help me understand)


#2

The biggest need that the ledger addresses is to provide an authoritative, globally consistent answer to this question: “What is the public key for identity X?” (Or what was it, at a particular point in time…) The answer to this question is the foundation of secure communication, of reliable digital signatures, and so forth. It is remarkably simple, and remarkably powerful. A related question is, “Where is the agent for identity X?”

You can’t use agents with confidence, without the ledger–because you have no way of knowing the authoritative endpoint of an agent. You can’t use digital signatures without a ledger, because you can’t test their appropriateness against a global source of truth.

The ledger is also required for the whole claims/proofs ecosystem, because without the ledger, there is no authoritative way for them to be signed, and no authoritative way to revoke.


#3

I’m also new to this.

How can the ledger answer “What is the public key for identity X?” if the private key for identity X is stolen and someone wants to masquerade as X?


#4

I was wondering the same topic discussed here.

As Sovrin is a permisioned ledger only trusted parties can write on it. There is no risk of a 51% Attack.
Which is the benefit of using a ledger (with the associated complexity) instead of a traditional chain of hashes for the “Identity Records”?

As rupert says probably I’m also missing something so any further explanation will be appreciated.

Thanks in advance,
Ivan.


#5

Hagna,

DIDs, decentralized identifiers, point to DDOs (DID descriptor objects), a JSON-LD structure that contains any public keys associated with that DID along with endpoints (URLs) that the DID uses. So, if you have my DID, you can look it up on the ledger and get a public key. See: https://github.com/WebOfTrustInfo/ID2020DesignWorkshop/blob/master/topics-and-advance-readings/DID-Whitepaper.md

Sovrin also allows records to be revoked, so if the private key is lost, the DID can be revoked.


The Authenticity of a DID and Sovrin's Dependence on the PKI
#6

We have not built this yet but one of the idea would be to let the combined effort of multiple identities trusted by the identity whose key is stolen to change it’s verkey. The idea is similar to Shamir’s secret sharing. So Alice might establish a rule on the ledger that in case if 2 out of 3 people, namely Alice’s Trust Anchor, her husband Bob and her manager Dave come together, they can change her key so when Alice loses her key, she asks all of the 3 people to make a particular transaction on the ledger and as soon as 2 people make that transaction, Alice’s key gets changed again thus putting Alice back in control.


#7

It is true that trusted parties called Validators (like a miner in Bitcoin) control the writes done by other identities. Each Validator is controlled by a Steward which is an organisation like a credit union, a healthcare firm, an insurance company, etc. It is among these parties that the trust is diffused, i.e

  • if more than 1/3 of these organisations were to go rogue, the ledger will stall,
  • if more than 2/3 go rogue and collude then data on the ledger cannot be trusted.
    But if the above 2 conditions are not met then a user does not have to trust any of the organisations (Validators) and each organisation ensure that writes done on the ledger are correct

#9

@rupertredding The “trust of the identity” can comprise of trust over several entities. The ledger can be just one of the entities. As an example consider an interaction between Alice and Bob where Alice needs to present a verifiable claim say a credit score certificate to Bob signed by a Issuer called Acme Corp. Now Bob’s Trust in the credit score certificate = Trust that Acme Corp does the credit score calculation correctly + Trust that the certificate was actually signed by Acme Corp.

Trust that Acme Corp does the credit score calculation correctly is an “off ledger” (does not require ledger) trust and in most cases will be a priory since Bob would have asked Alice that it will only accept a certificate from Acme Corp.

Trust that the certificate was actually signed by Acme Corp is an “on ledger” trust since Acme Corp’s DID lives on the ledger and the signature over the certificate can be verified by Acme Corp’s “public key” (it’s a different kind of public key though); this relationship is also facilitated by the ledger. Hope this answers your question.

Also Alice and Bob might want to write (encrypted and signed) some parts of their interaction on the ledger if they feel that that they will require arbitration in future and these parts of the interaction can then be inspected by an Escrow