- From: Víctor Rodríguez Doncel <vrodriguez@fi.upm.es>
- Date: Tue, 15 Nov 2016 08:18:16 +0100
- To: public-poe-wg@w3.org
- Message-ID: <27a5da7d-cdc4-ab56-4b51-61c95c082eee@fi.upm.es>
Hi!
Three ideas in this email. Please see below.
First, I have read the "conformance" in XACML. Somewhat ill-defined,
conformance is defined in terms of expected behaviour and features of
the processable input and output (reserved words which cannot be used etc.).
Conformant XACML implementations must /support/ (sic) some elements
(whatever support is), must execute some rule and policy combining
algorithms (cf. odrl:conflict), and must implement some functions of the
sort of:
urn:oasis:names:tc:xacml:1.0:function:string-equal
As an exercise, I will try to express (before today's call) the
"football embargo restriction" in OASIS XACML, I think it is possible.
>
> My memory is a bit hazy, but I think I got the “context” idea from
> looking at other rules engines like Drools? So I certainly don’t claim
> it as original to me. And the fact that the concept appears in other
> similar systems is an indication that it might be a good idea.
>
Second. Curiosity about context. Yes. Also it is a keyword in the XACML
world. We read here
http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html (red
color is mine) ....
Context
The canonical representation of adecision requestand anauthorization
decision
Context handler
The system entity that convertsdecision requestsin the native
request format to the XACML canonical form, coordinates with Policy
Information Points to add attribute values to the request context,
and convertsauthorization decisionsin the XACML canonical form to
the native response format
> I certainly agree with your suggestion that we decide upon and
> document the processing model for ODRL. I attempted to do so for
> RightsML http://dev.iptc.org/RIghtsML-Processing-Model with an eye to
> how news is typically licensed.
>
Third, as an implementor, I love the simplicity of the flowchart...
Regards,
Víctor
>
> Regards,
>
> Stuart
>
> *From:*Víctor Rodríguez Doncel [mailto:vrodriguez@fi.upm.es]
> *Sent:* Saturday, November 12, 2016 7:53 AM
> *To:* public-poe-wg@w3.org
> *Subject:* Re: About a more strict definition of Constraint
>
> Stuart,
>
> 1) I have just learnt about your code at
> https://github.com/iptc/rightsml-dev/
> <https://github.com/iptc/rightsml-dev/>. Good!
>
> 2) I share your vision. When you speak about context reminds me about
> the authorisation model in MPEG-21 REL, which had as input not only
> the request and the specified licenses but also the "authorization
> context". In the MPEG-21 REL this was insufficiently formalized, and
> the authorization algorithm was a very poorly described procedure. I
> wished this could be improved this tiem.
>
> Víctor
>
> El 09/11/2016 a las 23:49, Myles, Stuart escribió:
>
> Hi Simon,
>
> ØHow would your engine evaluate/determine whether constrained
> permission
> is valid?
> I.e., x <= "2010-12-31"^^xsd:date -> where does "x" come from?
>
>
> What I wound up doing was creating a “context” for each requested
> action. The context consists of a series of assertions that
> correspond to things that could be constraints, such as location,
> purpose, time of execution and so on. In fact, I (re)used the
> “constraint” part of ODRL to express the context assertions. Since
> the engine can “understand” a set of possible types of
> constraints, I realized that possible set implies the range of
> constraint slots which need to be filled.
>
> So, in your example, I would have a slot for time for execution,
> which corresponds to “x”.
>
> The ODRL representation library I built is
> https://github.com/iptc/rightsml-dev/tree/master/licensed although
> the engine where I actually evaluate whether a particular action
> is permitted is an API that layers on top of licensed. Maybe one
> day I will get around to sprucing it up a bit and releasing that
> as open source, too?
>
> Regards,
>
> Stuart
>
> *From:*Simon Steyskal [mailto:simon.steyskal@wu.ac.at]
> *Sent:* Wednesday, November 09, 2016 2:33 AM
> *To:* Myles, Stuart
> *Cc:* W3C POE WG
> *Subject:* Re: About a more strict definition of Constraint
>
> Hi!
>
> > (What follows is all based on my experience with implementing an
> > engine to evaluate ODRL automatically. [...]
>
> Just out of curiosity (sry for hijacking your email discussion)..
> Given
> following ODRL policy:
>
> <http://example.com/policy:0811>
> a odrl:Set;
> odrl:permission [
> a odrl:Permission ;
> odrl:action odrl:play ;
> odrl:target <http://example.com/game:4589> ;
> odrl:constraint [
> a odrl:Constraint ;
> odrl:operator odrl:lteq ;
> odrl:dateTime "2010-12-31"^^xsd:date
> ]
> ] .
>
> How would your engine evaluate/determine whether constrained
> permission
> is valid?
> I.e., x <= "2010-12-31"^^xsd:date -> where does "x" come from?
>
> br, simon
>
> ---
> DDipl.-Ing. Simon Steyskal
> Institute for Information Business, WU Vienna
>
> www: http://www.steyskal.info/ <http://www.steyskal.info/>
> twitter: @simonsteys
>
> Am 2016-11-08 16:13, schrieb Myles, Stuart:
> > I don’t see how it is meaningful to constrain either parties or
> > targets. In fact, I think it just introduces problems for evaluating
> > policies.
> >
> > (What follows is all based on my experience with implementing an
> > engine to evaluate ODRL automatically. And it is the same
> argument for
> > why I think it is a mistake to indicate any properties of parties
> > other than their URI - such as whether or not they are a “group”).
> >
> >
> > When you’re evaluating an ODRL policy, you’re trying to determine
> > “Am I permitted to perform this action on this asset?”. More
> > generally, it could be stated as “Is Party P permitted to perform
> > Action A on Asset X?”. That means you need to determine whether
> > various entities in the Policy are “the same as” the entities
> > you’re interested in. Is the Policy Asset “the same as” Asset X
> > and is the Policy Assignee “the same as” Party P? (In fact, it is
> > much more complicated than this, as you also need to determine
> whether
> > the Policy Action is “the same as” Action A – ODRL actions are
> > hierarchical, so it is quite likely the action you wish to
> perform is
> > very granular, but the Policy Action could be much more general – an
> > ancestor of Action A in the ODRL tree. And the same thing applies to
> > values for constraints such as location – the Policy may constrain
> > actions in Europe. And you might want to perform the Action in
> > Istanbul or Geneva or London).
> >
> > So, a lot of the work that an ODRL evaluation engine must perform is
> > to evaluate rules to determine whether various values are “the same
> > as” other values. So, what would it mean to introduce constraints on
> > those values in the Policy itself? How can a Party have both a URI
> > *AND* a constraint? What is that meant to mean? I can understand a
> > Party URI which means “people known to be 18 years and older”. But
> > I don’t understand how an engine is meant to evaluate a URI and a
> > constraint – unless we want to introduce rules for how to deal with
> > contradictions between what is stated in the Policy constraints and
> > what is “known” by the evaluating engine.
> >
> > Regards,
> >
> > Stuart
> >
> > FROM: Renato Iannella [mailto:renato.iannella@monegraph.com]
> > SENT: Tuesday, November 08, 2016 8:40 AM
> > TO: W3C POE WG
> > SUBJECT: Re: About a more strict definition of Constraint
> >
> > I think the general issue is that we have associated the
> Constraint to
> > the Perm/Prohib/Duty, when we should have associated it directly to
> > the Action/Name.
> >
> > Michael’s example show that with the “odrl:constraintsubject”
> > having to explicitly refer to the odrl:action.
> >
> > And this gets worse when we introduce support for Constraints on
> > Asset’s and Parties.
> >
> > *IF* we move the constraint directly as a property of the
> Action/Name,
> > then we could express:
> >
> > odrl:permission [
> >
> > a odrl:Permission ;
> >
> > odrl:target <http://example.com/music:4545 [1]> ;
> >
> > odrl:assigner <http://example.com/sony:10 [2]> ;
> >
> > odrl:action [
> >
> > a odrl:Action ;
> >
> > rdf:value odrl:copy ;
> >
> > odrl:constraint [
> >
> > a odrl:Constraint ;
> >
> > odrl:count 1 ;
> >
> > odrl:operator odrl:lteq
> >
> > ]
> >
> > ]
> >
> > ] .
> >
> > This makes the constraint clearly associated with the odrl:copy
> action
> > (and all constraints in that Action will apply to the same).
> >
> > Then, when we add a Constraint to the Target, the subject is clear:
> >
> > odrl:target [
> >
> > a odrl:Asset ;
> >
> > rdf:value <http://example.com/music:4545 [1]> ;
> >
> > odrl:constraint [
> >
> > a odrl:Constraint ;
> >
> > spotify:artist <http://music.net/people:prince [3]> ;
> >
> > odrl:operator odrl:eq
> >
> > ]
> >
> > ]
> >
> > And the same for Party:
> >
> > odrl:assignee [
> >
> > a odrl:Party ;
> >
> > rdf:value <http://example.com/billie> ;
> >
> > odrl:constraint [
> >
> > a odrl:Constraint ;
> >
> > spotify:age 18 ;
> >
> > odrl:operator odrl:gteq
> >
> > ]
> >
> > ]
> >
> > Then we have our favourite example…the constraint on a constraint.
> >
> > The constraint “end of the football match” is further constrained
> > by a “30 min time period”:
> >
> > odrl:action [
> >
> > a odrl:Action ;
> >
> > rdf:value odrl:distribute ;
> >
> > odrl:constraint [
> >
> > a odrl:Constraint ;
> >
> > odrl:event <http://premier-league.com/end-of-match ;
> >
> > odrl:operator odrl:eq ;
> >
> > odrl:constraint [
> >
> > a odrl:Constraint ;
> >
> > odrl:dateTime "P30M" ;
> >
> > odrl:operator odrl:gteq ;
> >
> > ]
> >
> > ]
> >
> > ] .
> >
> > Renato
> >
> > ps: i’ve used rdf:value here but we could define our own predicate
> >
> > Links:
> > ------
> > [1] http://example.com/music:4545 <http://example.com/music:4545>
> > [2] http://example.com/sony:10 <http://example.com/sony:10>
> > [3] http://music.net/people:prince <http://music.net/people:prince>
>
>
>
> --
> Víctor Rodríguez-Doncel
> D3205 - Ontology Engineering Group (OEG)
> Departamento de Inteligencia Artificial
> ETS de Ingenieros Informáticos
> Universidad Politécnica de Madrid
> Campus de Montegancedo s/n
> Boadilla del Monte-28660 Madrid, Spain
> Tel. (+34) 91336 3753
> Skype: vroddon3
--
Víctor Rodríguez-Doncel
D3205 - Ontology Engineering Group (OEG)
Departamento de Inteligencia Artificial
ETS de Ingenieros Informáticos
Universidad Politécnica de Madrid
Campus de Montegancedo s/n
Boadilla del Monte-28660 Madrid, Spain
Tel. (+34) 91336 3753
Skype: vroddon3
Received on Tuesday, 15 November 2016 07:20:39 UTC