On 18 Nov 2019, at 08:46 , Daniel Hardman <daniel.hardman@...> wrote:

This email is a comment about the architecture that's beginning to coalesce around the data hub concept. It is not me trying to derail the effort--I think it's good and important--but me trying to raise a cautionary flag and trigger some thoughtful dialog.

In our understandable enthusiasm to solve a nagging problem for everyone, I am worried that we might end up losing two aspects of SSI that matter a lot:

1. disintermediation

2. identity through DIDs

Regarding disintermediation, a core value that I see in SSI is the notion that I--not some third party with a paternalistic posture that I have to trust to get anything done--am the authority for myself. If people want my data, they have to get it from me. If they want to see my credentials, they have to ask me for them, not somebody else. If they want my consent, they have to ask me for it, not somebody else. If I want to audit what's happening, I audit my own records, not somebody else's.

To the extent that the posture of a hub is closer to a brokering service for my data, configured by me but operated by a third party that requires me to trust it, I think this aspect of self-sovereignty is seriously weakened. The notion that I am putting the data into the hub in encrypted form does not, in and of itself, alleviate this concern for me; however, how the encryption is controlled might make me more or less concerned. Portability of data out of the hub into a different hub or something that's not a hub at all would make a difference, too.

Now, I get that not everybody in our decentralized identity circles is explicitly pursuing SSI. Some of us will be perfectly content to building something that's decentralized but not self-sovereign. And that is fine, IMO. But I would like the architecture of hubs not to preclude self-sovereign versions of hubs. This means that I would like it to be possible for Alice to put a hub interface behind her own identity (and her own DID) rather than the identity of a third party hub-serving intermediary. If we can design hub interfaces such that this is a first-class mode of operation, I will feel cheerful about this issue.

Regarding identity through DIDs: it feels ironic to me that we have spent vast amounts of energy talking about how to prove control of an identifier associated with a particular identity subject, through the DID mechanism--and we then throw our wood/energy behind an approach that exposes all personal data through intermediaries, where those intermediaries interact in both directions through a different security mechanism (TLS with certs and logins/API keys). If hubs are as important to identity as we think, and they take off, and if they are exclusively TLS-centric, we've basically cut the legs out from under DIDs.

I get that RESTful, TLS-central interaces are ubiquitous and easy, so it's worth exposing them. I am not opposed to a hub mechanism that includes that sort of interface; what I am worried about is a hub mechanism that doesn't also include a mechanism secured by DIDs and their keys, such that builders of hubs don't get limited just to orgs with certs and trust derived from CAs (the very trust architecture we are hoping to upgrade). Therefore, I am looking for any spec that gets written to include the ability to interface with hubs over DIDComm. This means that in the non-TLS mode, I ought to be able to authenticate the hub itself, plus any party that interacts with a hub, using the keys in my DID doc, NOT using certs and logins and API keys.