RFC 7061

eXtensible Access Control Markup Language (XACML) XML Media Type

📅 published November 2013, from ietf

eXtensible Access Control Markup Language (XACML) XML Media Type 🎀

RFC 7061, an Independent Submission, by R. Sinnema and E. Wilde (both at EMC Corporation). 🦋

  • Category: Informational 🌸
  • ISSN: 2070-1721
  • Date: November 2013 📅
  • Obsoletes / Updates: this title block doesn't list any RFC as obsoleted or updated, so none are named here 🙈

Abstract ✨

Okay so this spec registers an XML-based media type for the eXtensible Access Control Markup Language (XACML). Basically it gives XACML documents an official name so everyone knows what they are 💅

Status of This Memo 💜

This doc is NOT an Internet Standards Track spec. It's published just for information, bestie 🧚

It's a contribution to the RFC Series, done independently of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about how useful it is for implementing or deploying. Docs the RFC Editor approves for publication aren't candidates for any level of Internet Standard, see Section 2 of RFC 5741 💀

If you want the current status, any errata, or a way to give feedback, check http://www.rfc-editor.org/info/rfc7061 ✨

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 📜

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 🦋

So XACML [XACML-3] is the big deal here. It defines an architecture and a language for access control (authorization) 🔐 The language is made of requests, responses, and policies.

The way it works: clients send a request to a server to ask whether a given action should be allowed. The server checks the request against the policies it has and sends back a response. The policies are how an organization writes down its access control requirements, and it's giving very organized energy 👑

2. IANA Considerations 📋

This spec details the registry for an XML-based media type for XACML, registered with the Internet Assigned Numbers Authority (IANA) under the "Media Type Specifications and Registration Procedures" [RFC6838]. The XACML media type represents an XACML request, response, or policy in the XML-based format from the core XACML spec [XACML-3] ✨

2.1. XACML Media Type application/xacml+xml 💖

This section registers the XML-based media type for XACML. Here's the full registration, bestie 🫶

Media Type Name: application

Subtype Name: xacml+xml

Required Parameters: none

Optional Parameters:

  • charset: This one works the same as the charset parameter of application/xml [RFC3023], including the same default (see Section 3.2 of RFC 3023) 🌸
  • version: This tells you which version of the XACML spec is in use. It can be used for content negotiation when clients and servers support more than one XACML version 🧚 Its range is the range of published XACML versions. As of writing, that's 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 the client doesn't specify this parameter, the server is free to return any version it deems fit 🤷‍♀️ If a client can't or doesn't want to deal with that, it should explicitly specify a version 💅

Encoding Considerations: Same as for application/xml [RFC3023] ✨

Security Considerations:

Per their spec, objects of type application/xacml+xml don't contain executable content 🙌 BUT they're XML-based, so they have all the general security considerations in Section 10 of RFC 3023 [RFC3023] 🚨

XACML [XACML-3] contains information whose integrity and authenticity really matter, like identity provider and service provider public keys and endpoint addresses. Sections 9.2.1 "Authentication" and 9.2.4 "Policy Integrity" in XACML [XACML-3] describe the requirements and considerations for authentication and integrity protection. Read them. Seriously 😭

To counter potential issues, the publisher may sign objects of type application/xacml+xml. Any such signature should be verified by the recipient of the data, both as a valid signature and as the signature of the publisher 🔥 The XACML v3.0 XML Digital Signature Profile [XACML-3-DSig] explains how to use XML-based digital signatures with XACML 🦋

Also, various publication protocols, like HTTPS, offer ways to make sure the publishing party is authentic and to protect the policy in transit 🔒

Interoperability Considerations: Different XACML versions use different XML namespace URIs, so check which one you've got 👀

  • 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 that implements or uses XACML, plus any apps that implement or use specs based on XACML. Apps using the Representational State Transfer (REST) Profile [XACML-REST] can especially 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 matching namespace URIs for each XACML version like this:

  • 1.0 and 1.1: The xacml prefix maps to urn:oasis:names:tc:xacml:1.0:policy, and 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, and 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). For current info on committee chairpersons and their contact addresses, check the XACMLTC website at http://www.oasis-open.org/committees/xacml/ 🌷 Committee members should send comments and potential errors to the xacml@lists.oasis-open.org list. Everyone else should submit them through the web form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=xacml 💌

There's also the XACML developer community mailing list, xacml-dev@lists.oasis-open.org, where you can talk about how to use the application/xacml+xml MIME media type 💬 It's publicly archived at http://www.oasis-open.org/archives/xacml-dev/. To post, you have to subscribe first, and you can do that on 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 spec are described in Section 2.1 of the media type registration. Go check them out, bestie 💖

4. Normative References ✨

okay so this is the list of everything the spec leans on, bestie 📚 if you want the full story, go read these. the tags in brackets are how the rest of the doc points at them 🔖

Appendix A. Acknowledgements 🙏

the people who helped build this spec and deserve all the flowers 💐 huge thanks to Oscar Koeroo (Nikhef), Erik Rissanen (Axiomatics), and Jonathan Robie (EMC) ✨ literal legends

Authors' Addresses 💌

the humans behind the doc, in case you want to slide into their inbox 📬

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/
📦 where this page comes from