[OASIS Issue Tracker] (COEL-80) Clarification in RPE for technology provision.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/COEL-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63479#comment-63479 ] 

David Snelling commented on COEL-80:
------------------------------------

Posting on behalf of Joss so we have it all in one place:

_____________________________________________
From: Joss Langford 
Sent: 15 September 2016 11:42
To: 'OASIS Issues Tracker' <workgroup_mailer@lists.oasis-open.org>; coel@lists.oasis-open.org
Subject: RE: [coel] [OASIS Issue Tracker] (COEL-80) Clarification in RPE for technology provision.


My understanding of the underlying issue is that Fujitsu (and therefore any other Data Engines) would have the opportunity to launch better services faster if they had the capability to extend their role beyond that of Data Engine alone. The challenge is to allow this within the COEL ecosystem without comprising the core principles.

The first key principle is the separation of DIPI and behavioural data. In the times before Operators we had to achieve this with a separation of Service Provider and Data Engine. Now that we have Operators there is a different route to achieve this. Currently a Service Provider can also be an Operator. I believe that the suggestion is that a Service Provider could also be Data Engine but not all 3.

There is some confusion within the RPE (and probably PIA) between ‘Roles’ and ‘Actors’. I think we need to tidy up the language whatever we do so that it is clearer that ‘Actors’ can have multiple ‘Roles’.

I can see that this approach provides more flexibility in the ecosystem and I don’t necessarily think that it is the wrong thing to do but we need to look at the possible negatives:
•	I think the additional of another role undermines quite a bit of the PIA work and is unnecessary with the clarification of ‘Actors’ an ‘Roles’. I have described below the existing role that would encompass ‘Service Enablers’.
•	If a Data Engine were also to take on the role of the Service Providers they would become data controllers (even though they do not have DIPI) as they are specifying the purposes and types of data collected.
•	A Service Provider with their own Data Engine is much more vertically integrated and so data sharing becomes more difficult – it will not be possible for competing Service Providers to use the same pool of behavioural data. Coelition would probably want to place FRAND terms on its Data Engines.
•	The IDA currently only allows Data Engines to check, not create UPKs. The same organisation would be able to do both – opening the great possibility for the organisation to take a control position in the ecosystem.
•	There may be a loss of transparency in the ecosystem from a Consumer’s perspective.
•	The change would degrade the privileged position held by the Data Engine. Service Providers who use separate Operators would be able to stand-up their own Data Engines.
•	Service Providers who stood up their own Data Engines would, invariably, be less experienced and increase the security risks for the whole ecosystem.
•	A combined Data Engine / Service Provider would not have the same cross-jurisdiction flexibility as a fully separated system.
•	Although we can maintain the principle of atom and DIPI separation, we would lose the separation of the purpose specification and holding of behavioural data. This will open up significant concerns that a single organisation will be tempted to use the data beyond the original purposes behind closed doors (the Service Provider has the right to explore the data for specific individuals in a way that the Data Engine does not).
•	The combined Data Engine / Service Provider approach also allows for a service embodiment with only 1 Coelition member so there is no peer oversight – central to our model of ecosystem trust.

I think my biggest concern is that the role of the Operator is not strong enough to stand against a combined Data Engine / Service Provider. By design, Operators do not have to be members of Coelition and so have restricted access. The transparency and interoperability provided by the MMI and PQI interface specifications are completely lost with a combined Data Engine / Service Provider.

The PIA and current specification allows a Data Engine to design and implement a Service Providers’ offering but just requires that is deployed within a different Actor’s facilities (Service Provider or Service Provider / Operator). There is nothing to prevent the IP behind the Service Providers’ system being owned and licenced from the Data Engine – this is in fact the case with most client applications.

I believe the issue of the ‘Service Enablers’ is somewhat separate and I agree that is needs clarifying. In the PIA methodology that we share with the ICO, we had roles described for actors that do not hold personal information so that we could be clear that were no data controllers ‘hidden’ in the architecture. My preference would be to use this term with the definition modified as needed (see below). Actors carrying out this role do not need a description in the RPE if they are not delivering Coelition services but we may wish to add one.

Technical Service Developer:
A developer of software for managing data or services within the ecosystem, who do not handle Coelition services or personal data. These include: app developers for Service Providers, development agencies that create Service Provider or Data Engine or Coelition infrastructure. It could be that a Data Engine acts as a Technical Service Developer to create software infrastructure that is then run by one of their Service Providers. Technical Service Developers may be members of Coelition if they wish to use the trademarks to display that they conversant with the Coelition ecosystem and the development of software within it.

Hardware Developer:
A developer of hardware (such as devices) which are compliant with COEL protocols for use by Service Providers and Operators.

Service Provider’s agent, distributor or vendor:
Entities that provide Service Providers with market reach to access Operators and Consumers.


Lastly, the role of the Associated Service Provider is probably needed as (I believe) that they are ‘data controllers in common’ rather than ‘joint data controllers’. I am awaiting some clarification on this.

Best regards
Joss




> Clarification in RPE for technology provision.
> ----------------------------------------------
>
>                 Key: COEL-80
>                 URL: https://issues.oasis-open.org/browse/COEL-80
>             Project: OASIS Classification of Everyday Living (COEL) TC
>          Issue Type: Improvement
>         Environment: RPE
>            Reporter: David Snelling
>
> A while back we separated Service Provider and Operator to clarify the roles of those that provide technology and these that deliver services directly to consumers. While the current roles and rules would allow a Data Engine to provide something like a Service Provider tool kit, it is not as transparent as it should be.
> The proposal is for changes to the RPE to clarify this possibility.
> See email sent to the list.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)