Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

Chapter 1 — Provider: encrypt data and publish an ODRL policy

This notebook walks through the provider side of the FAIR2Adapt access control workflow. You will:

  1. Encrypt a dataset with AES-256-GCM

  2. Create an ODRL access policy (JSON-LD)

  3. Wrap the dataset key for a specific consumer’s DID

Step 1 — Load and inspect the dataset

The dataset is a small CSV of synthetic Mediterranean biodiversity observations. In a real scenario, this would be your sensitive research data.

Step 2 — Encrypt the dataset

The provider encrypts the dataset with a random AES-256-GCM key. The encrypted file can be hosted anywhere (S3, Zenodo, GitHub) — without the key, it’s unreadable.

Step 3 — Create the ODRL access policy

The policy declares, in machine-readable form, who can do what with this dataset, under which conditions. It uses the ODRL (Open Digital Rights Language) standard with purpose constraints from the W3C Data Privacy Vocabulary.

This policy says:

  • ✅ Permitted: Use and Reproduce — for Public Benefit purposes

  • ❌ Prohibited: Commercialise and Sell

  • 📋 Duty: Attribute to FAIR2Adapt

The published nanopublication of this policy is: Once this policy is published as a nanopublication, set _nanopub_uri in policies/hamburg-buildings-example.jsonld and it flows through automatically. See nanopubs/drafts/hamburg-buildings-example.md for the exact form fields.

ODRL Policy rendered in Science Live

The same policy rendered in the Science Live platform’s ODRL viewer.

In production, this policy would be published as a signed nanopublication on the decentralised nanopub network, making it immutable, citable, and independently verifiable.

Step 4 — Receive an access request

A consumer identifies themselves with a DID and declares their purpose. In production, this happens via a GitHub Issue (with automated evaluation). Here we simulate it by loading the example consumer’s DID document.

Step 5 — Evaluate the policy

The provider (or an automated workflow) checks whether the consumer’s declared purpose matches the policy’s constraints.

Step 6 — Wrap the dataset key for the consumer

The provider wraps the dataset key using the consumer’s public key via ECDH key agreement + AES-GCM. Only the holder of the consumer’s private key can unwrap it.

Step 7 — Publish the access grant

The grant is a signed nanopublication recording: who was granted access, to which dataset, under which policy, and when. It is the auditable proof of the access decision.

Summary

The provider has:

StepArtefactWhere it lives
Encrypt datasethamburg-buildings-example.gpkg.encPublic (ROHub, S3, Zenodo)
Dataset key256-bit AES keyProvider’s secret store (never shared directly)
ODRL policyexample-policy.jsonld → nanopublicationPublic (nanopub network)
Wrapped keywrapped-dataset-key.jsonPublic (GitHub Pages)
Access grantnanopublicationPublic (nanopub network)

The dataset key exists in two forms:

  1. Plain — stored privately by the provider

  2. Wrapped — encrypted for a specific consumer, safe to publish

Next: Chapter 2 — Consumer: request access and decrypt