Trust Envelope specification

1. Introd­uction

TODO:

1.1. Terminology

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

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.

3. Model

TODO: Add figures here

4. Vocabulary

4.1. Classes

4.1.1. Trust Envelope

4.1.2. Data Provenance

4.1.3. Policy Provenance

4.2. Properties

4.2.1. Provenance

4.2.2. Sender

4.2.3. Recipient

4.2.4. Rights holder

4.2.5. Sign

5. Materialization

5.1. Age Verification

As such, she sends a Trust Envelope to 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:read ;
  odrl:target ex:x ;
  odrl:constraint ex:constaint1 .

ex:constraint1 a odrl:Constraint ;
  odrl:leftOperand odrl:purpose ;
  odrl:operator odrl:eq ;
  odrl:rightOperand "Age Verification" .

ex:signedEnvelope1 a sign:Signature ;
  sign:value "...";
  sign:target ex:envelope1 ;
  sign:issuer <https://alice.org>.

ex:signedDataProvenance1 a sign:Signature ;
  sign:value "...";
  sign:target ex:dataProvenance1 ;
  sign:issuer <https://alice.org>.

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 properlyW.

5.2. Cargo Monitoring

Beverage Company (BC) 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.

TODO: (analogous as age verification use case)

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. 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 te:      <https://w3id.org/trustenvelope#>.
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .