Vers une formalisation des langages de DRM (Digital Right Management)

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 FNAC 1. 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 Group 2 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 allprincipals 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 accord 4 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 keyholder est donc un élément de substitution pour principal 4 Comme 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 vide 5. 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 permission 6 p. L activation 7 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 6 Ou groupe de permissions grantgroup 7 Une permission est dite activée quand l utilisateur sollicite légitimement cette permission 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 Trusted- Principal. 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 exemple 8 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 Schema Part 0 : Primer, 2001. www.w3.org/tr/2001/rec-xmlschema-0-20010502/. [17] World Wide Web Consortium (W3C). XML Schema Part 1 : Structures, 2001. www.w3.org/tr/2001/rec-xmlschema-1-20010502/. [18] World Wide Web Consortium (W3C). XML-Signature Syntax and Processing, 2002. www.w3.org/tr/xmldsig-core/. [19] World Wide Web Consortium (W3C). Extensible Markup Language (XML) 1.0 (Third Edition), 2004. www.w3.org/tr/rec-xml/. 10