Classification of Everyday Living - OASIS Web viewAlthough called the Classification of Everyday Living, ... There is a single Japanese word for this ... Performing a GET on this URI

Classification of Everyday Living Version 1.0

Working Draft 03

23 January 2017

Technical Committee:OASIS Classification of Everyday Living (COEL) TC

Chairs:Joss Langford ([email protected]), Activinsights LtdDavid Snelling ([email protected]), Fujitsu Limited

Editors:Paul Bruton ([email protected]), Tessella Ltd.Joss Langford ([email protected]), Activinsights LtdMatthew Reed ([email protected]), CoelitionDavid Snelling ([email protected]), Fujitsu Limited

Additional artefacts:The additional artefact is a JSON object that provides the content of the Classification of Everyday Living model:

COEL model V1.0 (http://docs.oasis-open.org/coel/COEL/v1.0/csd02/model/coel.json)Related work:

This specification is related to: TBD Abstract:

This document provides TBD. Status:

This Working Draft (WD) has been produced by one or more TC Members; it has not yet been voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a Committee Note Draft). The OASIS document Approval Process begins officially with a TC vote to approve a WD as a Committee Draft. A TC may approve a Working Draft, revise it, and re-approve it any number of times as a Committee Draft.

URI patterns:Initial publication URI:TBDPermanent "Latest version" URI:TBD(Managed by OASIS TC Administration; please don’t modify.)

Copyright © OASIS Open 2015. All Rights Reserved.All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

COEL-v1.0-wd03 Working Draft 03 23 January 2017Standards Track Draft Copyright © OASIS Open 2017. All Rights Reserved. Page 1 of 56

https://www.oasis-open.org/policies-guidelines/ipr

http://docs.oasis-open.org/coel/BAP/v1.0/BAP-v1.0.docx

http://docs.oasis-open.org/coel/BAP/v1.0/csd01/BAP-v1.0-csd03.docx

https://www.oasis-open.org/policies-guidelines/tc-process#standApprovProcess

https://www.oasis-open.org/policies-guidelines/tc-process#committeeDraft

https://www.oasis-open.org/policies-guidelines/tc-process#dWorkingDraft

http://docs.oasis-open.org/coel/COEL/v1.0/csd02/model/coel.json

http://www.fujitsu.com/

mailto:[email protected]

http://www.coelition.org/


http://www.activinsights.com/


http://tessella.com/


http://www.fujitsu.com/


http://www.activinsights.com/


https://www.oasis-open.org/committees/coel/

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Table of Contents1 Introduction......................................................................................................................................... 6

1.1 Objective........................................................................................................................................... 61.2 Summary of key COEL concepts......................................................................................................61.3 Implementations................................................................................................................................ 61.4 Terminology....................................................................................................................................... 61.5 Notational Conventions..................................................................................................................... 61.6 Normative References....................................................................................................................... 61.7 Non-Normative References...............................................................................................................61.8 Glossary............................................................................................................................................ 6

2 A COEL ecosystem (non-normative).................................................................................................102.1 Introduction...................................................................................................................................... 102.2 Roles............................................................................................................................................... 10

2.2.1 Summary of Roles....................................................................................................................102.2.2 Identity Authority......................................................................................................................102.2.3 Date Engine............................................................................................................................. 102.2.4 Service Provider.......................................................................................................................102.2.5 Operator................................................................................................................................... 102.2.6 Consumer................................................................................................................................. 10

2.3 Principles of Operation of a COEL ecosystem................................................................................102.4 Ecosystem structure........................................................................................................................10

2.4.1 Relationships between actors..................................................................................................102.4.2 Data Flows............................................................................................................................... 11

3 COEL by Example (non-normative)..................................................................................................123.1 Setting up a consumer facing health care service with COEL.........................................................123.2 Setting up the Data Engine – Service Provider – Operator handshakes.........................................123.3 Registering a Consumer.................................................................................................................. 123.4 Getting Consent.............................................................................................................................. 123.5 Delivering Service Journey..............................................................................................................123.6 Etc................................................................................................................................................... 12

4 The Classification of Everyday Living................................................................................................134.1 Introduction...................................................................................................................................... 134.2 Knowledge Base............................................................................................................................. 134.3 COEL Data Model Specification......................................................................................................134.4 Methodology.................................................................................................................................... 134.5 Principles behind structuring and populating the knowledge base..................................................164.6 Structure of the COEL model..........................................................................................................174.7 Description of the COEL taxonomy.................................................................................................204.8 Visualising the COEL model............................................................................................................214.9 Principles for version control of COEL model..................................................................................214.10 Permanent location of COEL JSON artefacts................................................................................23

5 The Behavioural Atom....................................................................................................................... 245.1 Introduction...................................................................................................................................... 245.2 COEL Behavioural Atom Specification............................................................................................24


5.3 Behavioural Atom Examples...........................................................................................................246 Security............................................................................................................................................. 25

6.1 General technical principles:...........................................................................................................256.1.1 Internet..................................................................................................................................... 256.1.2 Authentication..........................................................................................................................256.1.3 Pseudonymous Keys...............................................................................................................256.1.4 Userids and passwords............................................................................................................25

6.2 Ecosystem security diagram and analysis.......................................................................................267 Minimal Management Interface.........................................................................................................28

7.1 Introduction...................................................................................................................................... 287.2 COEL Minimal Management Interface Specification (MMI).............................................................28

7.2.1 Authorization Protocol..............................................................................................................287.2.2 Information Request................................................................................................................. 28

7.2.2.1 Example (non-normative)....................................................................................................................297.2.3 Service Provider: Create New Operator...................................................................................29

7.2.3.1 Example (non-normative)....................................................................................................................307.2.4 Service Provider: Retrieve Operator List..................................................................................307.2.5 Service Provider: Retrieve Consumer List................................................................................307.2.6 Service Provider: Forget Consumer.........................................................................................307.2.7 Operator: Create New Consumer.............................................................................................307.2.8 Operator: Assign a Device to a Consumer...............................................................................30

8 Behavioural Atom Protocol Interface.................................................................................................318.1 Introduction...................................................................................................................................... 318.2 COEL Behavioural Atom Protocol Interface Specification (BAP).....................................................31

8.2.1 HTTP Protocol..........................................................................................................................318.2.2 Media Types for Messages......................................................................................................318.2.3 Operations................................................................................................................................ 318.2.4 Security.................................................................................................................................... 318.2.5 Exceptions................................................................................................................................ 31

9 Public Query Interface....................................................................................................................... 329.1 Introduction...................................................................................................................................... 329.2 COEL Public Query Interface Specification (PQI)...........................................................................32

9.2.1 Authentication and Authorisation..............................................................................................329.2.2 Query Operation....................................................................................................................... 329.2.3 Segment Data.......................................................................................................................... 32

10 Identity Authority Interface................................................................................................................3310.1 Introduction.................................................................................................................................... 33

10.1.1 Overview................................................................................................................................ 3310.2 COEL Identity Authority Interface Specification (IDA)....................................................................34

10.2.1 Authentication and Authorisation............................................................................................3410.2.2 Information Request...............................................................................................................35

10.2.2.1 Example (non normative)..................................................................................................................3510.2.3 PseudonymousKey endpoint..................................................................................................35

10.2.3.1 Example (non-normative)..................................................................................................................3610.2.4 PseudonymousKeyBatch endpoint........................................................................................36

10.2.4.1 Example (non-normative)..................................................................................................................37


10.2.5 Validation endpoint................................................................................................................. 3810.2.5.1 Example (non-normative)..................................................................................................................38

11 Privacy-by-Design Implementations (non-normative)........................................................................4011.1 Principles....................................................................................................................................... 40

11.1.1 Data Separation Principle (P1)...............................................................................................4011.1.2 Data Atomisation Principle (P2).............................................................................................4011.1.3 Atomised Consent Principle (P3)...........................................................................................4011.1.4 Separation of Competence Principle (P4)..............................................................................4011.1.5 No Conflict of Interest Principle (P5)......................................................................................4011.1.6 Active Support Principle (P6).................................................................................................4111.1.7 Transparency Principle (P7)...................................................................................................41

11.2 Actors, Roles & Responsibilities....................................................................................................4111.2.1 Identity Authority.................................................................................................................... 4211.2.2 Data Engine........................................................................................................................... 4211.2.3 Service Provider..................................................................................................................... 4411.2.4 Operator................................................................................................................................. 4511.2.5 Consumer............................................................................................................................... 46

11.3 Actor Relationships........................................................................................................................4712 Identity Management (non-normative)..............................................................................................4813 COEL Policies & Adjacencies (non-normative).................................................................................49

13.1 Security standards......................................................................................................................... 4913.2 Consent standards........................................................................................................................4913.3 Identity Assurance standards........................................................................................................4913.4 Quality-of-Service policies.............................................................................................................4913.5 Use Cases..................................................................................................................................... 49

14 Conformance..................................................................................................................................... 5014.1 Conformance Targets.................................................................................................................... 5014.2 Conformance Clause 1: COEL Data Model...................................................................................5014.3 Conformance Clause 2: COEL Behavioural Atom.........................................................................5014.4 Conformance Clause 3: COEL Minimal Management Interface....................................................5014.5 Conformance Clause 4: COEL Behavioural Atom Protocol Interface............................................5014.6 Conformance Clause 5: COEL Public Query Interface..................................................................5114.7 Conformance Clause 6: COEL Identity Authority Interface............................................................51

Appendix A. Acknowledgments................................................................................................................. 52Appendix B. Known Extensions to the COEL Model..................................................................................53Appendix C. Revision History.................................................................................................................... 54


1 IntroductionThis document provides an overview of the structure of the specification and defines the model of the hierarchical taxonomy that provides the holistic framework for measuring everyday living events. The content of the model is defined in the document by a link to the JSON object.

1.1 Objective

1.2 Summary of key COEL concepts

1.3 Implementations

1.4 TerminologyThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in Error: Reference source not found.

1.5 Notational Conventions

1.6 Normative References[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP

14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt. [RFC4627] D. Crockford, The application/json Media Type for JavaScript Object Notation

(JSON), July 2006, http://www.ietf.org/rfc/rfc4627.txt. [RFC7617] J. Reschke, Ed., "The 'Basic' HTTP Authentication Scheme", RFC 7617,

September 2015. http://www.ietf.org/rfc/rfc7617.txt [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version

1.2", RFC 5246, August 2008. http://www.ietf.org/rfc/rfc5246.txt[RFC4122] Leach, P., Mealling, M., Salz, R., “A Universally Unique Identifier (UUID) URN

Namespace”, RFC 4122, July 2005. http://www.ietf.org/html/rfc4122[RFC3339] Klyne, G., Newman, C., “Date and Time on the Internet: Timestamps”, RFC

3339, July 2002. http://www.ietf.org/rfc/rfc3339.txt

1.7 Non-Normative References[Coelition] http://www.coelition.org. [Data to Life] Reed, M. & Langford, J. (2013). Data to Life. Coelition, London. ISBN 978-

0957609402

1.8 GlossaryIdentity Authority (IDA):

Oversees the effective, open running of the eco-system and administers the operation of the IDA service. The IDA service issues and checks unique Pseudonymous Keys that provide security and ensure the interoperability and universality of the ecosystem.


Paul Bruton, 03/01/17,

No longer the right scope.

http://www.coelition.org/

http://www.ietf.org/rfc/rfc3339.txt

http://www.ietf.org/html/rfc4122





Data Engine:Receives, stores and processes Behavioural Atoms. Data Engines provide business-to-business services to Service Providers and other organisations in the form of queries that create Report Data.

Service Provider:Provides the primary link between a Consumer and a Data Engine. They are able to query the atoms held by a Data Engine to develop personalised services for Consumers based on their everyday behaviours. Service Providers will often be consumer facing brands.

Associated Service Provider: A Service Provider that gains access to data collected by another service provider to provide a service to a Consumer.

Operator:Administers contact with the Consumer and holds the directly-identifying personal information (DIPI) needed to engage with the Consumer. An Operator might be an independent app, exist within a Service Provider or be an independent organisation. Operators only receive information from their Consumers and their Service Provider.

Consumer:The generic reference to any individual registered with the eco-system. They might be patients in a healthcare setting, subjects in a trial as well as consumers of a commercial digital service. A Consumer’s primary relationship might be with a Service Provider via a near-invisible Operator or with clearly recognisable Operator that is supported by a Service Provider in the background.

Technical Service Developer:Creates tools, infrastructure and software for managing data or services within the ecosystem, and does 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:Developers of hardware (such as Internet of Things devices) which are compliant with COEL protocols for use by Service Providers and Operators.

Behavioural Atom: The fundamental data type defined and used extensively throughout the COEL ecosystem is Behavioural Atom (Atom). An Atom is a digital representation of an observable event in an individual’s life. It is a small block of self-describing, micro-structured data. Any type of life event can be coded into a Behavioural Atom using the Classification of Everyday Living, a hierarchical taxonomy of decreasing granularity. The individual’s identity is pseudonymised with the directly identifying personal information (DIPI) segregated from the Behavioural Atoms in both storage and transmission. The Behavioural Atoms also code the time and duration of events, how they were observed and where they occurred. The Atom types are described by the Classification of Everyday Living Version 1.0, one of this collection’s specifications.


Ecosystem:

The Ecosystem is defined as ‘the extended set of corporate and individual actors who interact for their mutual benefit via the medium of the specification and under appropriate voluntarily entered into legal agreements’.

Pseudonymous Key:A string formatted as a UUID as defined in [RFC_4122, Section 3] that uniquely identifies pseudonymously, an entity in the ecosystem. The uUnique Pseudonymous Keys are generated by the IDA for use with the ecosystem to provide unique codes for the data and transaction of Consumers, Devices, Operators and Service Providers.

PseudonymousKey: A string formatted as a UUID as defined in [RFC_4122, Section 3] that uniquely identifies

pseudonymously, an entity in the ecosystem. These are used for Consumer, Operator, Service Provider, and Device identifiers.

Directly Identifying Personal Information (DIPI):Static or slow-changing data needed to provide services to a Consumer including, for example: name, date of birth, contact information, medical/insurance numbers, payment details, etc. DIPI specifically excludes all event-based information (Behavioural Data / Atoms). DIPI is information that would be generally known as PII PII (Personally Identifying Information) in a USA context.

Segment Data:Year of birth, gender, home time zone (GMT+/-x) and home latitude to single degree resolution.

Behavioural Data:Data that is coded according to the COEL TC protocols with, as a minimum, a Classification of Everyday Living code, a unique ConsumerID and a timestamp. A single instance is known as a Behavioural Atom or Atom.

Report Data:Data developed from the analysis of Behavioural Data (Atoms) for the purposes of developing insight and information for the provision of value-add services.

Aggregated and anonymised summary data:Data developed from the analysis of Behavioural Data (Atoms) for the purposes of comparison with Report Data and to deliver business to business services outside a COEL ecosystem.

ConsumerID:An IDA unique Pseudonymous Key for a particular Consumer.

ServiceProviderID:An IDA unique Pseudonymous Key for a particular Service Provider.


OperatorID:An IDA unique Pseudonymous Key for a particular Operator.

DeviceID:An IDA unique Pseudonymous Key for a particular consumer device.

PseudonymousKey: A string formatted as a UUID as defined in [RFC_4122, Section 3] that uniquely identifies

pseudonymously, an entity in the ecosystem. These are used for Consumer, Operator, Service Provider, and Device identifiers.

DateTime:A string formatted as a date-time according to [RFC_3339]. Used to represent the time of an event within the ecosystem.

Authentication Protocol:There are two authentication/authorisation protocols used in the ecosystem. In all cases the underlying connection is protected by server side authenticated transport level security (TLS) [RFC5246]. The two classes are: 1) None: where the TSL connection is anonymous from the client side and therefore there is neither authentication nor authorisation required; and 2) BasicAuth: where the client must both authenticate and be authorised using HTTP Basic Authentication [RFC7617].



We might get challenged over this since BasicAuth is referred to as an ‘authentication’ rather than authorization protocol, but we wrap both of these up in our error codes (e.g. we reject calls by an ‘operator’ to a ‘service provider’ API in the same way we reject any invalid password.

2 A COEL ecosystem (non-normative)2.1 Introduction

2.2 Roles

2.2.1 Summary of Roles

2.2.2 Identity Authority

2.2.3 Date Engine

2.2.4 Service Provider

2.2.5 Operator

2.2.6 Consumer

2.3 Principles of Operation of a COEL ecosystem

2.4 Ecosystem structure

2.4.1 Relationships between actors


2.4.2 Data Flows

The IDA issues a unique Pseudonymous Key to the Operator when the Consumer joins the ecosystem. Once this has been registered with the Data Engine it becomes the ConsumerID and replaces the DIPI in all transactions other than those between the Operator and Consumer.In normal operation the Behavioural Data will stay with the Data Engine unless the Service Provider needs to provide non-standard services or the Consumer makes a specific data request.The illustration shows the Segment Data delivered through the Service Provider, this is accurate when the data is recalled but the Operator sends this directly to the Data Engine when the Consumer is first registered.


Report Data & all services


Segment Data & report requests


Behavioural Data

DIPI, Segment Data

Device

Consumer


Operator

ServiceProvider

DataEngine

3 COEL by Example (non-normative)3.1 Setting up a consumer facing health care service with COEL

3.2 Setting up the Data Engine – Service Provider – Operator handshakes

3.3 Registering a Consumer

3.4 Getting Consent

3.5 Delivering Service Journey

3.6 Etc


4 The Classification of Everyday Living4.1 IntroductionThe Classification of Everyday Living (COEL) is a hierarchical taxonomy of everyday human life events. It comprises three distinct aspects: (a) A Knowledge Base, (b) a Data Model and (c) a Methodology. Together these three aspects facilitate the creation of personal digital services in a wide range of jurisdictions. For further background on the concepts behind COEL see [Data to Life].

4.2 Knowledge BaseA taxonomy is a highly structured form of knowledge base that links two distinct features: a nomenclature (a way of naming things) and a classification (a way to discriminate between different types of thing based on their features or attributes). Although called the Classification of Everyday Living, COEL could more accurately be described as a taxonomy. The COEL is very compact by design. Nevertheless, it’s high level structure and content represents a significant knowledge base. The COEL is a taxonomy of human life events, where an event is defined as: ‘a transient and time-bound activity that can be objectively recorded by a person or a device’. Each such life event is called a Behavioural Atom (see Section 5).The COEL has the ambition of becoming a globally used asset base. A comprehensive and unambiguous taxonomy of human life events. Each of the elements of the COEL Data Model is a meaning. Normative section of COEL structure is in English.From time to time, the COEL will need to expand to incorporate types of observable human events that were not originally included. Perhaps the most obvious source for new types of event are human activitesactivities that are named by a concept that is not ready translated into English. For example, there may be a specific action in Japanese culture that involves a very specific way for someone to Stir Green Tea. There is a single Japanese word for this type of event.The COEL can easily be modified by addition to include this type of event. To make this addition compliant with this specification, the COEL Element MUST contain an English description, but the Element can also OPTIONALLY include the non-English word. ENGLISH (Script, Language).The COEL Data Model WILL NOT be translated by COEL-TC. There is no language flag in version number control. New translation may trigger new concepts.

4.3 COEL Data Model Specification

Although the COEL knowledge base could be structured in many different ways, for ease of human understanding and machine readability the COEL is constructed as a four level hierarchical in the COEL Data Model. The entities in the lower levels of the COEL structure are sub-types of an entity at the next higher level. Thus the lower levels represent progressively more detailed views of life events.

4.4 Methodology

To operationalize the COEL Data Model a methodology is needed to capture, record and communicate data. This methodology is described in the specifications described below.



I think we may want to pull some of these normative statements out into a separate subsection in section 4 that clearly states the rules for COEL extension and version control.

The complete COEL specification can be read from the top down using the table below as a guide. This set of specifications is the minimum requirement to stand up and use a fully functioning COEL compliant system.

Section of document

Description

44. The Classification of Everyday Living

This section of the document. A high level overview of what COEL is, the design principles by which it was constructed and key references. Permanent links to the detailed content of the latest version of the COEL Data Model.

22. A COEL Ecosystem

A top level description of the structures and operations of one type of ecosystem that implements the COEL standard in the manner in which it was originally designed. The section describes the roles that various actors in such an ecosystem would play, the principles by which the ecosystem would work together, the interaction structure between different actors and high level security considerations.

33. COEL by Example (This section is non-normative)

This non-normative section describes how to set up a hypothetical, but realistic, consumer facing health care service implementation using the COEL specification in an ecosystem as outlined in section 22.

910. Identity Authority Interface

A description of the role and operation of the Identity Authority used to create and manage COEL compliant Pseudonymous Keys.

5 The Behavioural Atom and 78. Behavioural Atom Protocol Interface

The means by which COEL event data can be packaged and communicated.

89. Public Query Interface

The minimal requirements of a query interface.

67. Minimal Management Interface

The minimal management interface requirements for operation of the COEL ecosystem.

The different sections of this specification are dependent on each other as can be seen in the visualization below.


Figure 1

The figure below shows in a schematic way how data flows through a fully functioning COEL compliant system.

The IDA issues a unique Pseudonymous Key to the Operator when the Consumer joins the ecosystem. Once this has been registered with the Data Engine it becomes the ConsumerID and replaces the DIPI in all transactions other than those between the Operator and Consumer.In normal operation the Behavioural Data will stay with the Data Engine unless the Service Provider needs to provide non-standard services or the Consumer makes a specific data request.The illustration shows the Segment Data delivered through the Service Provider, this is accurate when the data is recalled but the Operator sends this directly to the Data Engine when the Consumer is first registered.


Report Data &



ServiceProvider

DataEngine


Needs updating: we no longer have an RPE for example

4.5 Principles behind structuring and populating the knowledge baseThe COEL is a new event-based taxonomy for classifying and naming small observable events that form our everyday lives. It was constructed according to a set of design principles, as follows:

Beneath the important surface of cultural differences, everyday human behaviour is surprisingly similar. Our daily lives are made up of a finite number of behaviours which have a natural granularity. A coherent classification of daily events SHOULD work at this level of granularity.

We SHOULD aim to classify, name and code all of the daily behaviours that make up an individual’s life.

To provide a robust and accurate view on daily life, we SHOULD only measure and record human behaviours that are observable. Personal emotions / thoughts become observable events when an individual reports those emotions / thoughts, for example in conversation or a digital diary.

Individual behavioural events SHOULD sit at the bottom of a logically clustered hierarchy. Events that have certain similarities SHOULD be kept together.

Category errors SHOULD be avoided. The COEL SHOULD only include elements of a single category: events, where an event is defined as: “a transient, time-bound activity that can be objectively recorded by a person or device”.

Each element in the COEL SHOULD be clearly distinct from all other elements, that is, they SHOULD be Mutually Exclusive.

In totality, the complete listing of elements in the COEL SHOULD completely cover the whole of everyday human activity, that is, they SHOULD be Completely Exhaustive.

The requirement for the COEL to be both Mutually Exclusive AND Completely Exhaustive (MECE) is particularly demanding. This principle SHOULD be applied to the Class, Sub-class and Element layers of the knowledge base.The principles above have been used to create the COEL. Future developments and versions of the COEL can be expanded both in depth (by adding more detail at the Element level) and breadth (by adding more Clusters and Classes).

4.6 Structure of the COEL model

The most logical way to describe the structure of the full COEL taxonomy is from the top down. However, the fine-grained (and often most interesting) detail is at the bottom of the hierarchy, at the level of the individual elements.

At the top level of the COEL tree there are about thirty Clusters of event categories that go together. The name of each Cluster has been chosen to be intuitive for users of the classification. Some of these Clusters inevitably have a much richer structure than others, since certain aspects of daily life contain more variation than others.

Below the level of the Clusters come three further levels: Class, Sub-class and Element. This structure is shown schematically below.


Report Data &

The principles in section 3.1 above have been used to create the COEL. The COEL exists concretely as a single digital artefact – a JSON format object defining the COEL Clusters, COEL Classes, COEL Sub-classes, COEL Elements and Version. This artefact is held at the permanent OASIS hosted URIs described above. Applications that refer to or use the Classification of Everyday Living (COEL) as a coherent Knowledge Base of daily human events or as a Data Model that embodies that knowledge base MUST refer to this document, its subsidiary documents and the JSON artefact described above.

4.6.1 Artefact Format

The JSON format artefact is a single object with the following fields:

Value Name Description Type

Version The version number of this instance of the COEL model. See below for details.

JSON Array 0..3 of Integers.

Clusters The model Clusters. See below for details. JSON Array of JSON Objects.

Classes The model Classes. See below for details. JSON Array of JSON Objects.


Element 2Element 1

Sub-class 2Sub-class 1

Class 2Class 1

Cluster 2Cluster 1


SubClasses The model SubClasses. See below for details. JSON Array of JSON Objects.

Elements The model Elements. See below for details. JSON Array of JSON Objects.

The Cluster, Class, Sub-class and Element sections of the JSON artefact SHALL all have the same format. Each activity is described fully by its cluster, class, sub-class, and element code numbers. When an activity is being used as a general term (or the detail is not sufficient to describe at all four levels) the upper levels can be used in place of the more specialized descriptions (by providing a zero value for the lower level code numbers). For example, Travel by sports car would be coded as cluster = 22, class = 2, subclass=1, element=1, while travel by land would be coded as cluster = 22, class = 2, subclass=0, element=0.


Name The name of the everyday living activity. String

Cluster The cluster code number of the activity. Integer: 1..99

Class The class code number of the activity. Integer: 0..99

SubClass The sub-class code number of the activity. Integer: 0..99

Element The element code number of the activity. Integer: 0..99

Examples:[ …,


{"name": "Travel", "cluster": 22, "class": 0, "subclass": 0, "element": 0}

…][ …,

{"name": "Travel by car", "cluster": 22, "class": 2, "subclass": 1, "element": 0}

…]

4.6.2 Artefact Style GuideThe string descriptions MUST be formatted with only the first word capitalised with no punctuation, abbreviations or trailing spaces. The Clusters MUST be single words with no spaces.

4.7 Description of the COEL taxonomyTo provide a human readable top level description of COEL, the following table provides names of and longer form descriptions of the COEL Clusters. Note that any apparent logical ambiguities that can be suggested by these top level cluster names can be resolved by moving down in the hierarchy. Although structured for ease of use, the actual coherence of the COEL is guaranteed by the full set of elements.

COEL Cluster Name Long Form Description

Personalcare All self performed activities related to looking after yourself

Childcare Activities related to looking after children

Adultcare Activities related to looking after adults

Housework Cleaning and day to day running of your dwelling

Maintenance Functional upkeep of your dwelling and possessions

Animalcare Activities related to looking after animals

Health Activities related to your own health

Medicine The diagnosis & treatment of ailments

Symptoms Specific events related to symptoms of illness

Eating The consumption of food items

Drinking The consumption of liquid items

Cooking The preparation of food and drink

Sleep Activities related to preparing for sleep and the timecourse of sleep itself

Sports Sports and predominantly physically active hobbies & pastimes

Hobbies Sports and hobbies using vehicles / equipment

Spectator Activities related to watching sports

Pastimes Participatory pastimes (non-physically active)

Observer Spectator pastimes (non-physically active)

Media All activities involving the use of media.


Shopping Activities involved in shopping for physical goods

Service Activities involved in shopping for services

Travel Moving from one place to another for a specific purpose

Communication All methods of socially interacting via communicating face to face, non face to face and to groups & audiences

Device Using electronic devices

Trials Unplanned events which cause irritation or shock

Education Activities involved with the process of acquiring knowledge

Accident Accidents and injuries related to people

Lifestage Life defining events

Lifestyle Events related to lifestyle and type of person

Task Generic work tasks

Work Different types of work

Mind Observable manifestations of emotion

4.8 Visualising the COEL modelAs a gracious and thoughtful service to users of COEL, a dynamic visual representation of the latest version of the full COEL model is provided at [Coelition].

4.9 Principles for version control of COEL modelThe OASIS COEL-TC has adopted a set of conservative principles for modifying the COEL model. Because the structure of the COEL Data Model is a fundamental part of the whole COEL specification, changing the structure of the COEL Data Model should be avoided at all costs. When a non-backwards compatible change is made, e.g. new structure or changing the value of an existing field, this change MUST run through full OASIS process. The Index value 0 in the Version section of JSON artefact MUST be incremented. In addition, a new version of the COEL Specification will be released by OASIS. If the implications of the change in COEL Data Model are minor then MUST be agreed by the OASIS Committee, if more substantial MUST run through full OASIS process.When a backwards compatible change is made, e.g. new fields, this change MUST be agreed by the OASIS Committee. The Index value 1 in the Version section of JSON artefact MUST be incremented. In addition, a new version of the COEL Specification MUST be released by the OASIS Committee.A plain text concordance of version numbers of the COEL Specification and COEL Data Model will be held at URI

Numbering: Mock up an example of if it made sense.

Adopt a single numbering system to flag changes in the Classification of Everyday Living Specification (this document) and the COEL Data Model (JSON artefacts).


Principle is that a single 4 integer digit version number indicates in a harmonised manner possible changes in both Classification of Everyday Living Specification and the COEL Data Model.A Behaviourial Atom Version Field is only compliant if the version number has four positive integers. First pair of digits are version of COEL used to define Atom structure. Second pair are version of COEL Data Model used to code behaviours. The version number in the Behaviourial Atom Version Field SHALL have the following format:

Index Value Description Type

0 Must increment when a non-backwards compatible change is made to the COEL, e.g. new Atom structure or changing key interface properties. MUST run through full OASIS process.

Integer

1 Incremented for any release of COEL that is backwards compatible. MUST be agreed by the OASIS Committee.

Integer

2 Must increment when a non-backwards compatible change is made to the COEL Data Model, e.g. new Data structure or removal of elements. MUST run through full OASIS process.

Integer

3 Incremented for any release of COEL Data Model that is backwards compatible. MUST be agreed by the OASIS Committee.

Integer

For example,

Version Number COEL COEL Data Model

1,2,1,2 Version 1,2 of COEL Version 1,2 of Data Model






Ambiguous. Earlier in this section we use COEL to refer to the classification now we use it to refer to the whole standard (this document?)

27,3,14,-9 Version 27,3 of COEL Non-compliant Atom.

NOTE: If any of the values in these Version Number are negative, then the BehaviourialBehavioural Atom is not compliant with COEL. A COEL compliant Data Engine MAY reject Atoms containing a negative version number without explanation.

4.10 Permanent location of COEL JSON artefactsAll legitimate versions of the COEL JSON artefacts are located at URI: BLAHAs new versions of the COEL Data Model are agreed and new versions of the JSON artefact are formally released by OASIS, they will be added to the URI. For any specific version of the COEL Data Model, the JSON Artefact located at the OASIS maintained URI will be the ONLY compliant Artefact.A change table for the COEL Data Model, the JSON Artefacts will be kept at same URI.



TBC

5 The Behavioural Atom5.1 Introduction

5.2 COEL Behavioural Atom Specification

5.3 Behavioural Atom Examples


6 Security6.1 General technical principles:

6.1.1 InternetSSL/TLS [RFC5246] SHALL be used for all internet communications within the ecosystem. This creates an encrypted channel for the data (Behavioural Atoms, Report data and Pseudonymous Keys – no DIPI) and prevents a third party from reading it in transit. It means that servers like the IDA, Data Engine and any Service Provider/ or Operator systems MUST have SSL/TLS certificates.

6.1.2 AuthenticationSingle factor authentication (userid and password) SHALL be used for all Data Engine and IDA calls with the exception of: [a] submitting atoms which can be done anonymously [b] an Operator registering consumers or assigning devices with the DE.

6.1.3 Pseudonymous Keys IDA generated Pseudonymous Keys SHALL be used as the userids for actors in the ecosystem. These are devoid of DIPI and unique across the ecosystem. Pseudonymous Keys used as Consumer IDs need to be handled carefully since they could be mis-used to pollute the atom collection in a data engine, or to retrieve data about a consumer if a service providers credentials are divulged.

6.1.4 Userids and passwordsDifferent userids MAY be used and different passwords SHALL be used for each embodiment (e.g. for Operator with IDA, Operator with Data Engine, Service Provider with different Data Engines). These SHALL be stored in an encrypted format.


6.2 Ecosystem security diagram and analysis

With reference to above diagram, the following is a summary of the specific requirements for the use or otherwise of secure communication:

1. Operator / IDA: The IDA SHALL require single factor authentication with userid and password for an Operator to access the IDA API.

2. Service Provider / IDA: The Service Provider does not have a role in the IDA API. The IDA MAY provide a mechanism to allow a Service Provider to register new Operators and this mechanism MUST be protected through single factor authentication, at least, with userid and password. The IDA SHALL NOT keep any DIPI for Operators.

3. Operator / Data Engine: The Data Engine SHALL NOT require a password from an Operator when registering a new Consumer or when assigning a new Device to a Consumer.

4. Service Provider / Data Engine:

a. The Data Engine SHALL require single factor authentication with userid and password for a Service Provider to access the Management Interface (MI) and Query Interface (QI)


6.

5.

4.

3.

1.

2.

Operator

ServiceProvider

IDA

DataEngine


These points below are somewhat in conflict with what we say in the other sections (for example IDA does not need 1FA for all of its methods, the service provider _does_ interact with the IDA - to get device IDs, the mechanism for registering operators is not specified, we should put hte requirement for the IDA not to hold DIPI in the IDA section, The MMI registration of operators and device security requirements are specified in the MMI and duplicated here. Really this ought to be a non-normative section with specific normative requirements referred to in each section.

b. Separate credentials SHOULD be used to access the Management Interface (MI) and Query Interface (QI), reducing the likelihood of getting access to both and retrieving Atoms for all of the Service Provider’s Consumers.

c. The data engine MUST use a secondary method to assert the identity of the Service Provider prior to processing a ‘forget’ request for a Consumer since these requests are not reversible.

5. Operator / Service Provider: Where the Operator is a separate entity, it will request reports on Consumers from the Service Provider, but these reports are pseudonymised and contain no DIPI. Where the Operator is a separate entity their communication MUST use single factor authentication with userid and password.

6. Data Engine / IDA: The IDA SHALL require single factor authentication with userid and password for a Data Engine to access the IDA API.


7 Minimal Management Interface7.1 IntroductionThis section defines the Minimal Management Interface (MMI) between the Data Engine and other actors in the ecosystem. It provides an information request operation through which all actors in the ecosystem discover the URLs for all operations on the Data Engine. It provides operation definitions on the Data Engine for use by a Service Provider to register a new Operator, to retrieve a list of existing Operators, to retrieve a list of Consumers associated with a given Operator, to suspend and resume Operators, register and unassign Devices and to assure a consumer is registered. It also provides operation definitions on the Data Engine for use by an Operator to register a Consumer, forget a Consumer and to associate a device with a consumer. This interface represents the minimal requirements of a Data Engine’s management interface, but does not limit this interface to these capabilities. High quality Data Engines may offer more comprehensive management services.

7.2 COEL Minimal Management Interface Specification (MMI)

7.2.1 Authorization ProtocolTo access all Service Provider operations on the Data Engine MMI API, Service Providers MUST use the BasicAuth Authorization Protocol.To assess all Operator operations on the Data Engine MMI API, Operators MUST use the None Authorization Protocol.

7.2.2 Information RequestEvery Data Engine SHALL publish its Data Engine Home URI. Performing a GET on this URI SHALL return general information about the Data Engine as JSON object.

Method RequestBody

Response Status ResponseContent-Type

Response Body

GET /home None 200 (OK) application/json JSON object

Format for the response body JSON object:Name Value Description REQUIRED

AtomsURI String The URI of the Atoms service encoded as a string. Yes

QueryURI String The URI of the Query service encoded as a string. Yes

ManagementURI String The URI of the Management service encoded as a string. Yes

ServerTime Integer Current server time in UTC as a Unix timestamp. YesAtomsStatus String The current status of the Atoms service encoded

as a string. It MUST be one of "Up", "Down", or Yes


"Unknown".

QueryStatus StringThe current status of the Query service encoded as a string. It MUST be one of "Up", "Down", or "Unknown".

Yes

ManagementStatus StringThe current status of the Management service encoded as a string. It MUST be one of "Up", "Down", or "Unknown".

Yes

The JSON object of the response MAY contain additional fields with information about the Data Engine.

7.2.2.1 Example (non-normative)Example request message:

GET /home

Example response message:

HTTP/1.1 200 OK

{"AtomsURI": "https://www.dataengine.com/atoms", "QueryURI": "https://www.dataengine.com/query", "ManagementURI": "https://www.dataengine.com/management", "AtomsStatus": "Up", "QueryStatus": "Up", "ManagementStatus", "Up", "ServerTime": 1470822001}

7.2.3 Service Provider: Create New OperatorCreate a new Operator within the Data Engine and associate it with the requesting Service Provider. Completion of this operation allows the Operator to register new Consumers.If successful, an HTTP status code of 200 OK MUST be returned. If unsuccessful, an HTTP error code SHOULD be returned and a JSON object MAY be returned providing some explanation of the failure. If validation of the OperatorID fails, with a 410 (Gone) error from the IDA, an error 410 (Gone) should be returned.

Method RequestBody


Response Body

POST service-provider/operator

JSON object 200 (OK) None None410 (Gone) application/json JSON object

Content of the request body JSON object:Name Value Description REQUIRED

OperatorID PseudonymousKey

A Pseudonymous Key generated by an IDA and associated with the Operator being registered. Yes

TimeStamp DateTime Time stamp of the OperatorID indicating when Yes


the IDA created this Pseudonymous Key.

Signature String Signature proving that an IDA created this OperatorID. Yes

Content of the response body JSON object:Name Value Description REQUIRED

Reason String An optional description of why the registration failed. No

7.2.3.1 Example (non-normative)

Example request message:POST service-provider/operator

{"OperatorID": "00000000-0000-0000-0000-000000000000", "TimeStamp": "2011-02-14T00:00:00", "Signature":"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="}


HTTP/1.1 410 Gone

{"Reason":"Operator was not valid."}

7.2.4 Service Provider: Retrieve Operator List

7.2.5 Service Provider: Retrieve Consumer List

7.2.6 Service Provider: Forget Consumer

7.2.7 Operator: Create New Consumer

7.2.8 Operator: Assign a Device to a Consumer


8 Behavioural Atom Protocol Interface8.1 Introduction

8.2 COEL Behavioural Atom Protocol Interface Specification (BAP)

8.2.1 HTTP Protocol

8.2.2 Media Types for Messages

8.2.3 Operations

8.2.4 Security

8.2.5 Exceptions



Take information request out of here and into MMI

9 Public Query Interface9.1 Introduction

9.2 COEL Public Query Interface Specification (PQI)

9.2.1 Authentication and Authorisation

9.2.2 Query Operation

9.2.3 Segment Data


10Identity Authority Interface10.1 Introduction

[10.1.1] The Identity Authority (IDA)An Identity Authority (IDA) provides an The Identity Authority Interface (the API) is used to that generate s and subsequently validates a digitally signed unique Pseudonymous Keys to be used in signup to Data Engine services. The IDA does not require any input to generate the Pseudonymous Key.Section 3 of this document describes how the API is used by Operators, Service Providers, and Data Engines to register Consumers or Devices. Section 4 gives details on the API itself.The terms Pseudonymous Key, Data Engine, Operator, Hardware Developer and Service Provider are as defined in [COEL-RPE-1.0].

[10.1.2] IDA Protocol Overview

Figure 2: IDA/Data Engine signup sequence

Figure 1 shows the sequence an Operator MUST follows in signing up a new consumer: obtain a Pseudonymous Key from IDA and then use it to signup with the Data Engine. The Pseudonymous Key is used in all subsequent communications with the Data Engine such as sending data, requesting reports. For each new consumer, the Operator and Data Engine use a separate Pseudonymous Key. Applications that generate input (Behavioural Atoms) for the Data Engine also use the Pseudonymous Key.The signature is used so that the Data Engine can be assured that the Pseudonymous Key is genuine. Rather than using asymmetric key-pairs and distributing a public key and signing algorithm, the IDA provides the means for a receiver of a signed Pseudonymous Key to validate its signature. The Data Engine MUST use this validation mechanism.It is assumed that this transaction is short – Operators only request Pseudonymous Keys when they are needed them and register them shortly afterwards (probably ideally within minutes). The Identity Authority needs to be free to alter the means of signature (if for example it believes the mechanism used internally has been revealedcompromised). If this change happens during a transaction then validation will fail. This is an unlikely event, but parties in the transaction need to be able to manage it:


Data Engines receiving a failed validation code from the IDA MUST pass the failure back to the Operator (see MMI: create new operator).

Operators receiving a failed validation code from the Data Engine MUST discard the Pseudonymous Key and request a new one from the IDA.

If the second attempt also fails, the Operator SHOULD should try once more after a short delay (1-2 seconds) before aborting the attempt to register.

Figure 3: Service Provider registering a batch of DeviceIDs

The IDA also provides a means to generate a batch of up to 1000 Pseudonymous Keys in one request. The batch contains a single signature and the same protocol MUST is be followed for validation: The Service Provider passes the batch to the Data Engine which MUST validates the batch with the IDA. It is expected that the Service Provider will then provide this batch of IDs to a Hardware Developer to be used in devices. (see MMI: <<reference>>). Pseudonymous Keys are primarily intended to represent a consumer in the ecosystem. However, Operators and Service Providers also require keys to identify themselves in their machine to machine interactions. IDA generated Pseudonymous Keys MAY may be used for this purpose since they are devoid of DIPI and unique across the ecosystem.

10.2 COEL Identity Authority Interface Specification (IDA)

The Identity Authority (IDA) API provides a means for Operators and/or Service Providers to generate unique Pseudonymous Keys for Consumers or Devices. A Pseudonymous Key is REQUIRED when an Operator or Service Provider registers a consumer or device with a Data Engine. Pseudonymous Keys are digitally signed so that Data Engines can validate them to ensure they were generated by the IDA and have not been altered.



todo

[10.2.1] Introduction

10.2.1[10.2.2] Authentication and AuthorisationWith the exception of the IDA Information Request, callers MUST use the BasicAuth Authorization Protocol with a userid and password for all interactions with the IDA.The IDA information request requires only the None Authorization Protocol. Where BasicAuth is being used, each userid MUST be assigned to one of the following two roles in the IDA:

Generator: Allowing the caller to generate Pseudonymous Keys Validator: Allowing the caller to validate Pseudonymous Keys

If the userid is unknown to the IDA, or the wrong password is supplied a HTTP status code 401 Invalid username or password SHALL be returned.If a request is made with a userid that is assigned a role that is not authorized to perform that action then the HTTP status code 403 Unauthorised SHALL be returned.

10.2.2 Information RequestEvery Identity Authority SHALL publish its Home URI. Performing a GET on this URI SHALL return general information about the Identity Authority as JSON object.

Method Request ResponseStatus

Response Content-Type

Response Body

GET None 200 (OK) application/json JSON object

Content of the returned JSON Object:Name Value Description REQUIRED

IdentityAuthorityURI String The URI of the Identity Authority service encoded as a string. Yes

ServerTime Integer Current server time in UTC as a Unix timestamp. Yes

IdentityAuthorityStatus StringThe current status of the Identity Authority service encoded as a string. It MUST be one of “Up”, “Down”, or “Unknown”.

Yes

The JSON object of the response MAY contain additional fields with information about the Identity Authority.

10.2.2.1 Example (non normative)Example request message:

GET /home


HTTP/1.1 200 OK



Quotes

{"IdentityAuthorityURI": "https://www.ida.com/api", "IdentityAuthorityStatus": "Up", "ServerTime": 1470822001}

10.2.3 PseudonymousKey endpointThe IDA SHALL provide a PseudonymousKey end-point which provides the means to generate Pseudonymous Keys for users whose API Credentials have the Generator role.The mechanism used to sign the response is periodically changed, so the response SHOULD be passed to the Data Engine shortly after generation or validation can fail.Method Request

BodyResponse Status Response

Content-TypeResponse Body

POST /PseudonymousKey

None 200 (OK) application/json JSON

Any other status None None


PseudonymousKey PseudonymousKey

A Pseudonymous Key generated by the IDA. Yes

TimeStamp DateTime Time stamp indicating when the IDA created this response. Yes

Signature String Signature proving that the IDA created this response. Yes

Status: 200: The operation was successful401/403: The operation failed due to authentication or authorization failure. The caller should

confirm its credentials and retry.500: Internal error, the caller should retry

10.2.3.1 Example (non-normative)Example request message:

POST /PseudonymousKey

Example response messageHTTP/1.1 200 OK

{ "PseudonymousKey": "00000000-0000-0000-0000-000000000000", "TimeStamp": "2011-02-14T00:00:00", "Signature": "SGFDXCTVIVVIFUJUVUYBKYKJHBK=="}



Still need this? Is it normative?

10.2.4 PseudonymousKeyBatch endpointThe IDA SHALL provide a PseudonymousKeyBatch end-point which provides the means to generate a batch of Pseudonymous Keys in one response packet for users whose API Credentials have the Generator role. The request body SHALL contain one parameter: Size. The response SHALL contain three parameters: An array of Pseudonymous Keys; the timestamp at which the response was generated; and a signature that can be used for validation. The IDA SHALL be capable of generating batches of up to 1000 Pseudonymous Keys in each request.

Method RequestBody


Response Body

POST /PseudonymousKeyBatch

JSON 200 (OK) application/json JSON

Any other status None None

Content of the request body JSON object:Name Value Description REQUIRED

Size IntegerThe number of PseudonymousKeys to return in the batch. 1<=N<=1000 Yes


PseudonymousKeysArray of PseudonymousKey

Array of unique keys that can be used to represent devices in the ecosystem. Yes

TimeStamp DateTime Time stamp indicating when the IDA created this response. Yes

Signature String Signature proving that an IDA created this response. Yes

Status codes:200: The operation was successful400: The operation failed due to the request body being malformed or the size being out of range

[1..1000]401/403: The operation failed due to authentication or authorization failure. The caller should


10.2.4.1 Example (non-normative)Example request message


{"Size": 3}

Example response message:HTTP/1.1 200 OK



format this section

{ "“PseudonymousKeys"”: [ "“00000000-0000-0000-0000-000000000000"”, "“00000000-0000-0000-0000-000000000001"”, "“00000000-0000-0000-0000-000000000002"”] "“TimeStamp"”: "“2011-02-14T00:00:00"”, "“Signature"”: "“SGFDXCTVIVVIFUJUVUYBKYKJHBK=="”}

Example request messagePOST /PseudonymousKeyBatch

{"Size": -1}

Example response message:HTTP/1.1 400 OK

API Description


Generate a new signed batch of Pseudonymous Keys. The mechanism used to sign the response is periodically changed, so the response SHOULD be passed to the Data Engine shortly after generation or validation can fail.

The request body SHALL contain one parameter: Size.

Parameter Name Description Type

Size The number of PseudonymousKeys to return in the batch.

Integer: 1 <= n <= 1000

Media type: application/json, text/json

[10.2.4.1] Sample:{“Size”: 1000}

The response SHALL contain three parameters: An array of Pseudonymous Keys; the timestamp at which the response was generated; and a signature that can be used for validation.



??


PseudonymousKeys Array of unique keys to be used to represent a devices in the ecosystem.

Array of String: Each string formatted as a UUID as defined in [RFC_4122, Section 3]

TimeStamp Date and time at which the PseudonymousKey was generated.

String: Formatted as a date-time according to [RFC_3339].

Signature ASCII encoded signature which the IDA will use for validation.

String


Sample:{ “PseudonymousKeys”: [ “00000000-0000-0000-0000-000000000000”, “00000000-0000-0000-0000-000000000001”, “00000000-0000-0000-0000-000000000002”] “TimeStamp”: “2011-02-14T00:00:00”, “Signature”: “SGFDXCTVIVVIFUJUVUYBKYKJHBK==”}

Status: 200: The operation was successful400: The operation failed due to the request body being malformed or the size being out of range

[1..1000]401/403: The operation failed due to authentication or authorization failure. The caller should


The IDA SHALL be capable of generating a batch of up to 1000 PseudonymousKeys.

10.2.5 Validation endpoint

The IDA SHALL provide a Validation end-point which provides the means to validate a signed PseudonymousKey or a signed batch of PseudonymousKeys for users whose API Credentials have the Validator role.Method Request Response Status Response Response


Body Content-Type BodyPOST /Validation JSON 200 (OK) None None

Any other status application/json JSON

API Description

POST /Validation Validates a single signed Pseudonymous Key or a signed batch of Pseudonymous Keys to ensure that they were generated by IDA. The mechanism used for signing is periodically changed. If validation fails, the caller MUST request that the Operator requests a new Pseudonymous Key.

Request The request body format SHALL conforms to the specification of EITHER either the /PseudonymousKey response packet OR or the /PseudonymousKeyBatch response packet. The fields from the IDA response must not be modified or validation will fail.Content of the request body JSON object:Name Value Description REQUIRED

PseudonymousKey PseudonymousKey

A Pseudonymous Key generated by the IDA.Exactly one of these is required.PseudonymousKeys

Array of PseudonymousKey

Array of Pseudonymous Keys generate by the IDA

TimeStamp DateTime Time stamp from the original IDA response. YesSignature String Signature from the original IDA response. Yes

Media type: application/json, text/jsonSample 1 (Single input):{ “PseudonymousKey”: “00000000-0000-0000-0000-000000000000”, “TimeStamp”: “2011-02-14T00:00:00”, “Signature”: “SGFDXCTVIVVIFUJUVUYBKYKJHBK==”}Sample 2 (Batch input):{ “PseudonymousKeys”: [ “00000000-0000-0000-0000-000000000000”, “00000000-0000-0000-0000-000000000001”,


“00000000-0000-0000-0000-000000000002”] “TimeStamp”: “2011-02-14T00:00:00”, “Signature”: “SGFDXCTVIVVIFUJUVUYBKYKJHBK==”}

Response If successful, an HTTP status code of 200 OK MUST be returned. If unsuccessful, an HTTP error code SHOULD be returned and a JSON object MAY be returned providing some explanation of the failure. Content of the response body JSON object:Name Value Description REQUIRED

Reason String Optional description of why the operation failed No

Status: 200: The operation was successful. The Pseudonymous Key or batch of Pseudonymous Keys is

valid. 410: The operation was successful (the request was properly formed and authorized) but the

Pseudonymous Key or batch of Pseudonymous Keys is no longer valid.400: The operation failed due to the request body being malformed. 401/403: The operation failed due to authentication or authorization failure. The caller should



Reason An optional description of why the operation failed.

String:


[10.2.5.1] Example (non-normative)Example request message

POST /Validation

{ "PseudonymousKey": "00000000-0000-0000-0000-000000000000", "TimeStamp": "2011-02-14T00:00:00", "Signature": "SGFDXCTVIVVIFUJUVUYBKYKJHBK=="}

Example response:HTTP/1.1 200 OK

Example request messageCOEL-v1.0-wd03 Working Draft 03 23 January 2017Standards Track Draft Copyright © OASIS Open 2017. All Rights Reserved. Page 40 of 56


Format

POST /Validation

{ "PseudonymousKeys": [ “00000000-0000-0000-0000-000000000000", “00000000-0000-0000-0000-000000000001", “00000000-0000-0000-0000-000000000002"], "TimeStamp": "2011-02-14T00:00:00", "Signature": "SGFDXCTVIVVIFUJUVUYBKYKJHBK=="}

Example response:HTTP/1.1 410 Gone

{"Reason": "IDA could not validate these keys"}

Sample:Example request messagePOST /Validation

{ "PseudonymousKeys": [ "00000000-0000-0000-0000-000000000000", "00000000-0000-0000-0000-000000000001", "00000000-0000-0000-0000-000000000002"],}

Example response:HTTP/1.1 400 OK

{"“Reason"”: "“The input was missing mandatory elements"”}

{“Reason”: “The input was missing mandatory elements”}Status:

200: The operation was successful. The Pseudonymous Key or batch of Pseudonymous Keys is valid.

410: The operation was successful (the request was properly formed and authorized) but the Pseudonymous Key or batch of Pseudonymous Keys is no longer valid.

400: The operation failed due to the request body being malformed. 401/403: The operation failed due to authentication or authorization failure. The caller should



11 Privacy-by-Design Implementations (non-normative)

11.1 Principles

11.1.1 Data Separation Principle (P1)The specification implements a separation of data types: Data Engines keep data on what Consumers do (Behavioural Atoms) and the Service Provider/Operator keeps data on who Consumers are (DIPI). No single organisation holds both sets of data together. This means that it would need a double accidental or malicious disclosure for connected information to be released.

11.1.2 Data Atomisation Principle (P2)Data is deliberately broken down into small chunks of information by the Operator and coded with the Consumer’s ConsumerID (which implies their atomised consent), thus each separate Behavioural Atom has a very low privacy risk. Neither the Operator/Service Provider sees these atoms as raw atoms and can only see composite data from Data Engine under the terms of the specification.

11.1.3 Atomised Consent Principle (P3)Consumer gives informed consent to the Operator under guideline terms set by the specification. Consent allows the Operator to sign up the consumer with a ConsumerID. This ConsumerID is the indicator to Identity Authority and other eco-system actors that the consumer has given appropriate consent. Because each and every Behavioural Atom has the ConsumerID, each atom has that consumer’s consent written into the structure of the data. Removing the ConsumerID from a Behavioural Atom is removing the consent of that individual so the data can no longer be used by either the Operator or Service Provider who signed them up. The time stamp uniquely associated with each Behavioural Atom allows full auditing of this principle.

11.1.4 Separation of Competence Principle (P4)Data Engines are expert data handlers. They know how to run robust, secure and always on cloud based data services; they handle Behavioural Atoms NOT Consumers. Service Providers / Operators are experts at Consumer facing / relevant services and handling DIPI; they handle Consumers NOT Behavioural Atoms. The Identity Authority is expert at overseeing the ecosystem.

11.1.5 No Conflict of Interest Principle (P5)Consumers need to see that there are no conflicts around their data. To ensure this, the Identity Authority acts on behalf of the Consumer in partnership with Operator/Service Provider, Data Engine and regulators.


11.1.6 Active Support Principle (P6)All actors will actively promote the principles of the specification, safeguard the structure of the eco-system and support good data practice for both consumers and enterprise.

11.1.7 Transparency Principle (P7)The roles and identities of all the actors in the eco-system who are working together on behalf of a Consumer will be clear and visible to that Consumer.

11.2 Actors, Roles & Responsibilities

These roles will be performed by a number of actors that create the ecosystem. Actors may have multiple roles but certain combinations are not permissible as described in the Technical Requirements and the table below. The table shows all the possible role pairs; an actor may have more than two roles but every paring must be permitted.

Role 2

IDA Data Engine

Service Provider

Operator Consumer Technical Service

Developer

Hardware Developer

Role 1

IDA

Data Engine

Service Provider

Operator

Consumer

Technical Service

Developer

Hardware Developer


11.2.1 Identity AuthorityTechnical requirement Guiding principles & notes

SHALL Maintain an always-on IDA service that will generate or validate unique Pseudonymous Keys for Data Engine, Service Provider & Operator

P4

Be a non-profit legal entity P5

Provide its services on a fair, reasonable and non-discriminatory basis

P5

Provide Consumers with information about the operation of the eco-system free of charge

P5 & P7

SHALL NOT

Act as a Data Engine or Service Provider (other than for the purposes of providing a limited ‘sandbox’ test environment)

P4 & P5

Store Behavioural Atoms P4 & P5

Hold any Consumer’s directly identifying personal information (DIPI)

P5

MAY Request Data Engine support to deliver population-level insights for public information and the purposes of marketing the specification

P6

Make a query on Data Engines to ensure a specific ConsumerID has been forgotten

P7This allows the Identity Authority to audit the forgetting process.

Provide Consumers with information about their status within the eco-system, i.e. ‘known’ or ‘forgotten’ and only by ConsumerID and not DIPI.

P5 & P7

Provide audit services to Data Engine, Service Provider, Operator and regulators

P6

11.2.2 Data EngineTechnical requirement Guiding principles & notes

SHALL Provide secure storage of Behavioural Atoms for a period to be agreed with the Service Provider in line with the Consumer consent

P2 & P3

Provide minimal interface services for Service Providers to process joiners, movers, and leavers (e.g. Operator & Consumer trees, registration, ID re-allocation, forgetting)

P4


Provide minimal interface services for querying Behavioural Atoms by registered Service Providers

P1

Maintain an always-on, single entry point for uploading Behavioural Atoms to the Data Engine

P4

Receive Behavioural Atoms from Consumers or Devices registered with their Operators that conform to the specification free of charge

Receiving data is a minimal requirement for a Data Engine; commercial services apply to the use and processing of data.

Provide information to the Service Provider about the location and security of the infrastructure used in the delivery of services

P7

SHALL NOT

Link Behavioural Atom data to directly-identifying personal information (DIPI) from external sources

P1

Link Behavioural Atom data directly to external data storage if such link might directly identify Consumers

P1

Hold any Consumer’s directly identifying personal information (DIPI)

P1

Act as a Service Provider or Operator itself

P1 & P4

Request more than the Segment Data as defined in the specification (gender, year of birth, time zone & latitude to 0 decimal points) on registration of a Consumer

P1

Knowingly receive DIPI P1Levy unreasonably punitive charges for the complete download of stored Behavioural Atoms

Supports EU data protection and an open, competitive eco-system.

Utilise IDA unique Pseudonymous Keys outside of the ecosystem

P1

MAY Add non-personal data to the atom store to deliver enhanced services (e.g. local weather data)

P1While Behavioural Atoms cannot be linked out, additional information can be linked in.

Use suitable aggregation techniques rendering the data non-personal to provide indirect services to parties other than contracted Service Providers

P1 & P6

Host multiple Service Providers


11.2.3 Service ProviderTechnical requirement Guiding principles & notes

SHALL Ensure that their Operators have the minimum standard consent from Consumers

P3

Secure additional consent from Consumers when sending personal information outside the eco-system

P3 & P6

When sending Behavioural Atom information outside the eco-system, remove the ConsumerID and replace with DIPI

P6This ensures that information that has left the eco-system can be clearly identified.

Ensure that their Operators follow the specification

P6

For any one purpose and at any one time, have only one Data Engine

Avoids potential data loss for the consumer and ensures the complete audit map of the eco-system.

On a request from a Consumer, supply (or require associated Operator to do so) all DIPI, Segment Data, Behavioural Atoms and any stored Report Data

P2Basic tenet of EU data protection.

On a request from a Consumer to be forgotten, remove or render DIPI to be non-personal

Basic tenet of EU data protection.

On a request from a Consumer to be forgotten, instruct their Data Engine to remove or render data to be non-personal

P2 & P3

On a request from an Operator or Consumer, provide the identity of the Data Engine

P7

Notify Consumers (via Operators) of any mergers and acquisitions or other changes that would result in a change of control over the Consumers’ data

P7

Check the credentials of an Operator every time a request is made to release data for a ConsumerID

Security.

Ensure that all Operators within a specific embodiment are working under equivalent terms (e.g. consent, purpose, retention periods etc.).

P7

Use different passwords to interact with different actors in the ecosystem (within the same service embodiment).

Security.


Use a different ServiceProviderID for every instance of a service embodiment in which they are an actor

Security.

Hold ConsumerID Pseudonymous Keys with the same security level as DIPI.

Security.

Provide a secure interface to Operators such that communication is done in an appropriate manner with basic authentication as a minimum.

Security.

SHALL NOT

Receive Behavioural Atoms directly P1

Send DIPI to a Data Engine P1

Share DIPI with another Service Provider without additional consent from the Consumer

P3

MAY Transfer its operations between Data Engines

Supports open, competitive eco-system.

Host multiple Operators

An Associated Service Provider is a Service Provider that gains access to data collected by another service provider to provide a service to a Consumer. To do so, the Consumer MUST give consent to the Associated Service Provider to access the data collected by the original Service Provider. An Associated Service Provider has no right to grant a third-party any access to the data held by the original Service Provider. All of the technical requirements on a Service Provider above will apply to an Associated Service Provider except for Consumer requests to access or modify data held by the Data Engine which MUST be passed to the original Service Provider that collected the data.

11.2.4 OperatorTechnical requirement Guiding principles & notes

SHALL

Provide a mechanism for the consumer to access their ConsumerID.

P7This allows the Identity Authority to audit the ‘forgetting’ process.

Ensure that the minimum standard consent is given by Consumers - freely, specific & informed

P3

For any one purpose and at any one time, have only one Service Provider

Avoids potential data loss for the consumer and ensure the complete audit map of the eco-system.

Clearly identify the Service Provider to the Consumer

P7

Notify Consumers of any mergers and acquisitions or other changes that would result in a change of control over the Consumers’ data

P7


Hold ConsumerID Pseudonymous Keys with the same security level as DIPI

Security

Use different passwords to interact with different actors in the ecosystem (within the same service embodiment).

Security.

Use a different OperatorID for every instance of a service embodiment in which they are an actor

Security.

SHALL NOT

Store Behavioural Atoms other than for the purposes of transmission to the Data Engine.

P1

Send DIPI to a Data Engine P1

Share DIPI with another Operator or Service Provider without additional consent from the Consumer

P3

Utilise IDA unique Pseudonymous Keys outside of the ecosystem

P1

MAY Host multiple Consumers

11.2.5 ConsumerTechnical requirement Guiding principles & notes

MAY Request to be ‘forgotten’ in the eco-system


Request the Identity Authority to audit their status in the eco-system

P5 & P7

Request the Service Provider to supply their DIPI, demographic information and all Behavioural Atoms



11.3 Actor Relationships


Transparent Transparent

Device

Consumer

Possible Member

Contract Consent

CommercialContract

CommercialContract

Licence

Licence

LikelyMember

Likely Member

Operator

OASISCOEL TC

ServiceProvider

IDA

DataEngine

12Identity Management (non-normative)

The COEL specification provides tools for the collection and processing of the behavioural data of individuals and therefore identity management will be essential to any overall system implementation. This specification provides a Unique Pseudonymous Key (UPK) that links all data for a specific Consumer. There is no requirement for a Consumer to have only one UPK and so, in true identity terms, a UPK links data for a profile. The ability of Consumer to maintain multiple profiles is an important method by which they can control their identity. Outside the scope of this specification, multiple UPKs (profiles) could be maintained formally or informally by a Consumer to control their personal data and visibility of combinations of their data to any Service Provider.The UPK is a private subject key where the Operator has the responsibility to validate, assure and authenticate the identity of the Consumer to a level appropriate to the application. There is no requirement for the Consumer and Operate to initiate their relationship with a strong identity negotiation. The UPK provides a reference for the collection of data under an ‘assertion of sameness’ principle that may or may not lead to a strong identity negotiation.


13COEL Policies & Adjacencies (non-normative)13.1 Security standards

13.2 Consent standards

13.3 Identity Assurance standards

13.4 Quality-of-Service policies

13.5 Use Cases


14Conformance14.1 Conformance TargetsSections 4, 5, 6, 7, 8 and 9 contain the following implementations that are subject to compliance:

COEL Data ModelCOEL Behavioural AtomCOEL Minimal Management Interface (MMI)COEL Behavioural Atom Protocol Interface (BAP)COEL Public Query Interface (PQI)COEL Identity Authority Interface (IDA)

14.2 Conformance Clause 1: COEL Data ModelA data object conforms to this specification as COEL Data Model if it satisfies all the statements below:

(a) It is valid according to the structure and rules defined in section 4.3 "COEL Data Model Specification".

14.3 Conformance Clause 2: COEL Behavioural AtomA data object conforms to this specification as COEL Behavioural Atom if it satisfies all the statements below:

(a) It is valid according to the structure and rules defined in section 5.2 "COEL Behavioural Atom Specification".

14.4 Conformance Clause 3: COEL Minimal Management Interface A Data Engine process or program conforms to this specification as COEL Minimal Management Interface if it satisfies all the statements below:

(a) It can understand and process the functions defined in section 7.2 "COEL Minimal Management Interface (MMI)" according to their rules and semantics.

(b) It generates errors as required in error cases described in section 7.2.

14.5 Conformance Clause 4: COEL Behavioural Atom Protocol Interface

A Service Provider process or program conforms to this specification as COEL Behavioural Atom Protocol Interface if it satisfies all the statements below:

(a) It classifies events with the COEL Data Model as defined in Clause 1: COEL Data Model.(b) It can correctly format Behavioural Atoms as defined in Clause 2: COEL Behavioural Atom.(c) It can transmit or transfer Behavioural Atoms as defined in section 8.2 "COEL Behavioural

Atom Protocol Interface Specification (BAP)".


A Data Engine process or program conforms to this specification as COEL Behavioural Atom Protocol Interface if it satisfies all the statements below:

(a) It can parse and recognize the elements of any conforming COEL Behavioural Atom, and generates errors for those data objects that fail to conform as COEL Behavioural Atom when this is clearly intended.

(b) It can receive Behavioural Atoms as defined in section 8.2 "COEL Behavioural Atom Protocol Interface Specification (BAP)".

(c) It generates errors as required in error cases described in section.(d) It correctly implements the COEL Minimal Management Interface as defined in Clause 3

14.6 Conformance Clause 5: COEL Public Query InterfaceA Data Engine process or program conforms to this specification as COEL Public Query Interface if it satisfies all the statements below:

(a) It can correctly format Behavioural Atoms as defined in Clause 2: COEL Behavioural Atom.(b) It can understand and process the functions defined in section 9.2 "COEL Public Query

Interface (PQI)" according to their rules and semantics.(c) It generates errors as required in error cases described in section 9.2.(d) It correctly implements the COEL Minimal Management Interface as defined in clause 3

14.7 Conformance Clause 6: COEL Identity Authority InterfaceAn Identity Authority process or program conforms to this specification as COEL Identity Authority Interface if it satisfies all the statements below:

(a) It can understand and process the functions defined in section 10.2 "COEL Identity Authority Interface (IDA)" according to their rules and semantics.

(b) It generates errors as required in error cases described in section 10.2.


Appendix A. AcknowledgmentsThe following individuals have participated in the creation of this specification and are gratefully acknowledged:Participants:!!br0ken!!

Paul Bruton, Individual MemberJoss Langford, ActivinsightsMatthew Reed, CoelitionDavid Snelling, Fujitsu


Appendix B. Known Extensions to the COEL Model


Appendix C. Revision HistoryRevision Date Editor Changes Made

0 23/01/2017 David Snelling Initial document outline

1 Joss Langford Atom -> Behavioural AtomAdded Behavioural Atom sectionMoved IDA sectionStandardised section formats & titlesBasic conformance text added

2 27/01/2017 Paul Bruton Added section ’10: Data Engine’ to separate out the data engine information request from the BAP. For discussion: Further restructuring needed.

3 27/01/2017 Paul Bruton Reverted previous changes after discussion: Decided to move Information Request from BAP to MMI Section. Re-ordered sections and conformance clauses to put MMI first

4 02/02/2017 David Snelling Added first two sections of the MMI for discussion.

5 02/09/2017 David Snelling Updated the definitions section for authorization protocols and two data types.

6 21/02/2017 Paul Bruton Put in references for TLS, BasicAuth. Some minor corrections and comments.

7 24/02/2017 Joss Langford Added sections for ‘Privacy-by-Design’, ‘Security’ & ‘Identity Management’.Brought over all text from RPE.

8 24/02/2017 Matt Reed Brought in materials on section 4.

9 01/03/2017 Paul Bruton Accepted previous changes and copied in IDA content to section 10.

10 01/03/2017 Paul Bruton IDA content altered to fit with new style and approach

11 01/03/2017 Paul Bruton Review and minor correction/comments, section 1-9


Classification of Everyday Living - OASIS Web viewAlthough called the Classification of Everyday Living, ... There is a single Japanese word for this ... Performing a GET on this URI

Documents