LogoLogo
How to Build Dataspaces?Main IDSA AssetsOther ResourcesManifesto for International Data Spaces
IDS-G
IDS-G
  • Changelog
  • Code of Conduct
  • Contributing to IDS-G-pre
  • LICENSE
  • International Data Spaces Global (IDS-G)
  • Overview
    • Message Structure/Format
    • Message Types
    • media
    • Communication Protocols
      • IDS REST
        • header
        • IDS Linked Data Notification (IDS-LDN)
          • IDS-REST requests
            • IDS-LDN, send a PUT request
      • IDS Communication Protocol Version 2 (IDSCP2)
        • IDSCP2 Application Layer
          • Examples
        • IDSCP2 Transport Layer
          • Examples
      • multipart
    • sequence-diagrams
      • Message Flows for Connector to Clearing House Communication
      • IDS Connector Communication
        • images
      • IDS Metadata Broker Communication
  • Components
    • IDS App Store (IDS-CH)
    • ClearingHouse
    • IDS Connector
    • IDS Identity Provider
      • Connector Identifiers (Connector IDs)
      • Certificate Authority (CA)
      • Dynamic Attribute Provisioning Service (DAPS)
        • requests
          • DAPS DAT request (root POST)
      • ParIS
        • ParIS requests
          • IDS-ParIS GET root request
    • IDS Meta Data Broker
      • General Overview
      • Introduction
      • Annex
        • HTTP API
        • Removed Requirements
      • Functions and Correlated Messages
        • Messages received by a Broker
        • Messages send by a Broker as Response
      • IDS Meta Data Broker Profiles
        • Advanced Information Profile
        • Usage Control Profile
      • IDS Meta Data Broker Requirements
        • Behavioral Requirements
        • Business Requirements
        • Conditional Requirements
        • Connector Requirements
        • Functional Requirements
        • Informational Requirements
        • Interface Requirements
        • Message Requirements
        • Role of an IDS Meta Data Broker
      • IDS-MDB requests
        • IDS-MDB GET root request
  • Glossary
    • IDS Shortcuts
  • Handbook to IDS-G
    • Specification
  • IDS Information Model
    • ids:Message
      • DescriptionRequestMessage POST
      • Message requests
  • Overview of the IDS Architecture
    • References
    • Relevant Documents
      • IDS Repositories
  • IDS Usage Control
    • IDS Usage Control Contract
      • Policies
      • images
    • IDS Policy Enforcement
      • System Adapter Technical Documentation
      • Concepts
        • Concepts for Data Sharing
    • Specification
      • Concepts
        • Access Control for the Contract Metadata
        • T7_ODRL_policies
        • Interfaces Standardization for Context Information (PIPs) and Actions to be Performed (PXPs)
        • Concepts for Participant-restricted policies and reselling data
  • .github
    • ISSUE_TEMPLATE
      • content-change-request
      • epic
      • feature-request
      • topic--code
      • topic--documentation
      • topic--quickfix
      • topic--structure
Powered by GitBook

Links:

  • IDSA Website
  • IDSA Github
  • Legal Notice
  • Privacy Policy

© 2016 – 2025 | All Rights Reserved | International Data Spaces Association

On this page
  • Usage Control Enforcement
  • Usage Control Enforcement via Route/Interceptor
  • Usage Control Aware External Apps (http-based Web Services)
  • Usage Control Aware Internal Apps
Edit on GitHub
  1. IDS Usage Control

IDS Policy Enforcement

Last updated 1 year ago

Usage Control Enforcement

At runtime, the usage control enforcement prevents IDS connectors from treating data in an undesired way, for example by forwarding personal data to public endpoints.

image

For enforcing usage restrictions, data flows need to be monitored and potentially intercepted by control points (i.e., PEPs). These intercepted data flows are given to the decision engine (i.e., the PDP) for requesting permission or denial of the data flow. In addition to just allowing or denying the data flow, the decision can also require a modification of data.

Enforcement Layers

  • Connector/Container Layer

  • Route/Interceptor Layer

  • Application Layer


Usage Control Enforcement via Route/Interceptor

Use case: The Data App is allowed to use (process, display, etc.) the data

Usage Control tasks:

  • Check the conditions (Time interval, Data App, Events, etc.)

Condition:

  • Data App inside a connector

  • UC app inside a Connector


Use case: The Data App is allowed to use (process, display, etc.) and store the data

Usage Control tasks:

  • Check the conditions (Time interval, Data App, Events, etc.)

  • Log usage information

  • Inform a Party about the usage

  • Setting up a Delete Data PXP

Condition:

  • Data App inside a connector

  • Data sink inside a Connector

  • UC app inside a Connector


Use case: The Data App is allowed to use (process, display, etc.) the data and distribute it outside the connector

Usage Control tasks:

  • Check the conditions (Time interval, Data App, Events, etc.)

  • Log usage information

  • Inform a Party about the usage

Condition:

  • Data App inside a connector

  • System Adapter inside a Connector

  • UC app inside a Connector


Usage Control Aware External Apps (http-based Web Services)

Characteristics:

  • Data format must be json compatible

  • Hooking points must be known and implemented

Advantages:

  • One UC service can be used by many Data Apps (reusable)

  • Easier Policy Management


Use case: The Data App is restricted to use (process, print, display and store) the data

Usage Control tasks:

  • Check the conditions (Time interval, Data App, Events, etc.)

  • Log usage information

  • Inform a Party about the usage

  • Hook into the data flow (for fine-grained actions)

  • Modify in transit

  • Count usage

Condition:

  • Data App inside a connector

  • UC app inside a Connector

  • JSON data exchange


Use case: The Data App shall read and store the data via System Adapter App

  • System Adapter App encrypts and decrypts data that is stored/retrieved from a database outside a connector.

Usage Control tasks:

  • Check the conditions (Time interval, Data App, Events, etc.)

  • Log usage information

  • Inform a Party about the usage

  • Hook into the data flow in the System Adapter App

  • Modify in transit

  • Setting up a Delete Data PXP

Condition:

  • Data App inside a connector

  • System Adapter inside a Connector

  • UC app inside a Connector

  • Data Storage outside a Connector


Usage Control Aware Internal Apps

Characteristics:

  • It can be MYDATA or any other implementation.

  • Data format depends on the implementation of the Usage Control technology

  • Hooking points must be known and implemented

Advantages:

  • More independent solution (wrt. Programming language, data format, etc.)

Disadvantages:

  • Higher implementation effort

  • Higher effort for Policy Management


Use case: The Data App is allowed to use (print and display) the data

Usage Control tasks:

  • Check the conditions (Time interval, Data App, Events, etc.)

  • Log usage information

  • Inform a Party about the usage

  • Hook into the data flow (for fine-grained actions)

  • Modify in transit

  • Count Usage

Condition:

  • Data App inside a connector

  • UC app inside a Data App


uc-components

More information:

image
image
image
image
image
image
Usage Control in the International Data Spaces