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.