How agents interact with non-Sovrin APIs


We’ve been thinking about the best practices that should apply when an agent interacts with familiar web service APIs like Facebook, Google Plus, Twitter, and so forth. This topic feels important because we believe agents will do work on behalf of their owners, and sometimes that work will require proxying. This in turn entails the management of API keys/tokens, which raises some security questions.

Here is a doc that explores some of these questions. Comments appreciated.


I’d be interested in seeing an agent interacting with a less popular API as well. Personally, you won’t catch me with a smartphone unless it is at the far end of a hammer, and if you find me on facebook or linked-in please let me know because I believe in GDPR and my right to be offline.

The other end of the spectrum from facebook would be “niche sensitive data services” - imagine an bespoke API for a set of services - how could I run that on a general purpose agency? I’d have to upload code that runs on another infrastructure (much like a cloud). In certain markets the network is now trusted (like a phone line), but uploading and executing source code snippets “in a public/private cloud” is a lot like doing yoga at a public/private nude beach - no matter what, you are exposing a lot - and for the people consuming bespoke APIs, even a private cloud is a bit revealing.

my solution to this problem was something I called a “micro-agency” - the micro agency supports a very limited set of services for a very limited set of DIDs - where the edge cases get interesting as “very limited” grows. And it conflicts with the concept of DID = Agent, sorta.

it depends upon how DID = Agent, and IO = Agent play out. If you have an agent w/ multiple DIDs, supporting something “in common” - like a ‘primary DID’ which serves as the link to the IO. This adds a layer of “multi-DID routing” to the Agent which is not needed if “Agent = DID” - one agent, one DID.

But if you have Agent = DID, then you need to have the ability for an Agent to support everything a single DID might ever get up to, and that is a crazy burden to put on an agency unless you have an agency be the scale of “App Engine”, where people upload code … wait a minute… (we’ve been here! :wink:

So I think agents need to support a set of “services”, and the DDO should speak to “a set of agents” - where the total number of services supported by the DID is “the set of agents that know the secret cryptographic handshake” - your agents out there are the ones you can TLS with - and they are agents At-A-Place, For-A-Purpose…

In such a world you might have a “public agent” which sits on a well known agency, answers your email, routes your APIs, provides your public face. You might also have some, “discrete agents” which operate on your behalf for specific purposes (e.g. your banking on Hong Kong, your reporting to the United States Internal Revenue Service)

In this way your Hong Kong Financial Representative (agent_(< DID1 >_< HONG_KONG >) ) would sit there, operated by the Hong Kong Monetary Authority, interacting with Hong Kong Banks on your behalf, ensuring comprehensive and detailed compliance (think of the accounting savings!) - and it would be wholly different and insulated from the Social Media presence of your Hong Kong Financial Identity.

These two agents, operating for the same DID, on an agreed upon disjoint set of services (partitioning service_endpoints in the DDO?) - form the online expression of your identity, with the subscription to each service depending upon the backend services provided by the Agency itself. It disassociates, in a fundamental way, the connection of an IO with an Agency itself, and replaces it with the association of an IO with an Agency (for a purpose) - and that, I think, is important for the Trust Framework - particularly in determining the liability transfer characteristics of the IO/Agent relationship.

It’s a round-about way, but I hope not too meandering, way of requesting the comparison of a Facebook level sovrin/non-sovrin interaction in parallel with MyLocalCoffeeShopAPI sovrin/non-sovrin interaction.


That’s a really interesting point Eric. To avoid correlation, we have multiple DIDs per “identity owner”. This means you can have multiple endpoints too, one per DID. This chould give you the ability to have one agent endpoint handling your relationship with your bank via one pairwise DID set, and another agent endpoint handling your relationship with your doctor via a different pairwise DID set.

Similarly you could have one public-facing endpoint (e.g. equivalent to a business card) where you put certain information into the DDO that you are happy to be public, and many other endpoints which are private and subject to strict pairwise identifiers that are only each shared with one other identity owner.

Having two agent endpoints within a single DDO is intriguing. I’ll bravely leave @nage to answer that one!


I think it makes sense to have multiple agents per DID if those agents speak different protocols and provide different “services”, and if you are happy with this kind of correlation to be completely public.

Some agents may have a very narrow purpose (e.g. @ewelton’s Hong Kong banking example, or @nage’s video streaming example), and some agents may offer quite broad and generic functionality (e.g. XDI).

Not sure if there is a use case for having multiple agents per DID that fulfill the same purpose. Perhaps for redundancy/backup reasons. E.g. in the old XRD discovery format (a predecessor of the DDO format), you could have a list of endpoints with priorities for any given service type, and a client would try reaching them one after the other by priority.