spec.bs

<pre class='metadata'>
Title: Trust Envelope specification
Shortname: TE
Level: none
Status: LD
Editor: Wout Slabbinck, Ghent University - imec http://idlab.ugent.be/, wout.slabbinck@ugent.be
Editor: Beatriz Esteves, Ghent University - imec http://idlab.ugent.be/, beatriz.esteves@ugent.be
Editor: Ruben Verborgh, Ghent University - imec http://idlab.ugent.be/, ruben.verborgh@ugent.be
Abstract: 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. 
Markup Shorthands: markdown yes, css no
URL: https://w3id.org/trustenvelope
Previous Version: _ORCHESTRATOR_PREVIOUS_BUILD_FULL_LINK_
Repository: https://github.com/KNowledgeOnWebScale/TrustEnvelope
!License: <a href="https://creativecommons.org/licenses/by-sa/4.0/">CC-BY-SA-4.0</a>
</pre>

<p boilerplate="copyright">
  <!-- This document is made available under the CC-BY-SA-4.0 License. -->
</p>

<pre class=biblio> 
{
  "gdpr": {
    "href": "https://eur-lex.europa.eu/eli/reg/2016/679/oj",
    "title": "Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)"
  },
  "dga": {
    "href": "http://data.europa.eu/eli/reg/2022/868/oj/eng",
    "title": "Regulation (EU) 2022/868 of the European Parliament and of the Council of 30 May 2022 on European data governance and amending Regulation (EU) 2018/1724 (Data Governance Act)"
  },
  "ccpa": {
    "href": "https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201720180AB375",
    "title": "California Consumer Privacy Act"
  },
  "lot": {
    "href": "https://doi.org/10.1016/j.engappai.2022.104755",
    "title": "LOT: An industrial oriented ontology engineering framework",
    "authors": [
      "Poveda-Villalón, M.",
      "Fernández-Izquierdo, A.",
      "Fernández-López, M.",
      "García-Castro, R."
    ],
    "publisher": "Engineering Applications of Artificial Intelligence 111",
    "date": "2022"
  }
}
</pre>

Note: **Key publications that contributed to this work:** Slabbinck *et al.*, 2025, [*'Incentivizing Sustainable Data Exchanges through Unique Contextualization of History and Destiny'*](https://w3id.org/trustenvelope/papers/WOP2025).

Introd­uction {#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.


<mark>TODO:</mark> elaborate and make clear the importance of Trust Envelopes as technological solution for trust

## Terminology ## {#terminology}
The following terms are used to describe concepts in this specification. 

<dl>
  <dt><dfn>ODRL Policy</dfn></dt>
  <dd>TODO</dd>
  <dt><dfn>Trust Envelope</dfn></dt>
  <dd>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.</dd>
  <dt><dfn>Verifiable Credential</dfn></dt>
  <dd>TODO</dd>
  <dt><dfn>Verifiable Presentation</dfn></dt>
  <dd>TODO</dd>
</dl>

## Namespaces ## {#namespaces}

Commonly used namespace prefixes used in this specification:
```turtle
@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#> .
```

Requirements {#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](#orsd),
including the derived competency questions,
as required by the [Linked Open Terms (LOT)](https://lot.linkeddata.es) methodology [[!LOT]] for the the development of ontologies and vocabularies.

Model {#model}
==============


<figure id="trust-envelope-model">
<img src="./img/trust-envelopes-model.svg">
<figcaption>Trust Envelope core components and involved entities.</figcaption>
</figure>

<figure id="trust-envelope-spec">
<img src="./img/trust-envelopes-spec.svg">
<figcaption>Ontology Design Pattern for Trust Envelopes. Trust Envelope vocabulary terms, in yellow, include the `te` prefix.</figcaption>
</figure>

Vocabulary {#vocabulary}
========================

## Classes ## {#Classes}

### Trust Envelope ### {#TrustEnvelope}

<pre class=simpledef>
IRI: [te:TrustEnvelope](https://w3id.org/trustenvelope#TrustEnvelope)
Label: Trust Envelope
Type: [rdfs:Class](http://www.w3.org/2000/01/rdf-schema#Class), [skos:Concept](http://www.w3.org/2004/02/skos/core#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.
</pre>

### Data Provenance ### {#DataProvenance}

<pre class=simpledef>
IRI: [te:DataProvenance](https://w3id.org/trustenvelope#DataProvenance)
Label: Data Provenance
Type: [rdfs:Class](http://www.w3.org/2000/01/rdf-schema#Class), [skos:Concept](http://www.w3.org/2004/02/skos/core#Concept)
Definition: Contextual information that captures the origin and history of data, including its source entity, entity providing the data, and issuance time.
</pre>

### Policy Provenance ### {#PolicyProvenance}

<pre class=simpledef>
IRI: [te:PolicyProvenance](https://w3id.org/trustenvelope#PolicyProvenance)
Label: Policy Provenance
Type: [rdfs:Class](http://www.w3.org/2000/01/rdf-schema#Class), [skos:Concept](http://www.w3.org/2004/02/skos/core#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.
</pre>

## Properties ## {#Properties}

### Provenance ### {#Provenance}

<pre class=simpledef>
IRI: [te:provenance](https://w3id.org/trustenvelope#provenance)
Label: Provenance
Type: [skos:Concept](http://www.w3.org/2004/02/skos/core#Concept), [rdfs:Property](http://www.w3.org/2000/01/rdf-schema#Property)
Definition: Denotes contextual information related to the origin and history of data units and policies.
Domain: [te:TrustEnvelope](https://w3id.org/trustenvelope#TrustEnvelope)
Range: [te:DataProvenance](https://w3id.org/trustenvelope#DataProvenance), [te:PolicyProvenance](https://w3id.org/trustenvelope#PolicyProvenance)
</pre>

### Sender ### {#Sender}

<pre class=simpledef>
IRI: [te:sender](https://w3id.org/trustenvelope#sender)
Label: Sender
Type: [skos:Concept](http://www.w3.org/2004/02/skos/core#Concept), [rdfs:Property](http://www.w3.org/2000/01/rdf-schema#Property)
Definition: Entity that issues the trust envelope.
Domain: [te:DataProvenance](https://w3id.org/trustenvelope#DataProvenance)
Range: [xsd:anyURI](http://www.w3.org/2001/XMLSchema#anyURI)
</pre>

### Recipient ### {#Recipient}

<pre class=simpledef>
IRI: [te:recipient](https://w3id.org/trustenvelope#recipient)
Label: 
Type: [skos:Concept](http://www.w3.org/2004/02/skos/core#Concept), [rdfs:Property](http://www.w3.org/2000/01/rdf-schema#Property)
Definition: Entity that receives the trust envelope.
Domain: [te:PolicyProvenance](https://w3id.org/trustenvelope#PolicyProvenance)
Range: [xsd:anyURI](http://www.w3.org/2001/XMLSchema#anyURI)
</pre>

### Rights holder ### {#RightsHolder}

<pre class=simpledef>
IRI: [te:rightsHolder](https://w3id.org/trustenvelope#rightsHolder)
Label: Rights holder
Type: [skos:Concept](http://www.w3.org/2004/02/skos/core#Concept), [rdfs:Property](http://www.w3.org/2000/01/rdf-schema#Property)
Definition: Entity claiming to have usage rights over the data unit.
Domain: [te:PolicyProvenance](https://w3id.org/trustenvelope#PolicyProvenance)
Range: [xsd:anyURI](http://www.w3.org/2001/XMLSchema#anyURI)
</pre>

### Sign ### {#Sign}

<pre class=simpledef>
IRI: [te:sign](https://w3id.org/trustenvelope#sign)
Label: Sign
Type: [skos:Concept](http://www.w3.org/2004/02/skos/core#Concept), [rdfs:Property](http://www.w3.org/2000/01/rdf-schema#Property)
Definition: Denotes information about digital signatures.
Domain: [te:TrustEnvelope](https://w3id.org/trustenvelope#TrustEnvelope), [te:DataProvenance](https://w3id.org/trustenvelope#DataProvenance), [te:PolicyProvenance](https://w3id.org/trustenvelope#PolicyProvenance)
Range: [xsd:anyURI](http://www.w3.org/2001/XMLSchema#anyURI)
</pre>

Materialization {#materialization}
==================================

## Purchase of age-restricted goods ## {#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](#trustenvelope-1) 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.<br>
The **data unit** contains a proof ([represented by a VP](#data-unit-1)), issued by the government, that Alice is over 18 years old. 
The envelope also encloses an [**ODRL policy**](#policy-1) permitting ABC to use the data unit solely for age verification purposes.

For this envelope, there are three [signatures](#signatures-1) made by Alice.<br>
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`](#data-unit-1)) 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`](#policy-1)) AND all the triples of `ex:policyProvenance1` minus the `te:sign` triples.<br>
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](https://knowledgeonwebscale.github.io/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.

<div class="example" highlight="turtle" id="trustenvelope-1"> 
Trust Envelope issued by Alice to prove to ABC that her age is above 18
```turtle
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 .
```
</div>

<div class="example" highlight="json" id="data-unit-1"> 
A Verifiable Presentation containing proof that Alice her age is over 18.
The proof is a Verifiable Credential issued by the government of her country.
```json-ld
{
  "@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": "..."
      }
    }
  ]
}
```
</div>

<div class="example" highlight="turtle" id="policy-1"> 
An ODRL policy with a permission rule that states that only Alcoholic Beverages Corporations can use the [data](#data-unit-1) under a purpose constraint.
```turtle
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" .
```
</div>

<div class="example" highlight="turtle" id="signatures-1"> 
The signatures for Alice her [Trust Envelope](#trustenvelope-1).

The **Trust Envelope signature** entails all triples related to the Trust Envelope ([`ex:envelope1`](#trustenvelope-1))  (the data, the policy, and all the provenance and corresponding signatures as shown below) (apart from the signature itself)
```turtle
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:dataProvenance1`](#trustenvelope-1)) (apart from the signature itself) AND all triples related to the data ([`https://country.org/uuid1`](#data-unit-1)).
```turtle
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:policyProvenance1`](#trustenvelope-1)) (apart from the signature itself) AND all triples related to the data ([`ex:policy1`](#policy-1)).
```turtle
ex:signedPolicyProvenance1 a sign:Signature ;
  sign:value "...";
  sign:target ex:policyProvenance1 ;
  sign:issuer <https://alice.org>.
```
</div>

Note: The signatures [above](#signatures-1) its structure is influenced by [RDF context associations](https://knowledgeonwebscale.github.io/rdf-context-associations/). Though currently, proper selection trough asserting a set of triples is not performed properly.

## Cargo Monitoring ## {#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.

<div class="example" highlight="turtle" id="trustenvelope-2"> 
Trust Envelope issued by the waterway authority to allow Boxport the tracking of the real-time location of a given vessel.
```turtle
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 .
```
</div>

<div class="example" highlight="turtle" id="data-unit-2"> 
The spatio-temporal information from Bluewave, represented through a [SSN/SOSA](https://www.w3.org/TR/vocab-ssn/) Result.
This information is generally retrieved by sensors capturing [Automatic Identification System (AIS)](https://en.wikipedia.org/wiki/Automatic_identification_system) signals, which vessels are obliged to transmit.

```turtle
<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".

```
</div>

Note: The full SSN/SOSA deployment description from the waterway to sense AIS signals is omitted for brevity.

<div class="example" highlight="turtle" id="policy-2"> 
An ODRL policy with a permission rule that states that Boxport can use and distribute the [data](#data-unit-2).
```turtle
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 .
```
</div>

<div class="example" highlight="turtle" id="signatures-2"> 
The signatures for the waterway authority [Trust Envelope](#trustenvelope-2) of a particular AIS measurement.

The **Trust Envelope signature** entails all triples related to the Trust Envelope ([`ex:envelope2`](#trustenvelope-2))  (the data, the policy, and all the provenance and corresponding signatures as shown below) (apart from the signature itself)
```turtle
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:dataProvenance2`](#trustenvelope-2)) (apart from the signature itself) AND all triples related to the data ([`https://country.org/uuid2`](#data-unit-2)).
```turtle
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:policyProvenance2`](#trustenvelope-2)) (apart from the signature itself) AND all triples related to the data ([`ex:policy2`](#policy-2)).
```turtle
ex:signedPolicyProvenance2 a sign:Signature ;
  sign:value "...";
  sign:target ex:policyProvenance2 ;
  sign:issuer <https://waterway.org>.
```
</div>

Note: The signatures [above](#signatures-2) its structure is influenced by [RDF context associations](https://knowledgeonwebscale.github.io/rdf-context-associations/). Though currently, proper selection trough asserting a set of triples is not performed properly.

<div class="example" highlight="turtle" id="trustenvelope-3"> 
Trust Envelope issued by Boxport to allow Beverage Company to track its cargo.
```turtle
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 .
```
</div>

<div class="example" highlight="turtle" id="data-unit-3"> 
The spatio-temporal information of the cargo that Beverage Company is monitoring.
This has been transformed from `ex:AIS-measurement` from the [data](#data-unit-2) from the Waterway authority.

```turtle
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".
```
</div>

<div class="example" highlight="turtle" id="policy-3"> 
An ODRL policy with a permission rule that states that Beverage Company can use the [data](#data-unit-3) for the purpose of estimating the time of arrival.
```turtle
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" .
```
</div>

<div class="example" highlight="turtle" id="signatures-3"> 
The signatures for the Boxport [Trust Envelope](#trustenvelope-3) of the location of the cargo from Beverage Company.

The **Trust Envelope signature** entails all triples related to the Trust Envelope ([`ex:envelope3`](#trustenvelope-3))  (the data, the policy, and all the provenance and corresponding signatures as shown below) (apart from the signature itself)
```turtle
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:dataProvenance3`](#trustenvelope-3)) (apart from the signature itself) AND all triples related to the data ([`https://country.org/uuid3`](#data-unit-3)).
```turtle
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:policyProvenance3`](#trustenvelope-3)) (apart from the signature itself) AND all triples related to the data ([`ex:policy3`](#policy-3)).
```turtle
ex:signedPolicyProvenance3 a sign:Signature ;
  sign:value "...";
  sign:target ex:policyProvenance3 ;
  sign:issuer <https://boxport.com>.
```
</div>

Note: The signatures [above](#signatures-2) its structure is influenced by [RDF context associations](https://knowledgeonwebscale.github.io/rdf-context-associations/). Though currently, proper selection trough asserting a set of triples is not performed properly.

Legal Considerations {#legal}
=============================

The [Trust Envelope model](#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.

Ontology Requirement Specification Document {#orsd}
===================================================

<table class="center">
  <tr><th colspan=2 style="background-color: #444; color: white; font-size: smaller; text-align: center; border: 3px solid #444;">
    Trust Envelope specification
  </th></tr>
  <tr><th colspan=2 style="background-color: #aaa; color: white; font-size: smaller; text-align: center; border: 3px solid #444;">
    Purpose
  </th></tr>
  <tr>
    <td colspan=2 style="text-align: justify; text-justify: inter-word; padding-left: 10px; padding-right: 10px; font-size: smaller; border: 3px solid #444;">
    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.
    </td>
  </tr>
  <tr><th colspan=2 style="background-color: #aaa; color: white; font-size: smaller; text-align: center; border: 3px solid #444;">
    Scope
  </th></tr>
  <tr>
    <td colspan=2 style="text-align: justify; text-justify: inter-word; padding-left: 10px; padding-right: 10px; font-size: smaller; border: 3px solid #444;">
    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.
    </td>
  </tr>
  <tr><th colspan=2 style="background-color: #aaa; color: white; font-size: smaller; text-align: center; border: 3px solid #444;">
    Implementation Language
  </th></tr>
  <tr><td colspan=2 style="text-align: justify; text-justify: inter-word; padding-left: 10px; padding-right: 10px; font-size: smaller; border: 3px solid #444;">
    RDF, RDFS
  </td></tr>
  <tr><th colspan=2 style="background-color: #aaa; color: white; font-size: smaller; text-align: center; border: 3px solid #444;">
    Intended End-Users
  </th></tr>
  <tr><td colspan=2 style="text-align: justify; text-justify: inter-word; padding-left: 10px; padding-right: 10px; font-size: smaller; border: 3px solid #444;">
    Developers and users of data sharing ecosystems
  </td></tr>
  <tr><th colspan=2 style="background-color: #aaa; color: white; font-size: smaller; text-align: center; border: 3px solid #444;">
    Ontology Requirements
  </th></tr>
  <tr><th colspan=2 style="background-color: #aaa; color: white; font-size: smaller; text-align: center; border: 3px solid #444;">
    Non-Functional Requirements
  </th></tr>
  <tr><td colspan=2 style="text-align: justify; text-justify: inter-word; padding-left: 10px; padding-right: 10px; font-size: smaller; border: 3px solid #444;">
    NFR 1. The ontology shall be published online with standard documentation.
  </td></tr>
  <tr><th colspan=2 style="background-color: #aaa; color: white; font-size: smaller; text-align: center; border: 3px solid #444;">
    Functional Requirements: Groups of Competency Questions
  </th></tr>
  <tr>
    <th style="background-color: #aaa; color: white; font-size: smaller; text-align: center; border: 3px solid #444;">
      CQG1. Related to trust envelopes components
    </th>
    <th style="background-color: #aaa; color: white; font-size: smaller; text-align: center; border: 3px solid #444;">
      CQG2. Related to regulatory compliance
    </th>
  </tr>
  <tr>
    <td style="text-align: justify; text-justify: inter-word; padding-left: 10px; padding-right: 10px; font-size: smaller; border: 3px solid #444;">
      CQ1. Who are the entities to which the data is related?<br>
      CQ2. Who are the entities involved in the data exchange?<br>
      CQ3. Who are the entities that have rights over the data?<br>
      CQ4. Which are the conditions for using the data?<br>
      CQ5. In which context was the data generated?
    </td>
    <td style="text-align: justify; text-justify: inter-word; padding-left: 10px; padding-right: 10px; font-size: smaller; border: 3px solid #444;">
      CQ6. Which obligations and requirements need to be fulfilled to be legally compliant?<br>
      CQ7. What is the legal identification of the involved entities?
    </td>
  </tr>
</table>