How does this project fit with the strategy?

Information Sharing Interoperability Charter

Timeframe

• all deliverables by Q3/Q4 2022

Why are we doing this?

Problem statement

The Consent Receipt v1.1 from Kantara was frozen in 2017 and has seen substancial interest as it can bring 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.

The proposers have identified a high impact application to Consent Receipts: the case of Web consent. This scenario should be extremely familiar.  Every day and just in Europe, many millions of people access websites multiple times per day. On landing on a page, users are asked to consent with data collection. Control of any consent action in a website is typically lost as soon as, e.g., a cookie banner is dismissed as it is difficult, if not impossible, to review the Consenting action or keep track of past actions.

Web consent receipts (WCRs) offer a promising approach: whenever a consent action is taken, a consent receipt is generated.

We will not anticipate how such receipts will be used, as this should be allowed to evolve organically through adoption, but immediate applications are in user-controlled tracking of personal data or demonstration of consent for websites.

This project will specify an interoperable and (potentially) extensible architecture, based on web and browser technologies so to allow web users, by means of a browser agent (such as an extension), to generate WCRs automatically and non-intrusively, directly in the browser.

Impact of this problem

Significant: no current and structured means exist for individuals to keep track of their consents in the real-time web.

How do we judge success?

We will

• Publish a set of open specifications
• Publish best-practices guides
• Create an open-source software implementation reference (if resources are available)
• Organise hackathons for implementers and user-testers

What do we already know?

The project will define an architecture for WCRs.

For the receipts format, we will be as interoperable as possible with the Kantara Initiative Consent Receipt Specification v1.1 (2017) and the upcoming ISO/IEC 27560 (ISO SC 27/WG 5).

The remaining technical components will use standard web technologies.

There may be a case for Distributed Identifiers and/or Verified Credentials, at which point we will liaise to seek advice.

What do we need to answer?

What are we doing?

We will develop, specify and potentially implement an architecture for Web Consent Receipts.

The core of the project is to deliver the following specifications:

• a format of receipts customised for the Web case
• the user-agent (a browser extension)
• signalling mechanisms between any webpage and any compatible user-agent (e.g., HTML semantics/tags and/or HTTP headers)
• programmatic interfaces for receipt storage (e.g., online wallets)

For the receipts format, we will be as interoperable as possible with the Kantara Initiative Consent Receipt Specification v1.1 (2017) and the upcoming ISO/IEC 27560 (ISO SC 27/WG 5).

For the user-agent, we will use a generic browser extension mode (such as those used by Edge, Chrome, Firefox, Opera, Brave and Vivaldi).

For browser/extension signalling, we will select commonly available, standard methods such as HTTP headers or standard javascript APIs.

For receipt storage, where we contemplate either a (simple) local form or in the cloud, we will select a few representative methods and define APIs.

Why will netizens want this?

We see great potential in offering a solution for receipts specifically for the Web. A number of user-empowering applications are possible simply by the existence of this framework – for example, timeline visualisation just from the receipts.

Visualize the solution

The central use-case is the following:

• User navigates to a website
• The website’s HTML, or HTTP, will carry special signalling that is needed to populate the content of the receipts – for example, the name of the Data Controller or a signature.
• The browser extension will detect the opportunity to generate a receipt (e.g., by finding a special tag in the HTML)
• The WCR, in the predefined format, will be generated in the background
• and potentially stored in the cloud

There may be other exploitations, e.g., a distributed architecture base don verifiable credentials.

Scale and scope

WWW-scope