XACML Media Type: eXtensible Access Control Markup Language (XACML) XML Media Type
An official MIME type for access control policy documents
Sinnema, R. and E. Wilde, "eXtensible Access Control Markup Language (XACML) XML Media Type", RFC 7061, DOI 10.17487/RFC7061, November 2013, <https://www.rfc-editor.org/info/rfc7061>.
@misc{rfc7061,
series = {Request for Comments},
number = 7061,
howpublished = {RFC 7061},
publisher = {RFC Editor},
doi = {10.17487/RFC7061},
url = {https://www.rfc-editor.org/info/rfc7061},
author = {R. Sinnema and E. Wilde},
title = {{eXtensible Access Control Markup Language (XACML) XML Media Type}},
pagetotal = 8,
year = 2013,
month = nov,
} RFC text
Contents
Independent Submission R. Sinnema
Request for Comments: 7061 E. Wilde
Category: Informational EMC Corporation
ISSN: 2070-1721 November 2013
eXtensible Access Control Markup Language (XACML) XML Media Type
Abstract
This specification registers an XML-based media type for the
eXtensible Access Control Markup Language (XACML).
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7061.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 2
2.1. XACML Media Type application/xacml+xml . . . . . . . . . . 2
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
4. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The eXtensible Access Control Markup Language (XACML) [XACML-3]
defines an architecture and a language for access control
(authorization). The language consists of requests, responses, and
policies. Clients send a request to a server to query whether a
given action should be allowed. The server evaluates the request
against the available policies and returns a response. The policies
implement the organization's access control requirements.
2. IANA Considerations
This specification details the registry of an XML-based media type
for the eXtensible Access Control Markup Language (XACML) that has
been registered with the Internet Assigned Numbers Authority (IANA)
following the "Media Type Specifications and Registration Procedures"
[RFC6838]. The XACML media type represents an XACML request,
response, or policy in the XML-based format defined by the core XACML
specification [XACML-3].
2.1. XACML Media Type application/xacml+xml
This specification details the registration of an XML-based media
type for the eXtensible Access Control Markup Language (XACML).
Media Type Name: application
Subtype Name: xacml+xml
Required Parameters: none
Optional Parameters:
charset: The charset parameter is the same as the charset
parameter of application/xml [RFC3023], including the same default
(see Section 3.2 of RFC 3023).
version: The version parameter indicates the version of the XACML
specification. It can be used for content negotiation when
dealing with clients and servers that support multiple XACML
versions. Its range is the range of published XACML versions. As
of this writing, that is 1.0 [XACML-1], 1.1 [XACML-1.1], 2.0
[XACML-2], and 3.0 [XACML-3]. These and future version
identifiers must follow the Organization for the Advancement of
Structured Information Standards (OASIS) patterns for versions
[OASIS-Version]. If this parameter is not specified by the
client, the server is free to return any version it deems fit. If
a client cannot or does not want to deal with that, it should
explicitly specify a version.
Encoding Considerations: Same as for application/xml [RFC3023].
Security Considerations:
Per their specification, objects of type application/xacml+xml do
not contain executable content. However, these objects are XML-
based, and thus they have all of the general security
considerations presented in Section 10 of RFC 3023 [RFC3023].
XACML [XACML-3] contains information about whose integrity and
authenticity is important -- identity provider and service
provider public keys and endpoint addresses, for example.
Sections 9.2.1 "Authentication" and 9.2.4 "Policy Integrity" in
XACML [XACML-3] describe requirements and considerations for such
authentication and integrity protection.
To counter potential issues, the publisher may sign objects of
type application/xacml+xml. Any such signature should be verified
-- both as a valid signature and as being the signature of the
publisher -- by the recipient of the data. The XACML v3.0 XML
Digital Signature Profile [XACML-3-DSig] describes how to use XML-
based digital signatures with XACML.
Additionally, various possible publication protocols, for example,
HTTPS, offer means for ensuring the authenticity of the publishing
party and for protecting the policy in transit.
Interoperability Considerations: Different versions of XACML use
different XML namespace URIs:
* 1.0 and 1.1 use the urn:oasis:names:tc:xacml:1.0:policy XML
namespace URI for policies and the
urn:oasis:names:tc:xacml:1.0:context XML namespace URI for
requests and responses
* 2.0 uses the urn:oasis:names:tc:xacml:2.0:policy XML namespace
URI for policies and the urn:oasis:names:tc:xacml:2.0:context
XML namespace URI for requests and responses
* 3.0 uses the urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 XML
namespace URI for policies, requests, and responses
Signed XACML has a wrapping Security Assertion Markup Language
(SAML) 2.0 assertion [SAML-2], which uses the
urn:oasis:names:tc:SAML:2.0:assertion namespace URI.
Interoperability with SAML is defined by the SAML 2.0 Profile of
XACML [XACML-3-SAML] for all versions of XACML.
Applications That Use This Media Type:
Potentially, any application implementing or using XACML, as well
as those applications implementing or using specifications based
on XACML. In particular, applications using the Representational
State Transfer (REST) Profile [XACML-REST] can benefit from this
media type.
Magic Number(s):
In general, this is the same as for application/xml [RFC3023]. In
particular, the XML document element of the returned object will
be one of xacml:Policy, xacml:PolicySet, context:Request, or
context:Response. The xacml and context namespace prefixes bind
to the respective namespace URIs for the various versions of XACML
as follows:
* 1.0 and 1.1: The xacml prefix maps to
urn:oasis:names:tc:xacml:1.0:policy; the context prefix maps to
urn:oasis:names:tc:xacml:1.0:context
* 2.0: The xacml prefix maps to
urn:oasis:names:tc:xacml:2.0:policy; the context prefix maps to
urn:oasis:names:tc:xacml:2.0:context
* 3.0: Both the xacml and context prefixes map to the namespace
URI urn:oasis:names:tc:xacml:3.0:core:schema:wd-17
For signed XACML [XACML-3-DSig], the XML document element is saml:
Assertion, where the saml prefix maps to the SAML 2.0 namespace
URI urn:oasis:names:tc:SAML:2.0:assertion [SAML-2].
File Extension(s): none
Macintosh File Type Code(s): none
Person & Email Address to Contact for Further Information:
This registration is made on behalf of the OASIS eXtensible Access
Control Markup Language Technical Committee (XACMLTC). Please
refer to the XACMLTC website for current information on committee
chairperson(s) and their contact addresses:
http://www.oasis-open.org/committees/xacml/. Committee members
should submit comments and potential errors to the
xacml@lists.oasis-open.org list. Others should submit them by
filling out the web form located at http://www.oasis-open.org/
committees/comments/form.php?wg_abbrev=xacml.
Additionally, the XACML developer community email distribution
list, xacml-dev@lists.oasis-open.org, may be employed to discuss
usage of the application/xacml+xml MIME media type. The xacml-dev
mailing list is publicly archived here:
http://www.oasis-open.org/archives/xacml-dev/. To post to the
xacml-dev mailing list, one must subscribe to it. To subscribe,
visit the OASIS mailing list page at
http://www.oasis-open.org/mlmanage/.
Intended Usage: common
Author/Change Controller:
The XACML specification sets are a work product of the OASIS
eXtensible Access Control Markup Language Technical Committee
(XACMLTC). OASIS and the XACMLTC have change control over the
XACML specification sets.
3. Security Considerations
The security considerations for this specification are described in
Section 2.1 of the media type registration.
4. Normative References
[OASIS-Version]
Organization for the Advancement of Structured Information
Standards, "OASIS Naming Directives Version 1.3",
December 2012, <http://docs.oasis-open.org/specGuidelines/
ndr/namingDirectives.html#Version>.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013.
[SAML-2] Organization for the Advancement of Structured Information
Standards, "Assertions and Protocols for the OASIS
Security Assertion Markup Language (SAML) V2.0",
OASIS Standard, March 2005, <http://docs.oasis-open.org/
security/saml/v2.0/saml-core-2.0-os.pdf>.
[XACML-1] Organization for the Advancement of Structured Information
Standards, "eXtensible Access Control Markup Language
(XACML) Version 1.0", OASIS Standard, February 2003,
<http://www.oasis-open.org/committees/download.php/2406/
oasis-xacml-1.0.pdf>.
[XACML-1.1]
Organization for the Advancement of Structured Information
Standards, "eXtensible Access Control Markup Language
(XACML) Version 1.1", OASIS Committee Specification,
August 2003, <http://www.oasis-open.org/committees/xacml/
repository/cs-xacml-specification-1.1.pdf>.
[XACML-2] Organization for the Advancement of Structured Information
Standards, "eXtensible Access Control Markup Language
(XACML) Version 2.0", OASIS Standard, February 2005,
<http://docs.oasis-open.org/xacml/2.0/
access_control-xacml-2.0-core-spec-os.pdf>.
[XACML-3] Organization for the Advancement of Structured Information
Standards, "eXtensible Access Control Markup Language
(XACML) Version 3.0", OASIS Standard, January 2013,
<http://docs.oasis-open.org/xacml/3.0/
xacml-3.0-core-spec-os-en.pdf>.
[XACML-3-DSig]
Organization for the Advancement of Structured Information
Standards, "XACML v3.0 XML Digital Signature Profile
Version 1.0", OASIS Committee Specification 01,
August 2010, <http://docs.oasis-open.org/xacml/3.0/
xacml-3.0-dsig-v1-spec-cs-01-en.pdf>.
[XACML-3-SAML]
Organization for the Advancement of Structured Information
Standards, "SAML 2.0 Profile of XACML, Version 2.0", OASIS
Committee Specification 01, August 2010,
<http://docs.oasis-open.org/xacml/3.0/
xacml-profile-saml2.0-v2-spec-cs-01-en.pdf>.
[XACML-REST]
Organization for the Advancement of Structured Information
Standards, "REST Profile of XACML v3.0 Version 1.0", OASIS
Committee Specification 01, April 2013,
<http://docs.oasis-open.org/xacml/xacml-rest/v1.0/
xacml-rest-v1.0.pdf>.
Appendix A. Acknowledgements
The following individuals have participated in the creation of this
specification and are gratefully acknowledged: Oscar Koeroo (Nikhef),
Erik Rissanen (Axiomatics), and Jonathan Robie (EMC).
Authors' Addresses
Remon Sinnema
EMC Corporation
EMail: remon.sinnema@emc.com
URI: http://securesoftwaredev.com/
Erik Wilde
EMC Corporation
6801 Koll Center Parkway
Pleasanton, CA 94566
USA
Phone: +1-925-600-6244
EMail: erik.wilde@emc.com
URI: http://dret.net/netdret/
AI ELI5
On this page
§1XACML and the Need for a Media Type
The eXtensible Access Control Markup Language (XACML) is a standard for writing access control policies—rules that define who is allowed to perform which actions on which resources. XACML policy documents are written in XML, a text-based format that humans can read and systems can parse. When exchanging XACML documents over the Internet using HTTP or similar protocols, there was no official way to label them, making it unclear to receiving systems whether they were receiving a policy, a request, a response, or something else entirely.
The Internet Assigned Numbers Authority (IANA) maintains a registry of media types (sometimes called MIME types) that label different kinds of content. Media types like text/plain, application/json, and image/png tell systems how to interpret incoming data. This RFC formally registers a media type for XACML, filling a gap in the ecosystem and enabling better interoperability.
When you send a file over email or the web, you tag it with a type like 'image' or 'document'. XACML files needed an official tag so everyone would recognize them.
§2The application/xacml+xml Media Type
The registered media type is application/xacml+xml, following the pattern of other XML-based formats like application/atom+xml and application/json. The media type can represent any of the three main XACML document types: a Policy (which defines access control rules), a PolicySet (a collection of policies), or a Request or Response (used in client-server access control queries).
The media type supports two optional parameters. The charset parameter (defaulting to UTF-8, like other XML media types) specifies the character encoding. The version parameter allows senders to indicate which version of XACML they are using—currently versions 1.0, 1.1, 2.0, and 3.0 exist, and they use different XML namespaces and slightly different structures. This lets receivers handle different XACML versions appropriately, either accepting or rejecting documents based on what they support.
The official tag is 'application/xacml+xml'. You can add optional information like 'I'm using XACML version 3.0' so receivers know what they're dealing with.
§3Security and Interoperability
XACML policy documents can contain sensitive information such as the addresses of identity providers, service providers, and public keys used for authentication and integrity checking. The RFC emphasizes that XACML documents themselves do not contain executable code, but they must be protected just like any other sensitive configuration or access control data. Senders can sign XACML documents using XML Digital Signatures, and transport protocols like HTTPS can protect them in transit.
Interoperability is a key concern because different versions of XACML use different XML namespace URIs. Version 1.0 and 1.1 use namespaces like urn:oasis:names:tc:xacml:1.0:policy, version 2.0 uses urn:oasis:names:tc:xacml:2.0:policy, and version 3.0 consolidates to a single namespace. XACML documents can also be wrapped in SAML 2.0 assertions for signed XACML. The media type registration facilitates these interoperability scenarios by giving applications a clear way to identify and handle XACML documents regardless of version or wrapper.
XACML files can contain secret information about who's allowed to do what, so they should be protected. The official tag helps different systems understand each other even though XACML has been around in different versions.
§4Use Cases and Applications
The primary beneficiaries of this media type registration are applications that use XACML for access control, particularly in cloud computing and REST (Representational State Transfer) architectures. Organizations might use XACML to define fine-grained access policies for APIs, web services, or cloud storage. When a policy document is exchanged over HTTP, having the official media type ensures that both the sender and receiver understand they are dealing with an access control policy.
The media type is also useful for XACML tools, libraries, and frameworks that need to identify and parse incoming documents. Web servers and HTTP clients can use the media type to route documents to the correct handler. Content negotiation (where a client requests documents in specific formats) becomes clearer: a client can explicitly ask for application/xacml+xml version 3.0 if that is what it expects. This registration represents a small but important step toward standardizing how the XACML ecosystem exchanges documents over the Internet.
When cloud systems and web services need to talk about who's allowed to access what, they can now clearly label those documents so nothing gets confused.