Vers une formalisation des langages de DRM (Digital Right

Vers une formalisation des langages de DRM
(Digital Right Management)
Thierry Sans
Frédéric Cuppens
{thierry.sans,frederic.cuppens}@enst-bretagne.fr
GET/ENST-Bretagne
2, rue de la Châtaigneraie
35576 Césson Sévigné - France
Résumé
La gestion des droits numérique (DRM) a pour objectif de contrôler l’accès, l’usage et la diffusion
de contenus numériques. Dans ce contexte, XrML est un langage permettant d’exprimer des droits
sous forme de licences. Ce langage a servi de support à la définition du langage MPEG-REL utilisé
dans la norme ISO MPEG-21. Cet article présente les concepts de XrML ainsi que la syntaxe pour
exprimer des licences. Nous dégageons certaines limites de XrML et justifions le besoin de définir une
sémantique formelle pour ce langage. L’objectif de ces travaux préliminaires est d’étudier comment
améliorer l’expressivité de XrML. Pour cela, nous voulons nous appuyer sur les concepts définis dans
le modèle Or-BAC pour étendre le langage XrML.
1
Introduction
Au cœur de l’économie numérique, le DRM (Digital Right Management), autrement dit la gestion
des droits numériques doit répondre aux exigences de contrôle d’accès et de diffusion de tout contenu
numérique. Afin de satisfaire ces exigences, il est nécessaire de spécifier un règlement énonçant les
conditions d’utilisation d’un contenu numérique et d’apporter les outils nécessaires afin d’appliquer ce
règlement. Ce règlement est souvent exprimé sous forme de licence. Une licence est une sorte de contrat
entre un fournisseur d’une ressource et un consommateur. Un langage permettant d’exprimer de telles
licences se doit d’être simple et expressif afin de couvrir les besoins exprimés dans le langage naturel.
David Parott en 2001 à mener une étude pour le groupe de travail sur la gestion des droits numérique
MPEG-21 [13]. Dans cette étude, il analyse les différents cas d’utilisation des licences et spécifie les exigences que doit satisfaire tout langage de droits REL (Rights Expression Language). Des langages comme
XrML (eXtensible Rights Markup Language) [3] ou ODRL (Open Digital Rights Language) [10] ont été
développés pour pouvoir exprimer de telles licences. Ces langages ont été proposés dans une perspective
de protéger des données telles que du son ou de la vidéo, de spécifier les conditions d’utilisation d’un
logiciel ou encore de contrôler l’accès à des web-services. Nous pouvons prendre pour exemple le système
de téléchargements de la FNAC1 . Une licence pourra exprimer une règle simple telle que “n’importe quel
utilisateur a la permission de lire un fichier audio en payant 2 euro” ou bien des licences plus complexes
telles que “un membre de la FNAC a la permission de lire 10 fichiers audio par mois” ou bien “lire un
nombre illimité de fois un certain fichier audio tant qu’il est membre en payant 1 euro”. Ces licences sont
vérifiées à l’aide du lecteur Windows Media Player de Microsoft. Sur le même principe, on peut citer le
système iTunes d’Apple pour ses baladeurs iPod ou bien encore le système mis en place dans RealPlayer
par RealNetworks. Tous ces systèmes sont aujourd’hui propriétaires et manquent d’interopérabilité, d’où
la nécessité d’un standard dans le domaine du DRM.
1 www.fnac.com
rubrique “télécharger”
1
Dans le cadre de cet article nous allons nous intéresser à XrML. XrML eXtensible Rights Markup
Language est un langage de droit développé par la société ContentGuard [3]. En 2000, XrML avait reçu le
soutien de plusieurs acteurs des technologies de l’information comme notamment Adobe, Microsoft, HP
labs, Xerox. Microsoft s’est inspiré de XrML pour implanter son système de gestion des droits numériques
utilisé dans Windows Media Player 9. De plus, le Moving Picture Group2 a choisi XrML comme langage
répondant aux spécifications du MPEG-21 Rights Expression Language. Depuis avril 2004, une norme
ISO concernant MPEG REL [11] est née. Le monde du DRM œuvre pour l’émergence d’un standard
pour l’expression et la gestion des droits numériques. MPEG REL pourrait bien être ce standard.
Dans la suite, la section 2 présentera plus en détails l’architecture XrML et la section 3 décrira la
syntaxe XrML. Nous verrons dans la section 4 les mécanismes pour mettre en application ces licences.
Ensuite la section 5 posera la problématique d’une sémantique formelle pour XrML. Dans la section 6,
nous aborderons le problème de la mise en œuvre de cette sémantique en étendant la syntaxe XrML
existante ainsi que les mécanismes à mettre en place pour pouvoir interpréter ces licences.
2
Architecture XrML
XrML se base sur les technologies XML du W3C. La définition de sa syntaxe et de sa grammaire s’appuie sur les schémas XML [16][17]. XML permet à XrML d’être un langage de haut niveau d’expressivité
et d’une grande interopérabilité. De plus, XML [19] apporte une grande souplesse pour étendre le langage.
Fig. 1 – Architecture XrML
Xrml se décompose en trois parties illustrés par la figure 1 :
– La partie noyau “core schema” définit les concepts liés aux notions de licence, de permission,
de sujet, d’action, de ressource et de condition. Nous reviendrons sur ces notions dans la section
suivante. Les définitions relatives à cette partie sont identifiées par le préfixe d’espace de nom XML
“r :”.
– La partie “standard extension schema” est une extension contenant les définitions permettant de
mettre en œuvre XrML dans des cas généraux. Elle s’appuie sur les définitions “abstraites” de la
partie noyau. Ces définitions sont apparues avec la version 2.0 de XrML. Les définitions relatives
à cette partie sont identifiées par le préfixe d’espace de nom XML “sx :”.
– La partie “content specific extension schema” est une extension contenant des définitions relatives
à la gestion de contenu numérique. Cette extension définit les notions de droit, de condition et de
ressource relatives à certains domaines d’application comme la diffusion de livres électroniques, du
son ou de vidéo. Les définitions relatives à cette partie sont identifiées par le préfixe d’espace de
nom XML “cx :”.
De la même manière que sont définies les extensions “standard extension” et “content specific extension”, l’utilisateur peut définir ses propres extensions pour une application spécifique. L’utilisation des
espaces de noms [15] pour définir de nouvelles extensions permet de garantir l’absence de conflit entre
les différentes définitions de schéma XML.
2 www.chiariglione.org/mpeg/
2
3
Les licences XrML
La partie noyau (core schema) contient les définitions abstraites de la syntaxe de base de XrML. Le
noyau définit donc les concepts liés aux notions de licence, de permission, de sujet, d’action, de ressource
et de condition. Le concept de licence est illustré par la figure 2. Dans cette section, nous allons d’abord
présenter la permission et revenir sur la licence elle-même.
Fig. 2 – Concept de XrML
3.1
La permission
La permission (grant) permet d’exprimer la relation “un sujet a la permission de faire une certaine
action sur une ressource sous une certaine condition.” La figure 3 représente la structure XML de la
permission. Les éléments sujet (principal), action (right), ressource (resource) et condition (condition)
sont “abstraits” au sens XrML. Ces éléments ne seront pas utilisés tels quels pour définir une permission.
On utilisera des élément de substitution à ces entités abstraites. Ce mécanisme de substitution est donné
dans la définition des schémas XML [16].
Le sujet (principal) permet de définir l’entité active de la permission, celle pour laquelle il est permis
d’exécuter une action sur un objet sous une certaine condition. Pour définir le sujet, XrML utilise le
concept de certificat et associe le sujet à une clé publique (keyholder)3 . Afin de représenter les informations relatives au certificat, XrML utilise la description XML des signatures électroniques [18], et plus
particulièrement de la description des certificat X.509.
Il est possible de définir l’entité active d’une permission comme un ensemble de sujets à l’aide de
l’élément allP rincipals. L’élément allP rincipals signifie que le droit est octroyé pour l’ensemble des
sujets du moment qu’ils agissent d’un commun accord. Une permission ayant pour sujet un élément
allP rincipals ne signifie donc pas que le droit est octroyé pour chaque sujet, mais que le droit est activé
si l’ensemble des sujets agissent de manière commune. Plusieurs parties doivent se mettre d’accord4
afin qu’une action soit possible. Néanmoins, un ensemble de sujets ne peut être vu actuellement comme
une entité à part entière. En effet, il est impossible de décrire un ensemble de sujets autrement qu’en
identifiant chacun des sujets de cet ensemble à l’aide du mécanisme de certificat pris en compte dans
3 L’élément
4 Comme
keyholder est donc un élément de substitution pour principal
par exemple dans le cas d’une signature de contrat
3
Fig. 3 – Schéma XML de la permission (grant)
XrML (keyholder). Chaque sujet de l’ensemble doit donc être identifié séparément pour que la permission
soit octroyée à l’ensemble des sujets.
L’utilisateur peut également définir ses propres mécanismes d’identification des sujets. Pour cela, il
devra définir une extension et un nouveau type de sujet comme élément de substitution de principal.
Remarque : l’absence de sujet dans une permission revient à définir une permission valable pour tout
le monde. De même lorsqu’on définit un élément allPrincipals vide5 .
L’action (right) est l’élément permettant de définir ce que peut faire le sujet avec la ressource. La
partie noyau de XrML définit quatre éléments de substitution à right.
– Le droit d’émission (issue) permet de donner une permission à un autre sujet. Considérons une
permission p telle que le sujet s a le droit d’émettre une nouvelle permission6 p′ . L’activation7 de la
permission p par le sujet s entraı̂ne, via le mécanisme d’interprétation des licences, la création d’une
nouvelle licence l signée par le sujet s de p (l/issuer = p/principal) et contenant la permission p′
(l/grant = p/resource = p′ ).
– Le droit de révocation (revoke) permet à un sujet d’invalider une signature de licence existante.
Ainsi toutes les licences concernées par cette signature seront alors révoquées.
– La définition de propriété (PossessProperty) permet de spécifier une caractéristique d’un sujet
comme une appartenance à un groupe ayant une propriété commune. Il est ainsi possible de définir
une permission s’appliquant à tout sujet ayant cette propriété en commun.
– L’obtention d’un droit (obtain) permet a un sujet de rendre effective une nouvelle permission p′
définie en tant qu’élément ressource de la permission initiale p. Dès lors que l’utilisateur active la
permission p, une nouvelle permission p′ est alors susceptible d’être activée.
L’extension “content specific extension” définit des actions spécifiques concernant la gestion des
documents numériques.
La ressource (resource) est l’objet sur lequel le sujet a la permission de faire une action. La ressource
peut être par exemple un contenu numérique (livre électronique, musique, image, vidéo ...), un serviceweb, une propriété ou une permission.
5 Sans
aucun sous-élément
groupe de permissions grantGroup
7 Une permission est dite activée quand l’utilisateur sollicite légitimement cette permission
6 Ou
4
La condition spécifie les contraintes qui devront être satisfaites afin que la permission soit effective. Ces
contraintes peuvent représenter un certain contexte d’utilisation de la ressource ou bien une obligation
dont le sujet doit s’acquitter pour bénéficier de la permission. L’absence de définition de condition se
traduit par une permission inconditionnelle et donc indépendante du contexte d’utilisation.
Pour décrire la condition, les éléments de substitution suivants sont définis dans le noyau :
– allConditions, une conjonction de conditions est requise.
– existsRight permet de vérifier qu’une certaine permission a été définie par un émetteur de confiance.
La notion de sujet de confiance peut être définie au niveau d’une licence grâce à l’élément T rustedP rincipal.
– prerequisiteRight permet de vérifier qu’une permission existe et qu’il est possible de l’activer.
– revocationFreshness permet de spécifier un temps de rafraı̂chissement de la validité de la signature
de la licence. Cette notion est rattachée a celles de révocation de certificat et de révocation de
licence.
– validityInterval, la permission est valable sur un certain intervalle de temps.
Parmi les autres champs de la permission, on trouve :
– delegationControl permet de déléguer une permission à un ou plusieurs sujets.
– forAll permet de définir des variables.
– encryptedGrant permet de chiffrer le contenu de la permission.
3.2
La licence (license)
Dans la pratique, en plus de définir un ensemble de permissions, il est parfois utile d’identifier l’entité
émettrice de ces permissions (the issuer). C’est pour cette raison que XrML définit le concept de licence
qui regroupe un ensemble de permissions et une description de l’entité qui a émis les permissions. La
licence est le concept le plus important dans XrML. La licence est un conteneur de permissions (ou un
groupe de permissions (grantGroup)). Le schéma XML de la licence est représenté par la figure 4.
Fig. 4 – Schéma XML de la licence (license)
Le titre (title) est une description de la licence. Cet élément n’apporte aucune information utile pour
le processus de traitement d’une licence XrML.
5
L’inventaire (inventory) est une commodité syntaxique qui peut être utilisée lorsqu’un même élément
(sujet, action, ressource ou condition) est utilisé plusieurs fois dans une même licence. Ce mécanisme
s’apparente à un mécanisme de définition de macros.
L’émetteur (issuer) est la signature numérique de l’entité émettrice de la licence. La signature est
définie par la recommandation du W3C sur la représentation de la signature en XML [18]. L’émetteur
est celui à l’origine de la (ou des) permission(s). Plusieurs entités peuvent signer la même licence. Actuellement aucune sémantique n’est associée à une signature multiple. Son interprétation dépend de
l’implémentation.
Parmi les autres champs de la licence, on trouve :
– other contient des informations supplémentaires sur la licence. La spécification XrML ne définit
rien sur cet élément. L’utilisateur peut utiliser cet élément comme il le souhaite.
– encryptedGrant, de la même manière que pour la permission, une licence peut avoir son contenu
chiffré.
3.3
Exemple sur un scénario multi-tiers
L’exemple8 illustré par la figure 5, nous montre comment mettre en œuvre ce système de licences
dans le cas d’un scénario multi-tiers.
Fig. 5 – Exemple de scénario multi-tiers
La première licence, écrite par une maison d’édition, décrit qu’un “distributeur” a la permission de
“diffuser” ses morceaux de musique à condition que ce dernier reverse 10% de royalties à la maison de
disque. Pour cela la maison de disque donne la permission au distributeur d’émettre des licences aux
utilisateurs sur ces morceaux de musique.
La seconde licence est celle que le distributeur émet à ses utilisateurs. Elle autorise l’utilisateur à lire
un morceau de musique sous la condition de payer une certaine somme au distributeur. Cette licence sera
signée par le distributeur et par la maison d’édition puisque cette dernière lui en a donné l’autorisation
grâce à la première licence.
8 extrait
de http ://www.contentguard.com/reference/docs/SimpleTierExample.htm
6
La dernière licence permet d’exprimer que le distributeur “jazz online” est un distributeur “reconnu”
par la maison de disque. Pour cela la maison d’édition donne une licence attestant que “jazz online” a
la propriété d’être un distributeur officiel.
Ainsi, grâce à ces trois licences, “jazz online” peut diffuser les morceaux de musique de la maison
d’édition. A chaque fois que “jazz online” émet une licence à ses utilisateurs, ce distributeur a l’obligation
de reverser 10% du montant de la transaction à la maison d’édition.
4
Utilisation des licences XrML
En complément du langage, ContentGuard fournit une plate-forme de développement XrML SDK
[4] pour exploiter les licences. Ce kit de développement permet d’écrire des licences XrML à partir de
modèles (templates XML), et fournit une interface de programmation pour utiliser ces licences.
Fig. 6 – Algorithme d’interprétation des licences XrML
Voici l’algorithme illustré par la figure 6 :
1 : Un utilisateur demande d’exécuter une action sur une ressource via l’application.
2 : L’application génère une requête (principal, resource, right) pour le “license interpreter”.
3 : Le “license interpreter” vérifie qu’une permission correspondant à la requête existe dans l’ensemble
des licences.
4 : Si cette permission existe, le “license interpreter” renvoie la condition à satisfaire à l’application.
5 : L’application va ensuite faire évaluer cette condition par le “condition validator”
6 : Si la condition est vérifiée, alors l’application autorise l’utilisateur à accéder à la ressource.
5
Vers une sémantique formelle pour XrML
Actuellement, XrML est un langage qui n’a pas de sémantique définie formellement. La sémantique de
XrML est seulement définie de manière informelle par l’algorithme d’interprétation des licences XrML.
Cet algorithme détermine à partir d’un ensemble de permissions si une action est permise ou pas.
L’implémentation de cet algorithme dans la SDK [4] est obscure et [9] montre que, dans certains cas,
les résultats fournies par cette implémentation ne correspondent pas à l’interprétation intuitive d’une
licence XrML.
De même, les conditions définies dans XrML n’ont aucune sémantique de sorte que le développeur
ne dispose d’aucune spécification pour implémenter les mécanismes permettant d’évaluer ces conditions.
On peut également constater que l’interprétation des licences n’est pas intuitive dès lors que la
ressource est elle-même une permission.
Un problème incontournable est donc, dans un premier temps, de définir une sémantique formelle
pour XrML et, ensuite, de démontrer que l’algorithme utilisé pour interpréter les licences est correct
vis-à-vis de cette sémantique.
Plusieurs articles soulignent déjà le manque de sémantique de XrML. Ainsi, Gunter et al [7] proposent
d’utiliser la sémantique des langages de programmation pour formaliser un langage de droits numériques.
7
Dans cette étude, une licence est modélisée comme un ensemble de traces, chaque trace étant un ensemble
d’actions autorisées par la licence.
[14] propose une approche basée sur la logique temporelle et la logique déontique pour définir des
licences et prouver certaines propriétés. L’approche est similaire à celle proposée par [7] ; une licence est
une description d’un ensemble d’actions autorisées. Un utilisateur est donc autorisé à faire une action si
cette action appartient à une séquence d’actions autorisées et qu’il a déjà effectué les actions précédant
celle-ci dans cette même séquence.
Halpern et Weissman dans [8] utilisent la logique du premier ordre pour décrire un langage de droits
basé sur les licences. Dans [9], ils reprennent la même démarche en enrichissant le langage à l’aide de la
logique déontique, et proposent une sémantique formelle pour XrML.
Une comparaison entre XrML et ODRL a été effectuée dans [2] pour mettre en évidence les limites
de ces langages. Sur ce constat, les auteurs proposent un nouveau langage de droit LicenceScript [1] basé
sur Prolog.
6
Vers des licences plus expressives
Nos travaux actuels ont pour objectif de proposer une formalisation en logique du premier ordre des
licences et de comparer ce formalisme à celui déjà défini dans Or-BAC [12]. Or-BAC est un modèle formel
de contrôle d’accès et d’usage reposant sur le concept d’organisation. Il permet d’exprimer des règles de
sécurité correspondant à des permissions, des interdictions, des obligations.
Intuitivement, notre démarche consiste à modéliser les licences comme des objets particuliers. On peut
dériver une permission de l’existence d’un tel objet. L’administration des licences est ainsi simplifiée. Le
droit de type issue proposé dans XrML pourrait alors être modélisé comme la création d’un objet de
type licence. C’est la démarche déjà proposée pour administrer les droits dans le modèle Or-BAC [5].
Nous envisageons également d’étendre le langage pour modéliser des licences plus expressives. Ainsi,
dans le langage XrML, il est actuellement difficile de spécifier une licence qui porte sur un ensemble de
ressources, par exemple l’ensemble des morceaux de jazz, sans avoir à énumérer toutes les ressources de
cet ensemble ou sans avoir recours à une description de l’ensemble de ces morceaux. De même, si l’on
souhaite définir une licence qui donne la permission de réaliser plusieurs actions, il faut énumérer dans
la licence ces différentes actions sous forme de right.
Pour augmenter l’expressivité des licences, nous pouvons nous inspirer de plusieurs concepts proposés
dans le modèle Or-BAC. Dans Or-BAC, les concepts d’organisation, de rôle, de vue et d’activité ont été
introduits. Une permission est émise par une organisation et relie un rôle, une activité et une vue. Une
telle permission est ensuite interprétée de la façon suivante : n’importe quel sujet jouant ce rôle a la
permission de réaliser n’importe quelle action correspondant à cette activité sur n’importe quel objet
appartenant à cette vue. On peut ainsi définir une permission qui concerne l’ensemble des morceaux de
jazz (en définissant une vue contenant les morceaux de jazz) ou qui porte sur un ensemble d’actions (en
définissant une activité qui regroupe cet ensemble d’actions).
Il parait donc intéressant d’utiliser ces différents concepts de rôle, d’activité et de vue pour étendre
la notion de licence XrML (voir figure 7). Le modèle Or-BAC introduit également la notion de contexte
pour définir des permissions conditionnelles. Nous avons modélisé cette notion dans [6], en particulier
nous avons proposé plusieurs types de contexte. L’utilisation de la notion de contexte permettrait de
formaliser les conditions associées à une licence XrML. XrML nous parait donc être un bon moyen de
traduire une modélisation Or-BAC afin de mettre en application un règlement de sécurité par ce système
de licences.
Enfin, la notion d’obligation est définie implicitement dans XrML. Par exemple, l’obligation de payer
1 euro pour écouter un certain fichier audio est représentée implicitement sous forme d’une condition
attachée à la licence. Cependant, dans certains cas, il parait nécessaire de représenter explicitement la
notion d’obligation, par exemple lorsque l’obligation de payer est déclenchée une fois que le fichier audio
a été écouté. Ce problème constitue une autre extension possible de XrML que nous souhaitons étudier.
8
Fig. 7 – L’extension OrBAC
7
Conclusion
XrML vise à répondre à des besoins commerciaux très divers qui nécessitent un langage de haute
expressivité. Du fait même de cette orientation commerciale de XrML, il est nécessaire de définir une
sémantique précise pour ce langage afin que les licences puissent être interprétées de façon non ambiguë.
Donner une sémantique formelle à XrML constitue donc un premier objectif de nos travaux.
On peut également constater que XrML peut probablement être appliqué à d’autres domaines non
commerciaux, par exemple pour contrôler l’accès à des données confidentielles ou contrôler l’utilisation
de données devant répondre à des exigences d’intégrité et de disponibilité élevées. Dans ce cas, des
adaptations de XrML sont probablement nécessaires pour augmenter son expressivité. Pour cela, certains
concepts déjà présents dans le modèle Or-BAC [12] semblent pertinents.
Signalons enfin que les travaux sur le langage XrML ont depuis avril 2004 abouti à une norme ISO
sous la dénomination MPEG-REL [11]. MPEG-REL a été défini par le groupe de travail MPEG-21 et
reprend les concepts déjà présents dans XrML. Nos travaux de recherche porteront donc dorénavant sur
la norme MPEG-REL.
Remerciements Pour ce travail, Thierry Sans et Frédéric Cuppens sont financés au travers de l’ACI
CASC du Ministère de la Recherche.
Références
[1] Cheun Ngen Chong, Ricardo Corin Sandro Etalle, and Pieter H. Hartel. LicenseScript : A Novel
Digital Rights Language and its Semantics. In 3rd International Conference on Web Delivering
Music (WEDELMUSIC’O3), Los Alamitos, California, September 2003.
9
[2] Cheun Ngen Chong, Sandro Etalle, and Pieter H. Hartel. Comparing Logic-based and XML-based
Rights Expression Languages. In Workshop on Metadata for Security, International Federated
Conferences (OTM’03), Catania, Italy, November 2003.
[3] ContentGuard.
eXtensible Rights Markup Language (XrML) 2.0 Specifications, 2001.
www.contentguard.org.
[4] ContentGuard. XrML Software Development Kit : User’s Guide, 2001. www.contentguard.com.
[5] Frédéric Cuppens and A Miège. adOr-BAC : An Administration Model for Or-BAC. In Workshop
on Metadata for Security, International Federated Conferences (OTM’03), Catania, Italy, November
2003.
[6] Frédéric Cuppens and Alexandre Miège. Modelling Contexts in the Or-BAC Model. In 19th Applied
Computer Security Associates Conference (ACSAC 2003), Las Vegas, Nevada, December 2003.
[7] Carl A. Gunter, Stephen T. Weeks, and Andrew K. Wright. Models and Languages for Digitals
Rights. In 34th Hawaii International Conference on System Sciences (HICSS’01), Maui, Hawaii,
January 2001.
[8] Joseph Y. Halpern and Vicky Weissman. Using First-Order Logic to Reason about policies. In 16th
IEEE Computer Security Foundation Workshop (CSFW’03), Pacific Grove, California, June 2003.
[9] Joseph Y. Halpern and Vicky Weissman. A Formal Foundation for XrML. In 17th IEEE Computer
Security Foundation Workshop (CSFW’04), Pacific Grove, California, June 2004.
[10] Renato Iannella. Open Digital Rights Management (ODRL). In World Wide Web Consortium
Workshop on Digital Rights Management for the Web (W3C DRM’01), Sophia-Antipolis, France,
January 2001.
[11] International Organization for Standardization (ISO). ISO/IEC 21000-5 :2004 Information
technology – Multimedia framework (MPEG-21) – Part 5 : Rights Expression Language, 2004.
www.iso.ch/iso/fr/prods-services/popstds/mpeg.html.
[12] A. Abou El Kalam, R. El Baida, P. Balbiani, S. Benferhat, F. Cuppens, Y. Deswarte, A. Miège,
C. Saurel, and G. Trouessin. Organization Based Access Control (Or-BAC). In IEEE 4th International Workshop on Policies for Distributed Systems and Networks (Policy 2003), Lake Come,
Italy, June 2003.
[13] David Parott. Requirements for a Rights Data Dictonary and Rights Expression Language. Technical
report, Reuters, June 2001.
[14] Riccardo Pucella and Vicky Weissman. A Logic For Reasoning about Digital Rights. In 15th IEEE
Computer Security Foundation Workshop (CSFW’02), Cape Breton, Canada, June 2002.
[15] World Wide Web Consortium (W3C). Namespaces in XML, 1999. www.w3.org/TR/REC-xmlnames/.
[16] World Wide Web Consortium (W3C).
XML
www.w3.org/TR/2001/REC-xmlschema-0-20010502/.
Primer,
2001.
[17] World Wide Web Consortium (W3C).
XML Schema Part 1 : Structures,
www.w3.org/TR/2001/REC-xmlschema-1-20010502/.
2001.
[18] World Wide Web Consortium (W3C).
www.w3.org/TR/xmldsig-core/.
Schema
Part
0
:
XML-Signature Syntax and Processing, 2002.
[19] World Wide Web Consortium (W3C). Extensible Markup Language (XML) 1.0 (Third Edition),
2004. www.w3.org/TR/REC-xml/.
10