Trust Envelope specification

1. Introd­uction

TODO:

1.1. Terminology

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.

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

TODO:

• add worked out examples

• current approach on how to signatures + limitations

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.

TODO: singing comments The history, comprising the data and it provenance, and the destiny, comprising the policy and its provenance, are each individually signed. These two signed entities are then encapsulated within an overarching signature at the Trust Envelope level

TODO: comments regarding policy being an agreement, meaning it is a contract and thus binding

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 .

<https://country.org/uuid1> 

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

5.2. Cargo Monitoring

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