Trustflows

1. Introd­uction

TODO: what are trust flows Trustflow and Trust Envelope

1.1. Terminology

Trustflow

A Trustflow is a secure data flow that explicitly embeds trust using cryptographic methods, provenance, usage policies, etc., to ensure reliability and integrity.

Trust Envelope

TODO:

Sticky Policy

TODO:

1.2. Requirements

• Identity: The need to be able to trust the identity or claims of a party

• Usage Control: The need that only authorized parties can use the data for a well-defined purpose

  • also related to confidentiality from the CIA triad

• Data minimization: The need to only disclose the minimal amount of data that other parties require for the processing

• Separation of concerns:

  • Argument one: choice -> no vendor lock-in (apple ecosystem, IDP ecosystem)

    • choice of IDP

    • choice of authorization server per resource (to get an access token)

  • Argument two: indepent evolution -> relies on interoperabilty and standardization (without that, it is impossible to have indepent evolution)

  • Argument three: knowledge: knowledge is fragmented at different places (there is no one place with all knowledge)

• Data Integrity: Classic information security. The need for proof/verification that data has not been tampered with.

• Interoperability: The ability of computer systems or software to exchange and make use of information. (oxford definition)

2. Components

2.1. Trust Envelope

• Sticky policy represent restrictions on the use of data, which are directly attached to the corresponding data (Ines: https://www.sciencedirect.com/science/article/pii/S1574013724000819) -> need for standardization language for expressing it -> context associations Ruben D

  • origin: sticky policy paradigm comes from P3P paper: Platform for Enterprise Privacy Practices: Privacy-enabled Management of Customer Data (2002)

    • P3P is obsolete since 2018 (W3C source)

  • suggestion of strong stickiness: Towards Accountable Management of Identity and Privacy: Sticky Policies and Enforceable Tracing Services (2003)

  • iterated upon (worked out) in Sticky Policies: An Approach for Managing Privacy across Multiple Parties (2011)

    • def 1: Machine-readable policies can stick to data to define allowed usage and obligations as it travels across multiple parties, enabling users to improve control over their personal information. The EnCoRe project has developed such a technical solution for privacy management that is suitable for use in a broad range of domains.

    • def 2: conditions and constraints attached to data that describe how it should be treated

  • Sticky Policies: A Survey (2019)

    • shows renewed interest

  • characteristics of sticky (usage control policy)

    • purpose (use of data)

    • constraints on subject and action

    • deontic rules (prohibitions and opbligations)

    • notification of disclosure and/or deletion (enforcement)

    • trusted authorities: provide assurance and accountability in the process of granting access to the protected data, potentially the result of a negotiation process.

    • strong binding -> integrity check due to cryptographic means

Trust envelope extends sticky policies by also incorporating the following

• provenance: where does the information come from?

• semantics: what exactly is in the envelope?

  • data selection and discovery purposes?

TODO: What do we mean with that; How does it differ from a sticky policy?

Technologies envisioned:

• Reference to [Context-Associations]

2.2. Policy Engine

TODO: What do we mean with that

Technologies envisioned

• Reference to [ODRL-MODEL]

• Reference to [FORCE]

• Reference to SDS paper

• Reference to XACML?

2.3. Credential Verifier

TODO: What do we mean with that

Technologies envisioned

• Reference to [OIDC]

• Reference to [WebID] and [Solid-OIDC]

• Reference to [DID] and [VC-data-model]

2.4. Data Minimization

TODO: What do we mean with that

• ZKP

• SPARQL + CSS -> Joachim paper

3. Architecture

TODO: check out the whitepaper [A4DS]

Rerefence to user managed access server?

4. Supporting Materials

5. Namespaces

Commonly used namespace prefixes used in this specification:

@prefix dct:    <http://purl.org/dc/terms/> .
@prefix odrl:   <http://www.w3.org/ns/odrl/2/>.
@prefix rca:    <https://w3id.org/context-associations> .
@prefix rdf:    <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix report: <https://w3id.org/force/compliance-report#>
@prefix xsd:    <http://www.w3.org/2001/XMLSchema#> .