Method Request Body Response Status Response Content-Type Response Body POST <ManagementURI>/ operator/consumer JSON Object 200 (OK) None None 410 (Gone) application/json JSON Object Error code application/json JSON Object Content of the request body JSON object: Key Type Description Required OperatorID String A Pseudonymous Key associated with the Operator and generated by an IDA. Yes ConsumerID String A Pseudonymous Key associated with the Consumer and generated by an IDA. Yes TimeStamp String Time stamp, in DateTime format, of the ConsumerID indicating when the IDA created this Pseudonymous Key. Yes Signature String Signature proving that an IDA created this ConsumerID. Yes SegmentData Object An OPTIONAL object containing (OPTIONALLY) residential time zone and latitude, gender, and year of birth. The field names are: ResidentTimeZone; ResidentLatitude; Gender; and YearOfBirth. No ResidentTimeZone String The time zone in which the Consumer generally resides, as a string indicating +/-hh:mm from UTC (e.g "-05:00"). No ResidentLatitude Number The latitude (rounded to an integer) at the Consumer generally resides. No Gender Number Integer representing the gender of the Consumer, where: 0 = not known; 1 = male; 2 = female; 9 = not applicable. No YearOfBirth Number Year in which the Consumer was born as an integer. No The Gender parameter SHALL have enumerated fields reserved for compliance with [ISO/IEC 5218]. Content of the response body JSON object in the case of an error: Key Type Description Required Reason String An OPTIONAL description of why the request failed. No Example Example request message: POST operator/consumer
Example response message: HTTP/1.1 200 OK {"IdentityAuthorityURI": "IdentityAuthorityStatus": "Up", "ServerTime": 1470822001, "CoelSpecificationVersion": [1,0] } PseudonymousKey endpoint The 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 Identity Authority MAY periodically change the mechanism used to sign the response, so the response SHOULD be passed to the Data Engine shortly generation or validation can fail. Method Request Body Response Status Response Content-Type Response Body POST <IdentityAuthorityURI> /PseudonymousKey None 200 (OK) application/json JSON Any other status None None Content of the response body JSON object: Name Value Description REQUIRED PseudonymousKey String A Pseudonymous Key generated by the IDA. Yes TimeStamp String Time in DateTime format, indicating when the IDA created this response. Yes Signature String Signature proving that the IDA created this response. Yes Status: 200: The operation was successful 401/403: The operation failed due to authentication or authorization failure. The caller SHOULD confirm its credentials and 500: Internal the caller SHOULD retry Example Example request message: POST /PseudonymousKey Example response message HTTP/1.1 200 OK { "PseudonymousKey": "00000000-0000-0000-0000-000000000000", "TimeStamp": "Signature": "SGFDXCTVIVVIFUJUVUYBKYKJHBK==" }
Implementations Introduction This section describes how the normative elements of the COEL Specification can be configured to achieve a privacy-by-design implementation within an Ecosystem managed by a single IDA. It sets out principles of operation, controls the roles that actors can perform and gives detailed requirements of the responsibilities of actors. Principles Data Separation Principle (P1) The COEL Specification implements a separation of data types for specific roles and this principle extend this to the actors. Data Engines keep data on what Consumers do (COEL Behavioural Atoms) and the 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. Data Atomisation Principle (P2) Data is deliberately broken down into small chunks of information by the Operator and coded with the Consumer’s ConsumerID, thus each separate COEL Behavioural Atom has a very low privacy risk. Atomised Consent Principle (P3) Consumers give informed consent to the Operator or are provided appropriate notice the requirements set out in this section. This allows the Operator to sign up the Consumer with a ConsumerID. This ConsumerID is the indicator to Identity Authority and other Ecosystem actors that appropriate consent or notice is in place. The requirement for every COEL Behavioural Atom to have a ConsumerID (or associated DeviceID) in combination with the detailed consent fields, ensures each Atom has that Consumer’s consent / notice written into the structure of the data. The time stamp uniquely associated with each COEL Behavioural Atom allows full auditing of this principle. 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 COEL Behavioural Atoms not Consumers. Service Providers are expert at manipulating behavioural data to deliver services and service content; they handle COEL Behavioural Atoms not Consumers. Operators are experts at Consumer facing services and handling DIPI; they handle Consumers not COEL Behavioural Atoms. The Identity Authority is expert at overseeing the Ecosystem. 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. Active Support Principle (P6) All actors will actively promote these principles, safeguard the structure of the Ecosystem and support good data practice for both individuals and enterprises.