ids policy language · © fraunhofer ids policy language jaroslav pullmann (fraunhofer fit)...

© Fraunhofer

IDS Policy Language

Jaroslav Pullmann (Fraunhofer FIT)

Sebastian Bader (Fraunhofer IAIS)

Dr. Christian Mader (Fraunhofer IAIS)

IDSA Webinar, 2018/12/21

© Fraunhofer of 35

Agenda

General introduction

Policy specification

Policy enforcement

Discussion

© Fraunhofer of 35

Introduction

Data Soveregnity

Motivation for usage control

Background on usage control

Access control vs. Usage control

© Fraunhofer of 35

Industrial Data Space // Value propositionData Sovereignty

Source: https://www.internationaldataspaces.org/publications/ids-ram2-0/

© Fraunhofer of 35

Implementing Data SovereigntyMotivation for usage control

Source: https://www.internationaldataspaces.org/publications/ids-ram2-0/

© Fraunhofer of 35

Motivating scenario

Source: Fraunhofer IESE

© Fraunhofer of 35

Authorization

Permission to (group of) subject(s) to perform an operation such as read (R), write (W), execute (X) upon a target object

Access control matrix

Subject’s static authorizations on object(s)

Access controlBaseline

File A Device B

Subject 1 read, execute

write

Access control list (ACL)

Capability list/ access profile

© Fraunhofer of 35

Access controlStatic entity model

environment Attribute 1 Attribute 2 Attribute N

subject Attribute 1 Attribute 2 Attribute N

object Attribute 1 Attribute 2 Attribute N

© Fraunhofer of 35

Usage controlProperties

subject Attribute 1.1 Attribute 2.4 Attribute N

Mutability

Subject and object attributes

Updates as result of usage

access count, duration, balance

Continuity of access enforcement

pre | on | post access

mutability

© Fraunhofer of 35

Usage control model / UCONDecision factors (ABC)

Authorization(A)

Obligations(B)

Conidtions(C)

requirement (action) on subject to gain/sustain access

environmental requirements to be satisfied prior to access/usage

© Fraunhofer of 35

Time

Storage for at least, or at most particular amount of time

Cardinality

Restricted number of accesses, renderings or distributions

Occurrence of events

Permission to use unless it's revoke

Actions

Attribute, notify of use, pay etc.

Technical/legal restrictions

Encrypted storage, distribution in anonymized format only

Recency

maintenance of an up-to-date, normative version of data

Purpose of use

non-commercial, scientific purpose etc.

Example obligationsPer dimension

© Fraunhofer of 35

Policy specification

Abstract policy model

Open Digital Rights Language (ODRL)

IDS Policy language / ODRL Profile

Examples

Open issues

Konzept eines “Profils“ einführen –

welche gibt‘s noch?

IDS Policy Sprache als „Profil“ darstellen ?

Policy Sprache als „shared language“

© Fraunhofer of 35

Usage Control in the IDS Architecture

Industrial Data Space

Information

System

Process

Functional

Business

Secu

rity

Ce

rtifi

cati

on

Go

vern

ance

Layers Perspectives

Usage Policy

Language

© Fraunhofer of 35

Usage control language – General concepts

Source: Reference Architecture Document 2.0 / Information Layer

© Fraunhofer of 35

ODRL Information Model

Source: https://www.w3.org/TR/odrl-model/

© Fraunhofer of 35

Policy

Group of one or more Rules formally stating usage arrangements among parties

Supports negotiation by dedicated subtypes

Set

Abstract Rules over an Asset, no privileges granted (default)

Assertion

Claimed Rules over an Asset from a party

Request

Proposed Rules over an Asset from an assignee

Offer

Proposed Rules over an Asset from an assigner

Agreement

Granted Rules over an Asset from an assigner to an assignee

Ticket

Granted Rules over an Asset from an assigner to a holder of the ticket

Core ODRL concepts – Policy

© Fraunhofer of 35

Rule

Abstract concept representing common characteristics of Rule types

Rule governs exactly one Action, applies to at most one Asset

Permission

Ability (of a Party) to exercise an Action over an Asset

May involve a Duty with Action(s), as a precondition to be granted

Prohibition

The inability (of a Party) to exercise an Action over an Asset

Duty (Obligation)

The obligation (of a Party) to exercise an agreed Action

Penalty (consequence) for not fulfilling an agreed Duty, or having infringed a Prohibition

Core ODRL concepts – Rule

© Fraunhofer of 35

Party (Agent)

Entity or a collection of entities (PartyCollection) that undertake Roles in a Rule (agent), i.e. functions (assigner, assignee etc.)

Intended members (parties) selected via refinement Constraint

Asset

Resource or a collection of resources (AssetCollection) that are the subject of a Rule (all the members are subject of the Rule)

Action

Operation on an Asset, as part of a Rule, refined by Constraint(s)

Examples: aggregate, annotate, anonymize, append, archive etc.

Core ODRL concepts continued

© Fraunhofer of 35

Expression that governs and refines the applicability of:

Rule (start < date < end)

Action (print at resolution >= X)

Members of a Party or Asset collection: (role = admin)

Multiple constraints are implicitly AND-connected (conjunction)

Logical Constraint

Meta-constraints combining existing Constraints via operand sub-properties:

or - at least one of the Constraints MUST be satisfied

xone - only one, and not more, of the Constraints MUST be satisfied

and - all of the Constraints MUST be satisfied

andSequence - all of the Constraints - in sequence - MUST be satisfied

Constraints compare two Operands via an Operator

operator(left operand, right operand)

Core ODRL conceptsConstraint

© Fraunhofer of 35

Operator

Operation (function) of a constraint expression

Examples: eq, gt, gteq, hasPart, isA, isAllOf, isAnyOf etc.

Operand

Parameter of a Constraint expression

Left operand

Named condition of asset, context or party compared to right operand

Examples: absolutePosition, absoluteSize, absoluteSpatialPosition, absoluteTemporalPosition, count, dateTime, delayPeriod etc.

Right operand

Value or value list (scalar or IRI)

Optional data type (xsd:integer), unit (Euro)

Optional status, i.e. most recent value generated by left operand

Core ODRL concepts – Constraints continued

© Fraunhofer of 35

Examples (1)

<http://example.com/policy:1111>a odrl:Agreement;odrl:permission [

a odrl:Permission ;odrl:target <http://example.com/message-id/SpecificOperationOfADataService> ;odrl:assigner <http://example.com/Supplier> ;odrl:assignee <http://example.com/OEM> ;odrl:action odrl:use;odrl:constraint [

a odrl:LogicalConstraint ;odrl:or (_:purposeRM _:purposeBNM) ;

]] ; odrl:prohibition [

a odrl:Prohibition ;odrl:target <http://example.com/message-id/SpecificOperationOfADataService> ;odrl:assigner <http://example.com/Supplier> ;odrl:assignee <http://example.com/OEM> ;odrl:action odrl:use;odrl:constraint [

a odrl:LogicalConstraint ;odrl:or (_:purposeP _:purposeS) ;

]] .

© Fraunhofer of 35

Examples (2)

_:purposeRMa odrl:Constraint ;odrl:leftOperand odrl:purpose;odrl:operator odrl:eq ;odrl:rightOperand ids:RiskManagement .

_:purposeBNMa odrl:Constraint ;odrl:leftOperand odrl:purpose;

odrl:operator odrl:eq ; odrl:rightOperand ids:BottleNeckManagement .

_:purposePa odrl:Constraint ;odrl:leftOperand odrl:purpose;odrl:operator odrl:eq ;odrl:rightOperand ids:Purchasing .

_:purposeSa odrl:Constraint ;odrl:leftOperand odrl:purpose;

odrl:operator odrl:eq ; odrl:rightOperand ids:Sales .

© Fraunhofer of 35

Examples (2)

policy:1111

:SpecificOperationOfDataServ

ice

:Supplier :OEM odrl:use

[ a odrl:Permission

]

odrl:permission

_:purposeSodrl:or

_:purposePodrl:or

odrl:target odrl:assigneeodrl:assigner odrl:action

odrl:constraint

[ a odrl:LogicalConstraint ]

© Fraunhofer of 35

Examples (2)

[ a odrl:Prohibition

]

:SpecificOperationOfDataServ

ice

odrl:prohibition

odrl:target

:Supplier

odrl:assigner

:OEM

odrl:assignee

odrl:use

odrl:action

[ a odrl:LogicalConstraint ]

odrl:constraint

_:purposeRModrl:or

_:purposeBNM

odrl:or

policy:1111

© Fraunhofer of 35

Examples (2)

_:purposeRM rdf:type

ids:RiskManagement

odrl:rightOperand

odrl:eq

odrl:operator

odrl:Constraint

odrl:purpose

odrl:leftOperand

© Fraunhofer of 35

Asset

Reference to parametrized, generated (web) resource

Persistent and consistent identity of resources

Subject to rules on Data Provider and Data Consumer side

Subject to perpetual rule evaluation (access counter etc.)

Action

Formally agreed, shared semantics

Parametrization, observation, quality assurance etc.

Constraint

Units

Status maintenance

Left operand

Information demand, sources and evaluation

Context, Asset, Party, Action

Specification Open issues (excerpt)

© Fraunhofer of 35

Policy enforcement

Enforcement levels

General concepts (Reference monitor)

Architecture / Service deployment

Processes

Implementations in IDS

© Fraunhofer of 35

Usage controlEnforcement levels

Specification Level Policies (SLP) – declarative contracts (natural language or machine-readable)

Implementation Level Policies (ILP) – machine-interpretable and enfor- cable (technology-dependent)

Policy mapping

© Fraunhofer of 35

Usage control enforcement implementationsIND2UCE // Fraunhofer IESE

Source: https://developer.mydata-control.de/

© Fraunhofer of 35

Usage control enforcement implementationLabel based Usage CONtrol (LUCON)Fraunhofer AISEC

Source: https://industrial-data-space.github.io/trusted-connector-documentation/docs/usage_control/

© Fraunhofer of 35

Data provenance trackingPrivacy dashboard // Fraunhofer IOSB

Logging of the transaction history (data flows)

Distributed storage of provenance data

Aggregation and visualization for the “data owner”


Transformation

Human intervention / configuration required

Context

Maintenance (update, access etc.) via PIP

Potential for privacy conflicts

Processing

Sequencing of tasks

Conflict resolution

Enforcement Open issues (excerpt)


Discussion

Questions

Feedback

Follow-up actions

ids policy language · © fraunhofer ids policy language jaroslav pullmann (fraunhofer fit)...

Documents