I think Jason Law ought to weigh in on this, but here’s my quick take:

Sovrin does not prevent storing encrypted attributes on the ledger (anything you store on the ledger is a blob, and all blobs are equally opaque). However, the Sovrin community should have an opinion about what attributes are good to store on ledger, and I believe the opinion should be: public attributes only.

When you have an attribute that everybody in the world is supposed to know (e.g., the street address of a university), then recording that attribute in a public source of truth makes sense. But when you have data that you want one (or very few, selectively chosen) entity to know, encrypting it and storing it on the ledger feels risky. Yes, you can encrypt it, and yes, the encryption that sovrin uses is industrial-strength and guarded by best practices. But the permanency of the ledger and publicness of the ledger run counter to the need for secrets; why put a hacking target out there, where all the world can see it for all time? If a key ever becomes known, old secrets may surface. The ledger becomes a honeypot (although the scope of hacking is limited, since very few secrets on the ledger would be encrypted with the same key).

Instead, we recommend using secure communication channels established and maintained through the sovrin ledger to exchange secret information out-of-band. Alice stores her public key for communications with Bob on-ledger; Bob stores his public key for communications with Alice on-ledger. When they wish to exchange a secret, they look up the respective public keys on-ledger to account for any revocation/rotation, then send the secret. Agencies help here, because “send the secret” implies that each can somehow contact the other–and an Agency can provide an addressable endpoint in the cloud that proxies an identity owner for communication purposes.

Hash-tree encryption is, indeed, used for zero-knowledge proofs–but not necessarily in conjunction with data stored on the ledger. Essentially what you have is a way to hash progressively less granular views (subsets) of a larger document, such that you can disclose a tiny portion of plain text, leave the rest of the doc encrypted, but prove that you possess the larger document because you can produce the bytes that generate it hash.

The only kind of key stored on ledger (IMO) should be asymmetric public keys (the “verification keys” used in elliptical curve cryptography). Private keys should be stored at the “edge” – that is, with the user, where they were originally generated, perhaps on a mobile device or similar – and never transmitted. Symmetric keys can be shared using a secure comm channel built from published public keys in much the same way that SSL builds a channel and then shares a symmetric session key; the symmetric keys are not stored anywhere but with the endpoints (the entities that are interacting). This makes symmetric keys ephemeral; the only revocation you have to worry about is revocation of the public key. Revocation transactions go on the ledger, so the ledger becomes the public source of truth about which key to use to talk to identifier X.

An agency can facilitate recovery mechanisms by supporting secure backups of keys known to an identity owner (where the backup is opaque to the agency, and decryptable only by the owner using a biometric or similar). It is also possible to use Shamir secret sharing to support recovery scenarios where, say, 5 friends are designated as trustees, and at least 3 friends must agree on the recovery to unlock it.

Now, this brings me to the question: how do “anonymous credentials” work? Is this feature somehow related to on-chain data encryption? Or will this also a responsibility of Sovrin Agents? To what extent will the Sovrin ledger provide actual zero-knowledge proofs?

Another great question, and it definitely isn’t made clear by the existing documentation. We are writing up something which explains it properly right now and hope to share it very soon. But in simple terms, what the ledger supports for claims is proof of ownership, proof of validity, proof of existence, and proof of non-revocation. The creation and verification of zero-knowledge proofs and anonymous credentials based on claims is done by the clients and agents, and facilitated by the ledger.

That’s what I thought, given that we don’t want private data stored on the ledger. It’d be quite interesting to know how does the ledger facilitate it, though… Anonymous credentials and selective disclosure are being mentioned frequently as one relevant feature of the Sovrin system, and I do think it’s quite an important characteristic for self-sovereign identity.

@cbruguera: Here’s one useful tidbit that I can offer, about anonymous credentials, before James’ content becomes available. Sovrin is going to offer an implementation of anonymous credentials that is based on Idemix (from IBM research). We are building it in such a way that uProve-style anoncreds can also be used, but we haven’t spent as much time there in our initial work. You should be able to do a web search for idemix and uprove and get some useful technical background which will sharpen the questions you ask when Sovrin’s official content becomes available.

Given that all data stored on the ledger is public by nature. What roles do XDI “link contracts” play here? As far as I can understand, link contracts govern the sharing of data. But if everything on the ledger is already public, how do link contracts fit in here and in which ways could an identity owner actually control who has access to what?

Also, regarding the public nature of the Sovrin Ledger: can anyone just query for viewing and verifying claims about just anything? Is it that public? Aren’t there any limitations to this?

Link contracts can be used to firstly request one party to share data with the other, and specify what data is being requested. The ledger will have been used to enable the 1st party to discover the 2nd party.

Once the 2nd party agrees to share the data, the link contract is completed and the data is shared directly between the parties (no intermediary). Both parties keep a copy of the link contract which both have signed so both have a record of the transaction which is itself anchored back to the ledger. The 1st party can verify the validity of the presented data using the original issuer’s public key available on the ledger. A hash of the link contract can then be stored on the ledger.

Private personal data is recommended to be stored off the ledger itself within the identity owners own “container”, which can be stored in multiple places. Therefore if you inspect the ledger you won’t see this information.

The ledger is indeed open to public view, which is why our recommendation is that private data, even if encrypted, is held off-ledger but anchored to identifiers & keys etc. Anyone can send a link contract request to another Sovrin identity owner, but it is up to that identity owner to determine whether they want to share data or not. There will be public data on Sovrin, such as company names and addresses, and other info that individuals may want to make public.

I hope that helps - the other guys are sure to jump in with more detail.

@Kazue, I was at IIW all last week or I would have answered earlier. The short answer is that the Sovrin ledger, by itself, does not answer the “trusted discovery” problem. Once you have the DID (decentralized identifier) of a Sovrin identity owner, the Sovrin ledger can help you look up that DID and verify identity claims from the identity owner. But how you first obtain the identity owner’s DID in order to begin the verification process is a different problem.

Numerous options for discovery were discussed at IIW last week, including “LinkedIn-style” Sovrin directory services, reputation services, and Sovrin login to conventional web pages with profile information. All of them can work assuming identity owners who participate in such discovery services can be assured that they will maintain their privacy. That’s yet another subject, and one I don’t have time to address now, but would love to delve into soon.