As far as I understand, or what I could catch from the agent talk, the Data Vault component of the Sovrin agent is being designed as a form of “connector”, some sort of API bridge to connect with the actual vaults that might be located anywhere. Is that right?

If so, are there any particular protocols being considered for this Data Vault connector for establishing secure communication with the Data Vault?

Any other details you could share about this Data Vault component? I’d really appreciate it.

Carlos, I’m not the one to answer this question— @nage and @TelegramSam should jump in—but my understanding is that the Data Vault would be one API extension exposed by the agent. So when you are communicating to that particular API extension, you are talking directly to the Data Vault.

If there IS a connector involved, it’s hidden behind that Data Vault API extension.

It could be done that way. We’re trying to specify the interface concept first so that it could be coded differently by different agent implementations.

To say this another way, we expect that there will be a data vault API that can be added to an agent, This API will provide the ability to store data under a key, as in key/value store, and this api layer will encrypt that data so that it can only be accessed by an authorized part of your agent. In the Sovrin reference agent the data will be saved locally to hard disk on the machine running the agent. In other use-cases the storage code could be storing that data somewhere else (on a SAN/NAS, in a database, etc). The protocol would be specified by the code that implements the data vault interface and could do so as it sees fit.

I am thinking that the policy system of an agent needs to handle Authorizing code that call other extension code the same way it handles letting endpoints call extension code. This helps the owner manage proxy calls to other agents (for example your cloud agent calls APIs that live on the agent in your home-automation system), and makes the logging and permissions uniform when you migrate an extension from being externally callable to becoming a part of some automation you’ve enabled.

The details around these “ACLs” or “Authorization Mechanisms” are not fully resolved yet. We’ll try to do that work out in the open as we dive into it.