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

Clarification: The former (ie end-to-end to originator not intermediary) should be the default.

> On 18 Nov 2019, at 09:27 , ProSapien Sam Smith <sam@prosapien.com> wrote:
> 
> I want to echo Daniels concerns about SSI at least the sovereignty part.  There is a subtle but very important distinction between a proxy service that acts on the behalf of  DID controller using end-to-end authentication back to the DID controller and an intermediary service that is authenticated with its own DID to serve up a third parties data.  This should be the default.
> 
> In some cases, however, (high volume) it may make sense to have a intermediary sign things (versus end-to-end back to originator). But that signing authority should be under the control of the originator controller not the intermediary.
> KERI includes the concept of hierarchical delegated keys/identifiers. This allows a controller to delegate a set of signing keys/identifiers to a proxy but those keys are controlled by the delegator and may be revoked/rotated away from the intermediary delegate at the discretion of the delegator. This allows true portability of the underlying identifiers. The delegator may merely change delegation via a rotation event to port their signing delegation to a new intermediary. A compliant intermediary would support an API for a new delegate to download the data from the old delegate. The rotation event indicates the control authority of the new delegate to extract the data from the old delegate.
> 
> This approach when coupled with derived DIDs  (see the DAD paper RWOT7) preserves the essential characteristics of self-sovereignty in more hierarchical or complex arrangements.
> 
> 
>> On 18 Nov 2019, at 08:46 , Daniel Hardman <daniel.hardman@evernym.com <mailto:daniel.hardman@evernym.com>> 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/952307> | New Topic <https://lists.hyperledger.org/g/indy/post>
>> 
>> Your Subscription <https://lists.hyperledger.org/g/indy/editsub/952307> | Contact Group Owner <mailto:indy+owner@lists.hyperledger.org> | Unsubscribe <https://lists.hyperledger.org/g/indy/unsub> [sam@prosapien.com <mailto:sam@prosapien.com>]
>> 
>> _._,_._,_
> 
> 
> Samuel M. Smith Ph.D.   Founder
> smith.sam@prosapien.com <mailto:smith.sam@prosapien.com> 
> ProSapien LLC
> 242 East 600 North, Lindon Utah 84042-1662 USA
> Office 1.801.768-2769
> Mobile 1.801.592.8230
> Skype: samuelmsmith
> http://www.prosapien.com/ <http://www.prosapien.com/> 
> 
> NOTICE: This electronic mail message, together with any attachments contains information
> that may be copyrighted, confidential, proprietary, and/or legally privileged of and/or by 
> ProSapien LLC. This  electronic mail message is intended solely for the use of
> the individual or entity originally named as the intended recipient. If you are not the intended
> recipient, and have received this message in error, please return immediately this message
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


Samuel M. Smith Ph.D.   Founder
smith.sam@prosapien.com 
ProSapien LLC
242 East 600 North, Lindon Utah 84042-1662 USA
Office 1.801.768-2769
Mobile 1.801.592.8230
Skype: samuelmsmith
http://www.prosapien.com/ 

NOTICE: This electronic mail message, together with any attachments contains information
that may be copyrighted, confidential, proprietary, and/or legally privileged of and/or by 
ProSapien LLC. This  electronic mail message is intended solely for the use of
the individual or entity originally named as the intended recipient. If you are not the intended
recipient, and have received this message in error, please return immediately this message