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

I just want to shoot in here that, because of the email from Daniel, I
finally understood the need for DIDComs. Not just as a message
envelope standard, that was easier to speak. But as just as safe method as
TLS, but rooted back to DIDs. So sorry for beeing slow, but it was an aha
moment for me, and I wanted to share that if there is more people out there
fighting or struggling with the understanding of DIDComs.
ᐧ

On Mon, Nov 18, 2019 at 5:31 PM ProSapien Sam Smith <sam@prosapien.com>
wrote:

> 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>
> 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
> <daniel.hardman@evernym.com?subject=Private:%20Re:%20%5BHyperledger%20Indy%5D%20concerns%20about%20personal%20data%20hubs%2C%20identity%20hubs%2C%20EDV>
> | Reply To Group
> <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 <indy+owner@lists.hyperledger.org> | Unsubscribe
> <https://lists.hyperledger.org/g/indy/unsub> [sam@prosapien.com]
> _._,_._,_
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>

-- 


*Snorre Lothar von Gohren Edwin*
Co-Founder & CTO, Diwala
+47 411 611  <+47%20404%2061%20926>94
www.diwala.io