How does this project fit with the strategy?

Information Sharing Interoperability Charter

Project time frame to Completion:

July 2020

Deliverables:

Reports:

Specs: Framework Specification for Personal Data Use Receipts

Recommendation / Practices:

Why are we doing this?

Objectives

The Consent Receipt v1.1 from Kantara was frozen in 2017 and has seen enormous success as seen, e.g., in adoption across organizations, as it brings efficiency, compliance, and user control. The original receipt was primarily aimed at personal information and, to a large extent, driven by upcoming regulations (at the time) such as EU's GDPR. Adaptations to different contexts such as Healthcare or Financial are now common but, as expected, the current specification is often limiting and requires modifications to specific use-cases.

In discussions with organizations that handle personal information, it became apparent that a more general framework would be readily accepted by implementers that were not addressing only consent-based personal data sharing situations. The concept that individuals should be given material for personal record-keeping about data interactions has proven to be very powerful and compelling.

The aim of this project is to create a framework specification that describes the requirements for Data Use Receipts. The framework specification will include mandatory and optional requirementselements. Communities of interest will create specialized profiles profile specifications of the framework specification that are customized for their use cases and scenarios.

The framework specification will allow implementers from any community to be assured that their profiled specifications contain the essential element of Data Use Receipts. Different profiles are not expected to be automatically semantically interoperable or technically intereoperable interoperable between domains. However, with some planning, profilers can adopt or align with pieces of other profiles.

How do we judge success?

A published framework specification that describes the requirement for Data Use Receipts requirements and guidelines for the creation of profile specifications.

It The end result should be compatible with that the current specfication (Consent Receipt Specification v1.1 ).

What are the possible solutions?

should appear as if was constructed as a profile from the PDUR Framework specification.

What do we already know?

The Kantara Initiative Consent Receipt Specification v1.1 was published by Kantara Initiative in 2017 and several communities and companies have implemented compatible consent receipt definitions.

Inputs:

Feedback from implementers of v1.1 was collected as a potential backlog of work items for future evolution of the CR v1.1

ISO 10000 provides guidance on how to write framework specifications and how to construct profile specifications from them. This approach will be used in the PDUR Framework Specification.

What do we need to answer?

What are we doing?

Taking the existing Consent Receipt Specification v1.1 plus implementer feedback as input to retroactively create a PDUR Framework Specification that will appear to be the progenitor of the v1.1 specification.

Constructing the PDUR Framework Specification in a way that it could be contributed to the ISO 27560 "Consent Record Information Structure" project as input into that ISO SC 27/WG 5 project. The ISO 27560 project intends to create an ISO Technical Specification that describes the requirements of consent record information structures - this is the same objective as the PDUR Framework specification project.

Why will a customer want this?

Personal record keeping for important events is a well-founded concept. The Personal Data Use Receipt framework specification will allow implementers to offer a standardized person record that corresponds to the data controller's records. Having an independent personal record is a powerful person-enabling capability that companies can use to increase the value deliver delivered to people.

Visualize the solution

The context of the solution is an online data-transfer interaction event between two parties. The PDUR Framework Specification will set out the expectations for PDUR profiles and the kinds of event metadata that should be kept, offered, and maintained by one or both parties.

For example, Party A might be an organization wanting to obtain data from Party B, an individual. In this example scenario, the data transfer interaction is online only.

Party A and Party B come to agree on the terms, conditions, and details of the data transfer. Party B positively indicates authorization to Party A to proceed with the data transfer interaction. In most cases, Party A must keep a record of the agreement, the authorization, and the event. Today, if Party B wishes to maintain a personal record about the agreement, authorization, and event, they must proactively decide to do so and record whatever they can with little or no assistance from Party A.

In the future, a PDUR profile would specify the expected metadata about the agreement, the authorization and the event to be retained by Party A, to be offered to Party B, and to be maintained by Party B over time.

The records kept by Party A could be called "Personal Data Use Records" and the corresponding records offered to and kept by Party B could be called "Personal Data Use Receipts". Both records would conform to the applicable PDUR Profile specification.

The highest-level description of the PDUR structure is:

• The content of a PDUR is the metadata of a data-transfer interaction event between parties. This might include timestamps, descriptions of the purpose, data transferred, the parties, contact information, and constraints - all related to the event.
  • In some profiles and scenarios, the content may also include the actual data transferred, if the profiler decides it to be so.
• The PDUR content is encapsulated in a "Receipt Envelope" construct which is comprised of PDUR metadata. This might include timestamps, descriptions of the receipt context, the parties, contact information, and constraints - all related to the receipt issuance.
• Receipts could be linked together into related groups by including references. Events could be linked together by including references.
• A profile might state that the PDUR Content is encrypted to a different party than the Receipt Envelope, or it could all be plaintext.