IDS POLICY LANGUAGE · © Fraunhofer IDS Policy Language Jaroslav Pullmann (Fraunhofer FIT)...
Transcript of 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 Page 2 of 35
Agenda
General introduction
Policy specification
Policy enforcement
Discussion
© Fraunhofer Page 3 of 35
Introduction
Data Soveregnity
Motivation for usage control
Background on usage control
Access control vs. Usage control
© Fraunhofer Page 4 of 35
Industrial Data Space // Value propositionData Sovereignty
Source: https://www.internationaldataspaces.org/publications/ids-ram2-0/
© Fraunhofer Page 5 of 35
Implementing Data SovereigntyMotivation for usage control
Source: https://www.internationaldataspaces.org/publications/ids-ram2-0/
© Fraunhofer Page 6 of 35
Motivating scenario
Source: Fraunhofer IESE
© Fraunhofer Page 7 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 Page 8 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 Page 9 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 Page 10 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 Page 11 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 Page 12 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 Page 13 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 Page 14 of 35
Usage control language – General concepts
Source: Reference Architecture Document 2.0 / Information Layer
© Fraunhofer Page 15 of 35
ODRL Information Model
Source: https://www.w3.org/TR/odrl-model/
© Fraunhofer Page 16 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 Page 17 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 Page 18 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 Page 19 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 Page 20 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 Page 21 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 Page 22 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 Page 23 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 Page 24 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 Page 25 of 35
Examples (2)
_:purposeRM rdf:type
ids:RiskManagement
odrl:rightOperand
odrl:eq
odrl:operator
odrl:Constraint
odrl:purpose
odrl:leftOperand
© Fraunhofer Page 26 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 Page 27 of 35
Policy enforcement
Enforcement levels
General concepts (Reference monitor)
Architecture / Service deployment
Processes
Implementations in IDS
© Fraunhofer Page 28 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 Page 29 of 35
Usage control enforcementComponent deployment
© Fraunhofer Page 30 of 35
Usage control enforcement implementationsIND2UCE // Fraunhofer IESE
Source: https://developer.mydata-control.de/
© Fraunhofer Page 31 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 Page 32 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”
© Fraunhofer Page 34 of 35
Usage control enforcementComponent deployment
© Fraunhofer Page 35 of 35
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)
© Fraunhofer Page 36 of 35
Discussion
Questions
Feedback
Follow-up actions