I like Julians explanation that appears to be based on the roles
of business entities rather than the roles of technical solution
components as the SoC proposed by Adrian.
To me SoC should ensure what Doc phrased here a long time ago:
https://blogs.harvard.edu/vrm/tag/first-party/
"Fourth parties also need to be substitutable. They need
service portability, just as the customer needs data
portability between fourth (and other) party services. That
way whatever they can provide can be swapped out by the user, if
need be."
This means that services like Digi.me that leaves the data
controller role to the individual may have agreements with 2. and
3. parties as long as they are transparent to the user. But it
means that a user may need to substitute the 4. party if he/she
should decide to switch to another 2. party.
4. party services like recommender and relationship management
services on the other hand naturally cannot coexist with any
contractual relationship between a 4. party and any 2. or
individual 3. parties. 4. parties may only facilitate
interactions (anonymously or identified) between 1. and 2. parties
following instructions from the 1. party. This is evidenced by the
huge amount of claimed 4. party "comparison services" that
overwhelmingly have turned out to be concealed 3. party services.
And any separation of roles at the technical level would not
prevent this from happening.
So SoC may have different implications depending on the nature of
services.
Once appropriate SoC has been determined at the business layer,
then it is up to technical standards to ensure that:
* that these concerns including - also legal and ethical
requirements - can be enforced by technology rather than policy
* service portability as well as data portability can be
implemented as required to support the business layer SoC in easy
and nondiscriminatory ways.
/Henrik
Den 01-03-2020 kl. 16:57 skrev Julian
Ranger:
Adrian,
Re
“the pushback is that no private business wants to be
strictly a data controller and forego access to the data
itself as part of their business model”
Some businesses, i.e. digi.me, want to be
neither a data controller nor have access to the data itself –
and that is ultimately the right answer. Don’t see, touch ro
hold the data. Now whether current implementations (ours
included) meet you strict definition of SoC I don’t know, but
to me it is clear that the individual’s data stores should
only be handled by software that the individual chooses to run
and that processing should sit within thinteh inidividual’s
domain (until such time as the individual specifically allows
data to leave their domain).
Jules
This is a good thing. There’s
some overlap between the Solid folks and those of
us working on SSI standards. Although they don’t
say it publicly, I’ve been assured that Inrupt
will implement and respect what I call Separation
of Concerns standards.
I saw the same potential synergies.
Separation of Concerns means that the
data controller can be specified by the data subject
separately form the data storage or other data
processors. UMA2 can already do that and it’s likely
that the upcoming IETF OAuth3 standards will also
support SoC. A pod would then be a special case of a
co-located controller and storage.
Our HIE of One Trustee project has
always done this. We keep separate github repos for the
two separate concerns in order to demonstrate the
standards that connect them and to highlight gaps in the
standards that still need improvement.
Defining agency as requiring SoC
seems to be controversial. There’s pushback because the
standards are immature. I suspect another, unstated
reason for the pushback is that no private business
wants to be strictly a data controller and forego access
to the data itself as part of their business model.
Sounds right.
I’m curious what others on this list
think about defining agency in terms of SoC.
My own small thought on it (having not
thought or known enough about it, so far) is that it makes
sense. Given the ease of data spread—with lost personal
agency in the midst—it's important to keep ambiguities
minimized and separate responsibilities clear.
Doc
This is an important
development in the global context of
giving agency to individuals. Here is my
current list of related initiatives. Note
that all of these are works-in-progress.
In no particular order:
The common thread
across all of these is an authorization
server acting on behalf of a data subject.
This is a very different model from GDPR,
HIPAA, CCPA, the proposed India Personal
Data Protection Bill or the other 9
privacy bills being considered in
Washington.
Thanks for bringing
this to our attention.
This is squarely my
area (by way of Descant). I'm a bit
crunched at the moment so not able to
provide a thorough analysis relative
to VRM but if you think back to
everything I've said in past VRM days
as well as on these threads, it claims
to provide a data facilitator platform
congruent with all that working code
I've been sitting on for much too
long!
First, thoughts on
the article. Then below that, a
reference to the Equifax announcement
yesterday.
A couple
characteristics that fit the VRM way,
and that are at least implied in the
article:
-
It revisits the flows of data for
credit analysis "through the eyes
of" the subjects of the data. It's
always important to question the
extent of this agency when it's
banks rolling out the solution but
the spirit of subject-driven data
flows seems to be present.
-
It addresses a gap in data pipeline
management on a narrower basis than
will be necessary to scale and than
we offer via Descant. See the
specific reference to an
India-specific requirement that
financial data be reported in a
standard, machine-readable format.
More on this below.
-
It suggests consents will be easier
to understand because data subjects
can choose to share portions of
data. This is a very big challenge
and one we've largely solved by
enabling UI/UX that spreads out
consents across touchpoints. Easier
to provide for context-based consent
in that manner. It's not clear that
India is thinking in these terms.
Indeed the intent seems to be that
fintech startups will build apps on
top of the platform. Unless there
are constraints on the spirit and
intent of such apps, they could be
heading back to opacity with little
opportunity to pull it back. Also,
more on this below.
Data pipeline
management:
Of all the big
data challenges addressed over the
past decade, pipeline management has
only recently popped up as a
significant area. I have only seen
developments (and patent filings)
for pipelines within enterprises.
The essence is that applying
transformation, processing, and
governance to data while in motion
streamlines its path to insights. As
the category implies, it's a more
fluid approach to data management
for sure as compared to the old ETL
model and arguably data lakes.
A facilitator
platform that replaces credit
bureaus will need to management
multiple pipelines, each potentially
presenting different levels of
privacy-sensitivity and latency
concerns. The solution announced by
this article is a reasonable start
but not as extensive as would be
needed to truly replace an Equifax.
I didn't see a plan to, say, open
source the system so extensions for
additional data pipelines could
emerge.
Note that this
data challenge is not obviously
about privacy but it is critical if
the goal is to replace intermediated
data solutions. This is a good a
place as any to include a link to an
opinion in yesterday's NYT about the
indictment of Chinese hackers for
the Equifax breach. Author makes the
point that the whole model
underlying Equifax and data brokers
is the problem. And that is a more
complicated data pipeline problem
than consents.
Context-based
consent etc:
Just adding a
short note that I've been
studying recent efforts to add
language to open source licenses
that encompasses privacy, data
rights, and/or human dignity. As
far as I can see, this is all
new territory. In the
"humanitarian license," the
author combines language from
the MIT open source license with
language out of the UN's
declaration of human rights. So
far OSI seems poised to reject
it as a "blessed" open source
license. NYU School of Law also
has some similar projects
underway.
I care about
this because when I think about
open sourcing the data-sharing
platform of Descant, I worry
much more about extensions in
conflict with the ethos of
people in charge of their own
data than specific uses of the
source code. This goes to my
concern that opening up for
fintech startups would be
problematic if there's no way to
police data usage.
Again, this
is all off the top of my head.
The title is correct that it is
better than the US but then we
are a dark and surveilled
country headed for very bad days
unless we can get a grip.
Let me know
of any questions/afterthoughts.
--
LaVonne
Reimer, Founder
Lumenous
503-720-0690 (cell)
lavonnereimer (skype)
www.lumenous.net