concerns about personal data hubs, identity hubs, EDV

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.