Note: Key publications that contributed to this work: Slabbinck et al., 2025, 'Incentivizing Sustainable Data Exchanges through Unique Contextualization of History and Destiny'.
1. Introduction
The physical world has finite number of carriers. Let’s not replicate that! the digital world doesn’t have that constraint. ...
We introduce in the specification here Trust Envelopes, which is a unique carrier every time, which adds unique value every time.
TODO: elaborate and make clear the importance of Trust Envelopes as technological solution for trust
1.1. Terminology
The following terms are used to describe concepts in this specification.- ODRL Policy
- TODO
- Trust Envelope
- A unique data document, timestamped and digitally signed by a sender, that represents a singular act of associating a data unit with context specific to an actual or proposed processing of the data unit by the recipient.
- Verifiable Credential
- TODO
- Verifiable Presentation
- TODO
1.2. Namespaces
Commonly used namespace prefixes used in this specification:
@prefix dcterms: <http://purl.org/dc/terms/> . @prefix dpv: <http://www.w3.org/ns/dpv#> . @prefix ex: <http://example.org/> . @prefix odrl: <http://www.w3.org/ns/odrl/2/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix sosa: <http://www.w3.org/ns/sosa/> . @prefix ssn: <http://www.w3.org/ns/ssn/> . @prefix te: <https://w3id.org/trustenvelope#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
2. Requirements
-
Explicitness from senders: Senders must define clear usage control policies that specify how data may be processed, for what purpose, and under which conditions.
-
Specificity from recipients: Recipients must be able to articulate exactly what data they require for what purpose. This is related to data minimization and ensures a high signal-to-noise ratio, reducing unnecessary exposure for the sender.
-
Uniqueness of each exchange: Every transaction is context-dependent and shaped by highly specific policies.
-
Legal compliance: Exchanges must adhere to jurisdictional regulations such as the [GDPR] in Europe or the California Consumer Privacy Act ([CCPA]).
-
Accountability: Transparency in both data verification and usage is essential. All parties must be able to audit the lifecycle of the data and demonstrate compliance when required.
These requirements are consolidated in an Ontology Requirement Specification Document, including the derived competency questions, as required by the Linked Open Terms (LOT) methodology [LOT] for the the development of ontologies and vocabularies.
3. Model
te prefix.4. Vocabulary
4.1. Classes
4.1.1. Trust Envelope
| IRI | te:TrustEnvelope |
|---|---|
| Label | Trust Envelope |
| Type | rdfs:Class, skos:Concept |
| Definition | A Trust Envelope is a unique data document, timestamped and digitally signed by a sender, that represents a singular act of associating a data unit with context specific to an actual or proposed processing of the data unit by the recipient. |
4.1.2. Data Provenance
| IRI | te:DataProvenance |
|---|---|
| Label | Data Provenance |
| Type | rdfs:Class, skos:Concept |
| Definition | Contextual information that captures the origin and history of data, including its source entity, entity providing the data, and issuance time. |
4.1.3. Policy Provenance
| IRI | te:PolicyProvenance |
|---|---|
| Label | Policy Provenance |
| Type | rdfs:Class, skos:Concept |
| Definition | Contextual information that captures the origin and history of a policy, including entities that have usage rights over the data unit, entity that will receive the data unit, and issuance time. |
4.2. Properties
4.2.1. Provenance
| IRI | te:provenance |
|---|---|
| Label | Provenance |
| Type | skos:Concept, rdfs:Property |
| Definition | Denotes contextual information related to the origin and history of data units and policies. |
| Domain | te:TrustEnvelope |
| Range | te:DataProvenance, te:PolicyProvenance |
4.2.2. Sender
| IRI | te:sender |
|---|---|
| Label | Sender |
| Type | skos:Concept, rdfs:Property |
| Definition | Entity that issues the trust envelope. |
| Domain | te:DataProvenance |
| Range | xsd:anyURI |
4.2.3. Recipient
| IRI | te:recipient |
|---|---|
| Label | |
| Type | skos:Concept, rdfs:Property |
| Definition | Entity that receives the trust envelope. |
| Domain | te:PolicyProvenance |
| Range | xsd:anyURI |
4.2.4. Rights holder
| IRI | te:rightsHolder |
|---|---|
| Label | Rights holder |
| Type | skos:Concept, rdfs:Property |
| Definition | Entity claiming to have usage rights over the data unit. |
| Domain | te:PolicyProvenance |
| Range | xsd:anyURI |
4.2.5. Sign
| IRI | te:sign |
|---|---|
| Label | Sign |
| Type | skos:Concept, rdfs:Property |
| Definition | Denotes information about digital signatures. |
| Domain | te:TrustEnvelope, te:DataProvenance, te:PolicyProvenance |
| Range | xsd:anyURI |
5. Materialization
5.1. Purchase of age-restricted goods
Alice wants to have alcoholic beverages delivered to her house in Belgium, where the legal age to buy alcoholic beverages is 18. She goes online to Alcoholic Beverages Corporations (ABC) and attempts to buy beer. The store requires sufficient evidence to demonstrate that each purchase complies to Belgian law. Therefore, ABC restricts purchases for alcoholic beverages to those who provide sufficient evidence, which is being over the age of 18. There are multiple carriers of that evidence: a national ID card, an international passport, a driver’s license, ... . (note that the three provided are all government issued documents)As such, she sends a Trust Envelope to ABC.
It is a technological solution that carries this evidence in a uniquely crafted envelope, tailored specifically for the transaction between Alice and ABC.
The data unit contains a proof (represented by a VP), issued by the government, that Alice is over 18 years old.
The envelope also encloses an ODRL policy permitting ABC to use the data unit solely for age verification purposes.
For this envelope, there are three signatures made by Alice.
First, the provenance signature (ex:signedDataProvenance1) and policy provenance (ex:signedPolicyProvenance1) are made.
For the provenance, this entails signing all triples related to the data (as shown by https://country.org/uuid1) AND all the triples of ex:dataProvenance1 minus the te:sign triples (as this is the signature and can only be added after the signing).
The policy signature strategy is the same, the signature entails all triples related to the policy (ex:policy1) AND all the triples of ex:policyProvenance1 minus the te:sign triples.
Finally, a signature is made over the whole Trust Envelope, selecting all triples related to the Trust Envelope apart from te:sign triples.
Note: Right now, this selection principle leaves room for interpretation given the Open World assumption of RDF. In current example, it is relatively clear which triples are meant, as all of them are explicitly shown. To create software, however, it is important to be explicit in the selecting of those triples. One potential solution for this purpose is using RDF context associations.
Note: A choice in this example is made to have an ODRL Agreement as policy. In practice, this implies that both the sender/assigner (Alice) and the recipient/assignee (ABC) have, in some form, signed the policy. As a result, it’s not a one-sided declaration but rather a mutual contract. Both parties acknowledge and are expected to honor the policy.
ex : envelope1 a te : TrustEnvelope ; dcterms : issued "2024-02-12T11:20:10.999Z" ^^ xsd : dateTime ; dpv : hasData <https://country.org/uuid1> ; odrl : hasPolicy ex : policy1 ; te : provenance ex : dataProvenance1 , ex : policyProvenance1 ; te : sign ex : signedEnvelope1 . ex : dataProvenance1 a te : DataProvenance ; dcterms : issued "2024-02-12T11:20:10.999Z" ^^ xsd : dateTime ; te : sender <https://alice.org> ; dpv : hasDataSubject <https://alice.org> ; te : sign ex : signedDataProvenance1 . ex : policyProvenance1 a te : PolicyProvenance ; dcterms : issued "2024-02-12T11:20:10.999Z" ^^ xsd : dateTime ; te : recipient <https://alcoholic-beverages.com> ; te : rightsHolder <https://alice.org> ; te : sign ex : signedPolicyProvenance1 .
{ "@context" : [ "https://www.w3.org/ns/credentials/v2" ], "type" : [ "VerifiablePresentation" ], "id" : "https://country.org/uuid1" , "holder" : "https://alice.org" , "verifiableCredential" : [ { "id" : "https://country.org/uuid1/credential" , "type" : [ "VerifiableCredential" ], "issuer" : "https://country.org/" , "validFrom" : "2025-03-07T11:13:40.178987907Z" , "credentialSubject" : { "id" : "https://alice.org" , "age" : { "type" : "AgeProof" , "name" : "Age is over 18" } }, "validUntil" : "2026-03-07T11:13:40.179049118Z" , "proof" : { "type" : "DataIntegrityProof" , "verificationMethod" : "..." , "cryptosuite" : "bbs-2023" , "proofPurpose" : "assertionMethod" , "proofValue" : "..." } } ] }
ex : policy1 a odrl : Agreement ; odrl : uid ex : policy1 ; odrl : permission ex : rule1 . ex : rule1 a odrl : Permission ; odrl : assigner <https://alice.org> ; odrl : assignee <https://alcoholic-beverages.com> ; odrl : action odrl : use ; odrl : target <https://country.org/uuid1> ; odrl : constraint ex : constaint1 . ex : constraint1 a odrl : Constraint ; odrl : leftOperand odrl : purpose ; odrl : operator odrl : eq ; odrl : rightOperand "Age Verification" .
The Trust Envelope signature entails all triples related to the Trust Envelope (
ex : signedEnvelope1 a sign : Signature ; sign : value "..." ; sign : target ex : envelope1 ; sign : issuer <https://alice.org> .
The provenance signature entails all triples starting from provenance (
ex : signedDataProvenance1 a sign : Signature ; sign : value "..." ; sign : target ex : dataProvenance1 ; sign : issuer <https://alice.org> .
The policy signature entails all triples starting from policy provenance (
ex : signedPolicyProvenance1 a sign : Signature ; sign : value "..." ; sign : target ex : policyProvenance1 ; sign : issuer <https://alice.org> .
Note: The signatures above its structure is influenced by RDF context associations. Though currently, proper selection trough asserting a set of triples is not performed properly.
5.2. Cargo Monitoring
In logistics, real-time cargo tracking is essential for optimizing planning and estimating time of arrival. In this use case, we have Beverage Company (BC) that contracts Boxport to transport goods via inland waterways. At all times BC wants the location of the cargo in real-time to estimate the delivery time. Waterway authorities monitor vessel movements and can verify location data. This includes of course Bluewave, the vessel employed by Boxport to transport BC its cargo.
To monitor its fleet, Boxport requests access to this data. The authority responds by issuing a Trust Envelope that encapsulates Bluewave’s precise location at time t and explicitly grants Boxport permission to use and distribute the data.
When BC requests the location of its cargo from Boxport, the latter responds with a new Trust Envelope . This envelope materializes the previously received Trust Envelope from the waterway authority into derived cargo spatio-temporal data, using it as the basis for a new, context-specific data unit.
ex : envelope2 a te : TrustEnvelope ; dcterms : issued "2024-02-12T11:20:10.999Z" ^^ xsd : dateTime ; dpv : hasData ex : AIS-measurement ; odrl : hasPolicy ex : policy2 ; te : provenance ex : dataProvenance2 , ex : policyProvenance2 ; te : sign ex : signedEnvelope2 . ex : dataProvenance2 a te : DataProvenance ; dcterms : issued "2024-02-12T11:20:10.999Z" ^^ xsd : dateTime ; te : sender <https://waterway.org> ; eu-dga : hasDataHolder <https://boxport.com> ; te : sign ex : signedDataProvenance2 . ex : policyProvenance2 a te : PolicyProvenance ; dcterms : issued "2024-02-12T11:20:10.999Z" ^^ xsd : dateTime ; te : rightsHolder <https://crew.boxport.com> , <https://waterway.org> ; te : recipient <https://boxport.com> ; te : sign ex : signedPolicyProvenance2 .
<urn:uuid:12c01cd9-d09e-4e4d-9589-f4c3da1f6190> a sosa : Observation ; sosa : resultTime "2024-02-12T11:20:10.999Z" ^^ xsd : dateTime ; sosa : hasResult <ex:AIS-measurement> . ex : AIS-measurement a sosa : Result ; sosa : isResultOf <urn:uuid:12c01cd9-d09e-4e4d-9589-f4c3da1f6190> ; <https://dbpedia.org/page/Category/MMSI_Number> "3b7455b3a0f78a47b7ddac16250dbc22" ; <https://dbpedia.org/ontology/destination> "ANTWERP" ; <https://dbpedia.org/page/Estimated_time_of_arrival> "12-02 06:00" ; <https://dbpedia.org/ontology/shipDraft> "3.6" ; <https://dbpedia.org/page/Course_(navigation)/> "155.4" ; <http://www.example.com/AISnavstat> "5" ; <https://dbpedia.org/page/Heading_(navigation)/> "91" ; <https://dbpedia.org/page/Rotation> "0" ; <https://dbpedia.org/page/speed> "0" ; geo : latitude "51.24607" ; geo : longitude "4.37544" ; geo : elevation "5.5" .
Note: The full SSN/SOSA deployment description from the waterway to sense AIS signals is omitted for brevity.
ex : policy2 a odrl : Agreement ; odrl : uid ex : policy2 ; odrl : permission ex : rule2 . ex : rule2 a odrl : Permission ; odrl : assigner <https://waterway.org> ; odrl : assignee <https://boxport.com> ; odrl : action odrl : use , odrl : distribute ; odrl : target ex : AIS-measurement .
The Trust Envelope signature entails all triples related to the Trust Envelope (
ex : signedEnvelope2 a sign : Signature ; sign : value "..." ; sign : target ex : envelope2 ; sign : issuer <https://waterway.org> .
The provenance signature entails all triples starting from provenance (
ex : signedDataProvenance2 a sign : Signature ; sign : value "..." ; sign : target ex : dataProvenance2 ; sign : issuer <https://waterway.org> .
The policy signature entails all triples starting from policy provenance (
ex : signedPolicyProvenance2 a sign : Signature ; sign : value "..." ; sign : target ex : policyProvenance2 ; sign : issuer <https://waterway.org> .
Note: The signatures above its structure is influenced by RDF context associations. Though currently, proper selection trough asserting a set of triples is not performed properly.
ex : envelope3 a te : TrustEnvelope ; dcterms : issued "2024-02-12T11:20:10.999Z" ^^ xsd : dateTime ; dpv : hasData ex : cargo-location ; odrl : hasPolicy ex : policy3 ; te : provenance ex : dataProvenance3 , ex : policyProvenance3 ; te : sign ex : signedEnvelope3 . ex : dataProvenance3 a te : DataProvenance ; dcterms : issued "2024-02-12T11:20:10.999Z" ^^ xsd : dateTime ; te : sender <https://boxport.com> ; eu-dga : hasDataHolder <https://boxport.com> ; te : sign ex : signedDataProvenance3 . ex : policyProvenance3 a te : PolicyProvenance ; dcterms : issued "2024-02-12T11:20:10.999Z" ^^ xsd : dateTime ; te : rightsHolder <https://crew.boxport.com> , <https://boxport.org> ; te : recipient <https://beverage-company.com> ; te : sign ex : signedPolicyProvenance3 .
ex : AIS-measurement ex : cargo-location dcterms : issued "2024-02-12T11:20:10.999Z" ^^ xsd : dateTime ; geo : latitude "51.24607" ; geo : longitude "4.37544" ; geo : elevation "5.5" .
ex : policy3 a odrl : Agreement ; odrl : uid ex : policy3 ; odrl : permission ex : rule3 . ex : rule3 a odrl : Permission ; odrl : assigner <https://boxport.com> ; odrl : assignee <https://beverage-company.com> ; odrl : action odrl : use ; odrl : target ex : cargo-location ; odrl : constraint ex : constaint3 . ex : constraint3 a odrl : Constraint ; odrl : leftOperand odrl : purpose ; odrl : operator odrl : eq ; odrl : rightOperand "Estimating the time of arrival" .
The Trust Envelope signature entails all triples related to the Trust Envelope (
ex : signedEnvelope3 a sign : Signature ; sign : value "..." ; sign : target ex : envelope3 ; sign : issuer <https://boxport.com> .
The provenance signature entails all triples starting from provenance (
ex : signedDataProvenance3 a sign : Signature ; sign : value "..." ; sign : target ex : dataProvenance3 ; sign : issuer <https://boxport.com> .
The policy signature entails all triples starting from policy provenance (
ex : signedPolicyProvenance3 a sign : Signature ; sign : value "..." ; sign : target ex : policyProvenance3 ; sign : issuer <https://boxport.com> .
Note: The signatures above its structure is influenced by RDF context associations. Though currently, proper selection trough asserting a set of triples is not performed properly.
6. Legal Considerations
The Trust Envelope model was developed to be regulation-agnostic, to be able to tackle legal requirements from different jurisdictions, different branches of law, e.g., data protection or intellectual property law, and different data types, e.g., personal or non-personal data. This is of particular importance to understand and correctly model all the parties that might have rights and obligations over the data unit, how they interplay, and how they are to be correctly interpreted and enforced.
Nonetheless, the terms chosen to model data provenance, in particular related to the source entity of the data, where kept in line with European legislation such as the General Data Protection Regulation (GDPR) [GDPR] and the Data Governance Act (DGA) [DGA] as these regulations are being followed and similarly adapted in other jurisdictions' regulations.
Moreover, by incorporating provenance and usage policies as fundamental components of trustful data exchanges, Trust Envelopes can be used as auditing tools by external legal authorities to assess good and poor practices of recipients, and possibly held as proof in judgments for the later case.
7. Ontology Requirement Specification Document
| Trust Envelope specification | |
|---|---|
| Purpose | |
| The purpose of this specification is to support the modelling of Trust Envelopes as unique data documents that associate a data unit with context specific information about its history and destiny. | |
| Scope | |
| The scope of this specification is limited to the reusage of existing terms from established standards and to the definition of new ones, that will serve one of these purposes: (i) define entity roles related to the origin and usage conditions of a data unit, (ii) define clear usage control policies, (iii) declare provenance information about the data unit, and (iv) assist with regulatory compliance. | |
| Implementation Language | |
| RDF, RDFS | |
| Intended End-Users | |
| Developers and users of data sharing ecosystems | |
| Ontology Requirements | |
| Non-Functional Requirements | |
| NFR 1. The ontology shall be published online with standard documentation. | |
| Functional Requirements: Groups of Competency Questions | |
| CQG1. Related to trust envelopes components | CQG2. Related to regulatory compliance |
| CQ1. Who are the entities to which the data is related? CQ2. Who are the entities involved in the data exchange? CQ3. Who are the entities that have rights over the data? CQ4. Which are the conditions for using the data? CQ5. In which context was the data generated? | CQ6. Which obligations and requirements need to be fulfilled to be legally compliant? CQ7. What is the legal identification of the involved entities? |