Re: Secure Data Hubs specification released

Speaking form a privacy perspective:

Can someone help me understand how the "data hub controller" works? Most of
what I see is about the storage agent and maybe the storage provider. I
imagine that the storage agent and provider entities are 'data processors"
under GDPR, liable for security but not privacy. The GDPR data controller
role is where privacy comes in.

From the controller (and privacy) perspective a Requesting Party brings:
- credentials,
- a scope of data requested, and \
- a description of proposed data use.

The controller may:
- issue an authorization token matched to a particular data processor
- request additional credentials
- modify the scope of the request
- fail because it doesn't understand the data use or doesn't agree with the
credentials / scope / use triplet.

For privacy by default, the controller should not actually see or touch the
data itself although, of course, a security breach at the controller would
allow an accomplice to see the data.

Also, the focus of the document on encryption makes privacy analysis more
difficult. It would be much easier to understand what's going on if
encryption was kept in the DID / VC documents and as a separate document
for the storage agent and providers. The OAuth specs are much simplified by
the assumption of TLS for all messages. Can TLS or the equivalent be used
the same way in the SSI designs or do we need to factor things differently?

Adrian



On Tue, Jul 9, 2019 at 12:11 PM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> > This topic is being raised 18-24 months after serious
>> > standardization work began in other channels, and the scope of the
>> > spec draft is a step backward. This isn't a recipe for alignment
>> > around interop.
>>
>> My understanding was that Aries and DIF were not standards setting
>> organizations? They are implementation organizations. W3C, IETF, Oasis,
>> ISO... those are the standards setting organizations.
>>
>
> I want to challenge your mental model a bit.
>
> First of all, can we agree that there is no such thing as a "standard
> setting" organization? There are Standards Development Orgs (SDOs) that
> *develop* standards, but whether they are set as relevant standards in the
> mind of the world is something that comes about through market forces,
> world consensus, and history--not through the actions of any org. SDOs
> often wish they could "set" standards, but the "D" in their acronym is
> actually more accurate. Two of the ISO standards I worked on in the 90s
> enjoyed brief surges of relevance but have long since been ignored. The
> world set a different standard from the SDO.
>
> Secondly, implementation communities have different degrees of formality
> to what they do. By making the strong contrast between implementation and
> SDO, it sounds like you are assuming that implementation is pretty
> different from developing standards, and has very little formality insofar
> as consensus specs are concerned--the formality all begins when an SDO gets
> involved.
>
> DIF does style itself as a an "implementation" org, IIRC. However,
> Hyperledger Aries doesn't use that term. It calls itself an open source
> "project" with a mandate/scope that includes developing an implementation
> but also globally relevant specs that drive it. This is quite far away from
> the loose approach to implementation that best fits your dichotomy. There
> are approximately 50 Aries RFCs
> <https://github.com/hyperledger/aries-rfcs/blob/master/index.md>--each of
> which is a formal specification that has a vetting process, a status, and a
> lifecycle. Many of them have multiple reference implementations in
> codebases from independent orgs. There are test suites, corpuses of bugs
> and improvements, PRs against the specs, and community meetings where those
> specs get debated and refined. Aries doesn't consider itself an SDO, but it
> also doesn't consider itself just a loose confederation of coders who might
> produce semi-cohesive stuff. Is incumbent on an SDO that picks up the
> thread of such work to cite prior art in detail, and to grapple with
> it--not just mention it in passing as "implementation" while proposing a
> work item that starts over. This is especially the case when the corpus of
> prior art is substantial, formal, directly related to the problem at hand,
> and highly interlinked and conceptually cohesive.
>
>

-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/