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

*From:*Doc Searls <anitadrink@gmail.com> *Sent:* 24 February 2020 20:02 *To:* Adrian Gropper <agropper@healthurl.com> *Cc:* Tim Reiniger <tsreiniger@gmail.com>; LaVonne Reimer <lreimer@lumeno.us>; ProjectVRM list <projectvrm@eon.law.harvard.edu>; wg-uma@kantarainitiative.org WG <WG-UMA@kantarainitiative.org> *Subject:* Re: [WG-UMA] [projectvrm] A ... not sure what, exactly ... development in India

On Feb 24, 2020, at 11:49 AM, Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>> wrote:

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

- Adrian

On Mon, Feb 24, 2020 at 4:26 PM Tim Reiniger <tsreiniger@gmail.com <mailto:tsreiniger@gmail.com>> wrote:

Adrian,

Thank you for compiling this great list! If you haven't seen this story, this might become an addition: https://www.schneier.com/blog/archives/2020/02/inrupt_tim_bern.html. See what you think!

Regards,

Tim

On Thu, Feb 13, 2020 at 1:02 PM Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>> wrote:

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:

- US ACCESS Act https://blog.petrieflom.law.harvard.edu/2019/10/24/access-act-points-the-way...

- EU+ MyData Operators https://docs.google.com/presentation/d/1J71J8_8kSiIXmVXSkQbRixmv0rxQXC_d-I6I...

- EU Open Banking and PSD 2 https://www.altexsoft.com/blog/engineering/open-banking-and-financial-apis-h...

- India Open Banking https://www.bloomberg.com/news/articles/2020-01-13/india-s-about-to-hand-peo...

- SSI and Rebooting Web of Trust https://github.com/WebOfTrustInfo/rwot10-buenosaires/blob/master/topics-and-...

- IETF Transactional Authorization https://tools.ietf.org/html/draft-richer-transactional-authz-03

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.

- Adrian

On Tue, Feb 11, 2020 at 2:07 PM LaVonne Reimer <lreimer@lumeno.us <mailto:lreimer@lumeno.us>> wrote:

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.

https://www.nytimes.com/2020/02/10/opinion/equifax-breach-china-hacking.html

*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.

Thanks again Doc!!

LaVonne

503-720-0690

On Tue, Feb 11, 2020 at 1:31 PM Doc Searls <anitadrink@gmail.com <mailto:anitadrink@gmail.com>> wrote:

Headlines:

India’s About to Hand People Data Americans Can Only Dream Of By Saritha Rai January 12, 2020, 11:01 PM EST

•  New system aims to protect data and unlock the credit market

•  India joins a growing movement to give consumers data control

<https://www.bloomberg.com/news/articles/2020-01-13/india-s-about-to-hand-people-data-americans-can-only-dream-of>

Anybody familiar with this want to lay it out in VRM terms (good, bad or otherwise)?

Doc

--

LaVonne Reimer, Founder Lumenous 503-720-0690 (cell) lavonnereimer (skype)

www.lumenous.net <http://www.lumenous.net/>

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> https://kantarainitiative.org/mailman/listinfo/wg-uma