IDS Usage Control Contract
Usage Control Terms in IDS Contracts
An IDS Contract, also reffered to as IDS Policy, is implicitly divided to two main sections: the contract specific metadata and the Usage Control Rules of the contract.
The IDS Usage Control Rules are the key motive of organizational and technical Usage Control enforcement and address several Data Usage Control statements (e.g., permissions, prohibitions and obligations). An IDS Contract is specified in the IDS Usage Control Language which is the IDS technology independent language based on ODRL Policy Language.
Usage Policy Specification
Policy Classes
A Policy Class is an atomic policy template which refers to a specific restriction on Data Usage. Here are a list of 21 Policy Classes:
Restrict the usage of data to:
Data Consumer
This policy restricts the usage of the data to a specific Data Consumer, regardless of how many connectors they have and without any further usage restriction.
Example for Policy Class 1: Restrict consumer - IDS
Example for Policy Class 1: Restrict consumer - ODRL
IDS Connector
The Connector-restricted Data Usage policy restricts the usage of the data to a specific IDS connector of a specific Data Consumer assuming that the Data Consumer owns one or more IDS Connector(s).
Example for Policy Class 2: Restrict connector - IDS
Example for Policy Class 2: Restrict connector - ODRL
Application inside a Connector
The Application-restricted Data Usage policy restricts the usage of the data to a specific application inside an IDS connector.
Example for Policy Class 3: Restrict application - IDS
Example for Policy Class 3: Restrict application - ODRL
User Role
This policy restricts the usage of the data to a specific users (e.g. users with specific roles or users who are members of a specific organization, etc.).
Example for Policy Class 4: Restrict user (role) - IDS
Example for Policy Class 4: Restrict user (role) - ODRL
Example (2) for Policy Class 4: Restrict user (role) - ODRL
Location of usage
The Location-restricted Data Usage policy restricts the usage of the data to a specific location. It may be expressed as names of areas or set of geographic points.
Example for Policy Class 5: Restrict location of usage - IDS
Example for Policy Class 5: Restrict location of usage - ODRL
Example (2) for Policy Class 5: Restrict location of usage - ODRL
Purpose
The Purpose-restricted Data Usage policy restricts the usage of the data to specific purposes such as "marketing", "research", "Defect Analysis".
Example for Policy Class 6: Restrict purpose - IDS
Example for Policy Class 6: Restrict purpose - ODRL
Example (2) for Policy Class 6: Restrict purpose - ODRL
Example (3) for Policy Class 6: Restrict purpose - ODRL
Event
The Event-restricted Data Usage policy restricts the usage of the data to specific events such as "Hannover Messe 2018" .
Example for Policy Class 7: Restrict event - IDS
Example for Policy Class 7: Restrict event - ODRL
Security Level
The Security Level-restricted Data Usage policy restricts the usage of the data to a Specific IDS Connector when it is certified for a specified security level (i.e. idsc:BASE_SECURITY_PROFILE, idsc:TRUST_SECURITY_PROFILE and idsc:TRUST_PLUS_SECURITY_PROFILE).
Example for Policy Class 8: Restrict security level - IDS
Example for Policy Class 8: Restrict security level - ODRL
Time Interval
The time interval-restricted Data Usage policy restricts the usage of the data to a specific time interval.
Example for Policy Class 9: Restrict time interval - IDS
Example for Policy Class 9: Restrict time interval - ODRL
Duration
The Duration-restricted Data Usage policy restricts the usage of the data to a specific period.
Example for Policy Class 10: Restrict duration - IDS
Example for Policy Class 10: Restrict duration - ODRL
Number of usage
This policy may be specified as “the Data Consumer is allowed to use my data not more than n times”.
Example for Policy Class 11: Restrict number of usage - IDS
Example for Policy Class 11: Restrict number of usage - ODRL
Delete Data
This policy demands to delete data either immediately after it is used, or after a delay period or before a defined deadline.
Example for Policy Class 12: Delete data - IDS
Example for Policy Class 12: Delete data - ODRL
Example (2) for Policy Class 12: Delete data - ODRL
Modify Data in Transit
This policy demands to intercept the data flow and modify the data in transit.
Example for Policy Class 13: Modify data in transit - IDS
Example for Policy Class 13: Modify data in transit - ODRL
Modify Data in Rest
This policy demands to modify the data fields of a repository inside a connector.
Example for Policy Class 14: Modify data in rest - IDS
Example for Policy Class 14: Modify data in rest - ODRL
Log Data Usage Information
This policy demands to log the Data Usage information either locally or on the Clearing House.
Example for Policy Class 15: Log usage information - IDS
Example for Policy Class 15: Log usage information - ODRL
Note: A Policy Enforcement Point (PEP) intercepts the data flow and waits for an authorization decision from the Policy Decision Point (PDP). A Policy Execution Point (PXP) which is responsible to log the information could return a boolean value to the PDP and eventually influence the PEP. In a case that the Clearing House is not available, the PXP cannot execute the duty action and therefore it would return a False value to the PDP. Eventually, the PEP can block the data flow after receiving a usage deny from the PDP. A policy would specify such a case slightly different than what is shown above.
Inform a participant about the Data Usage
This policy demands to inform a participant (e.g. person, organization), or even the Clearing House about the Data Usage. For example, inform a party via Email or a notification system.
Example for Policy Class 16: Notify participant - IDS
Example for Policy Class 16: Notify participant - ODRL
Pass a Policy to the Third-party
This policy demands to pass a policy to a third-party before distributing the data to them.
Example for Policy Class 17: Next policy - IDS
Example for Policy Class 17: Next policy - ODRL
Artifact State
The Artifact state-restricted Data Usage policy restricts that the data is used (or distributed) when it is encrypted, anonymized, combined, etc.
Example for Policy Class 18: Restrict artifact state - IDS
Example for Policy Class 18: Restrict artifact state - ODRL
Data Sale Contract
In this policy it is assumed that the payment has been done once.
Example for Policy Class 18: Payment for sale - IDS
Example for Policy Class 18: Payment for sale - ODRL
Example(2) for Policy Class 18: Payment for sale - ODRL
Data Rental Contract
In this policy it is assumed that the payment shall happen frequently (e.g. monthly)
Example for Policy Class 19: Payment for rent - IDS
State The State-restricted Data Usage policy restricts the usage of the data to specific environment state. For example, the data only can be used in an application when the firewall is activated.
Location of the Participant
This policy class restricts the data usage to location of the Participant.
Example for Policy Class 22: Location of the Participant - ODRL
User’s consent
This policy class restricts the data usage to obtain user’s consent.
Data Classification
This policy class restricts the data usage to the data classification.
Data Anonymization
This policy class demands to anonymize data before the data is used. Particularly, apply Privacy Enhancing Technologies (PETs).
Usage Control Policy It is an identified policy that is a combination of one or more instances of the policy classes. Example: "The Data Consumer X shall use my data not later than 30th of December 2022 and only for defect analysis purpose."
Policy Editor
A policy editor or in XACML terminology a Policy Administration Point (PAP) supports data owners and data providers in specifying their usage restrictions. The IDS Policy editor comprises a Graphical User Interface and offers a Policy Specification guidance to the user.
Policy Negotiation
A negotiation process takes care of the potential bargaining between a Data Provider and a Data Consumer regarding the usage conditions. An Offer Contract and a Request Contract are created by a Data Provider and a Data Consumer, respectively, and reflect their Data Usage requirements and demands. As a result of a Policy Negotiation process, it is expected that the involved parties reach an agreement. The corresponding Agreement Contract is specified in IDS Usage Policy Language and shall be enforced to their systems.
More information: Data Sovereignty: Updated Position Paper on Data Usage Control in the IDS
Policy Transformation
The technically enforceable rules shall be transformed to a technology dependent policy to facilitate the Usage Control enforcement of data sovereignty. In order to support the Data Usage Control technologies, the policy transformation service is additionally added to the IDS Policy Editor. Currently, it supports the transformation to enforceable policies for the MY DATA Control Technologies. The support for other technologies and further extension will follow.
Authors
| Name | Organization | Github |
|---|---|---|
Arghavan Hosseinzadeh | Fraunhofer IESE | |
Robin Brandstädter | Fraunhofer IESE |
Last updated
