Discussion about off-chain file storage


#1

Even though the Sovrin Ledger is specifically designed to tackle the core of the identity problem, intuition tells us that the storage of physical document scans as proofs of identity will be a common use case. However, these are most probably intended for private usage and selective sharing.

This thread is for discussing such matters, and propose different schemes that might allow for users to safely store (and share when needed) their relevant files with third parties. How can we leverage Sovrin identity layer in integration with off-chain platforms for effectively proving document ownership and disclosing its content selectively and securely? Which file storage technologies are a good fit for such model?..


Standards (or guidelines) on the functioning of Sovrin Agents?
#2

One of the purposes of an Agency (see The Inevitable Rise of Self-Sovereign Identity) is to provide storage for off-chain assets. Maybe Jason or Daniel could comment on any architectural features they envision for Agencies. I think most of that is yet undecided, however, and different agencies might choose to do that differently, so this is a timely discussion topic.


#3

Thanks for your reply Phil!

It would be interesting indeed to know what has been envisioned on this topic already. Although different agencies might have different needs and different platforms, it would be good to know the views from the team, as well as any guidelines or suggestions on the matter.


#4

I agree with @cbruguera that document sharing is important to many sovrin use cases.

Most of the off-ledger storage mechanisms that you can imagine (S3, IPFS, DropBox, etc) are technically compatible with Sovrin; we’ve deliberately not ruled things out. Of course, some scenarios disclose information in a way that’s correlateable, so not every choice preserves privacy equally well. Agencies could add value here by generating a unique URL alias for access to storage, for every unique relationship that an identity owner has in the sovrin ecosystem. Agencies could also provide the storage itself (not just a URL to access the storage)–but as soon as they do that, there is a potential for a sovrin identity to lose a little bit of its portability, if content is hard to move.

In general, I think the mindset of the sovrin design with regard to storage is to use the ledger to establish secure channels of communication using asymmetric keys, and then to transmit information about documents over those channels–instead of storing the documents themselves, directly. This works the ledger less, introduces less hacking targets, and provides maximum flexibility.


#5

I talked about this a little on today’s Sovrin User Group call. My view is that a primary feature of Sovrin agents is off-ledger storage of claims and other forms of Sovrin-secured data (scans of conventional identity documents are also a good example, as are medical records, financial records, educational records, family records, etc.)

Obviously for interoperability—including portability of that data across multiple agency providers—standardization of the agent interface is important. Here I’ll show my bias—I’m co-chair of the OASIS XDI Technical Committee, an open standard for semantic data interchange that is tailor-made for this job. So my recommendation fits Daniel’s final paragraph exactly: use Sovrin for IDs, keys, pointers (to agent endpoints) and proofs, and then use private XDI data exchange between Sovrin agents, secured by asymmetric encryption verified by Sovrin public keys, for the rest.


#6

I’m just as biased as Drummond here, but want to support the view that XDI can add value here. One of its capabilities is to reference any kind of data no matter where it is stored, what format it uses, and what protocol is needed to access it.

So in Sovrin, you could store an XDI address, which can point to any storage mechanism using XDI “connectors”:

Some examples of previous work in this area: