Re: [Hyperledger Indy] concerns about personal data hubs, identity hubs, EDV

I agree that both aspects of SSI are important, and that reliance on
classic CAs breaks SSI principles.

But regarding your first point, I don't think there's a difference
between the agent concept and hub concept in terms of how the respective
communities feel about disintermediation.
I believe the narratives are that hubs and agents can either be
self-hosted, or hosted by third parties, with the same pros and cons in
each case.
At least that's how it should be, maybe I missed something there.

Anyway, also +1 to secure communication with agents/hubs in a way that's
rooted in DIDs (e.g. using DIDComm, but could also be DID-TLS or
something else).

Markus

On 11/18/19 4:46 PM, 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.
>
> _._,_._,_
> ------------------------------------------------------------------------
> Links:
>
> You receive all messages sent to this group.
>
> View/Reply Online (#476)
> <https://lists.hyperledger.org/g/indy/message/476> | Reply To Sender
> <mailto:daniel.hardman@evernym.com?subject=Private:%20Re:%20%5BHyperledger%20Indy%5D%20concerns%20about%20personal%20data%20hubs%2C%20identity%20hubs%2C%20EDV>
> | Reply To Group
> <mailto:indy@lists.hyperledger.org?subject=Re:%20%5BHyperledger%20Indy%5D%20concerns%20about%20personal%20data%20hubs%2C%20identity%20hubs%2C%20EDV>
> | Mute This Topic <https://lists.hyperledger.org/mt/60205429/952282> |
> New Topic <https://lists.hyperledger.org/g/indy/post>
>
> Your Subscription
> <https://lists.hyperledger.org/g/indy/editsub/952282> | Contact Group
> Owner <mailto:indy+owner@lists.hyperledger.org> | Unsubscribe
> <https://lists.hyperledger.org/g/indy/unsub> [markus@danubetech.com]
>
> _._,_._,_