Re: [EXTERNAL] Re: The DID service endpoint privacy challenge

If I'm understanding the outcome of this thread correctly, the text we
should be adding to did-core privacy considerations section is that "Most
anywise did documents which are intended to be discoverable by numerous
people should use 1 service endpoint and it is recommended that the service
endpoint is shared by many did documents to achieve herd privacy benefits".

We may also want to define anywise did, n-wise did, and pairwise did within
the did-core terms.

Are there any other changes we'd want to make as well that I missed?

On Wed, Jul 1, 2020 at 1:01 PM Adrian Gropper <agropper@healthurl.com>
wrote:

> On Tue, Jun 30, 2020 at 8:14 PM Daniel Hardman <daniel.hardman@evernym.com>
> wrote:
>
>> My view diverges on this. I don't believe data is now, should be, or will
>> be the heart of SSI interactions; the self-sovereign identity subject must
>> be the heart instead, with data being legs and feet. Thus, personal
>> datastores (which certainly need to exist and are vital; don't get me
>> wrong) feel like the wrong foundational abstraction; people themselves are
>> better. First you deal with them; then you can deal with their data, if
>> they let you, as long as they continue to let you. You may have a
>> relationship to their data, but it is always secondary to the relationship
>> with them. They never fully disintermediate themselves, and they remain The
>> Fact you can't get around. Every attempt to access data is an opportunity
>> for them to express their sovereignty. This is a pretty radical departure
>> from today's information economy, which runs on the assumption that info is
>> an independent, inert resource to harvest, and it's published and held
>> somewhere in trust for an identity subject.
>>
>> It is true that a heavy identity subject in the middle of every
>> interaction could create inefficiency; thus, automating the authorization
>> and intent of the data subject with respect to the data is crucial. Done
>> right, I think it's invisible in UX and nearly invisible in terms of cost
>> -- unless/until the identity subject wants otherwise. I don't think this is
>> actually the sort of distinction that makes architectures impossible to
>> reconcile, so I'm not trying to incite a new debate on this thread. I still
>> agree with what we jointly published about rhythm and melody between hubs
>> and agents making beautiful music. I'm just noting that I have a different
>> take on how to balance the two and which is primary.
>>
>> But here, that's a subtlety. No matter whether you like my balance or
>> Daniel B's, the fact remains that data interop is hugely valuable and we
>> need to solve it.
>>
>
> +1 Daniel H. - well said.
>
> I'm hoping to separate the mediator from the storage as concerns to avoid
> the potential for lock-in and platform business models. "Surveillance
> capitalism" is probably hyperbole in this context because we seem to have a
> consensus that Alice should be paying for her mediator service.
>
> How Alice pays for her policy decision point (PDP) and her secure data
> store are also part of the surveillance capitalism issue. Ideally, from my
> perspective, Alice would be paying for her PDP directly but the payment for
> storage, security, and similar policy enforcement services could be bundled
> with the various services Alice is purchasing, for example, a connected car
> or a COVID test.
>
> From an app developer's perspective, they will be building to a standard
> storage model without knowing whether the storage is owned by Alice or just
> controlled by Alice's PDP.
>
> - Adrian
>
>

-- 
This communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.