1 Introduction

{Non-normative}

The XACML architecture promotes a loose coupling between the component that enforces decisions, the policy enforcement point (PEP), and the component that decides based on XACML policies, the policy decision point (PDP).

The XACML standard defines the format of the request and the response between the PEP and the PDP. As the default representation of XACML is XML and is backed by a schema, the request and response are typically expressed as XML elements or documents. Depending on the PDP implementation, the request and response could be embedded inside a SOAP message or even a SAML assertion as described in the SAML profile of XACML.

With the rise in popularity of APIs and its consumerization, it becomes important for XACML to be easily understood in order to increase the likelihood it will be adopted.

This profile aims at defining a JSON format for the XACML request and response. It also defines the transport between client (PEP) and service (PDP).

In writing this document, the authors have kept three items in mind:

Equivalence: a XACML request and response expressed in XML need not be strictly equivalent in structure to a XACML request expressed in JSON so long as the meaning remains the same and so long as the JSON and XML requests would lead to the same response (decision, obligation, and advice).
Lossless behavior: it MUST be possible to translate XACML requests and responses between XML and JSON representations in either direction at any time without semantic loss.
Transport-agnostic nature: the JSON representation MUST contain all the information the XACML request and/or response contains: this means the transport layer cannot convert XACML decisions into HTTP codes, e.g. HTTP 401 for a Deny decision.

1.1 IPR Policy

This specification is provided under the RF on Limited Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (https://www.oasis-open.org/committees/xacml/ipr.php).

1.2 Glossary

Array

An ordered sequence of zero or more JSON elements.

Element

In JSON, a value; either a JSON primitive type, an object or an array.

Member

A name/value pair in a JSON object.

Object

In JSON, an unordered collection of zero or more members.

1.3 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

1.4 Normative References

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[RFC4627] D. Crockford, The application/json Media Type for JavaScript Object Notation (JSON), http://tools.ietf.org/html/rfc4627, IETF RFC 4627, July 2006.

[XACMLMDP] XACML v3.0 Multiple Decision Profile Version 1.0. http://docs.oasis-open.org/xacml/3.0/xacml-3.0-multiple-v1-spec-en.doc

[RFC8259] T.Bray, Ed., The JavaScript Object Notation (JSON) Data Interchange Format, https://tools.ietf.org/html/rfc8259, IETF RFC 8259, December 2017.

[NAMESPACES] Bray, Tim, et.al. eds, Namespaces in XML 1.0 (Third Edition), W3C Recommendation 8 December 2009, available at http://www.w3.org/TR/2009/REC-xml-names-20091208/

[XACML30] eXtensible Access Control Markup Language (XACML) Version 3.0 Plus Errata 01. Edited by Erik Rissanen. 12 July 2018. OASIS Standard incorporating Approved Errata. http://docs.oasis-open.org/xacml/3.0/errata01/os/xacml-3.0-core-spec-errata01-os-complete.html. Latest version: http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-en.html.

[XML] Bray, Tim, et.al. eds, Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008, available at http://www.w3.org/TR/2008/REC-xml-20081126/

[XMLDatatypes] Biron, Paul et al. Eds, XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28 October 2004, available at http://www.w3.org/TR/xmlschema-2/

[XPATH] James Clark and Steve DeRose, XML Path Language (XPath), Version 1.0, W3C Recommendation 16 November 1999. Available at: http://www.w3.org/TR/xpath

[IEEE754] Institute of Electrical and Electronics Engineers, "Standard for Floating-Point Arithmetic", IEEE Standard 754, August 2008.

1.5 Non-Normative References

[XACMLREST] REST Profile of XACML v3.0 Version 1.0. Edited by Rémon Sinnema. Latest version: http://docs.oasis-open.org/xacml/xacml-rest/v1.0/xacml-rest-v1.0.doc.

[HTTP] Hypertext Transfer Protocol. June 1999. IETF RFC 2616. http://tools.ietf.org/html/rfc2616

[HTTPS] HTTP over TLS. May 2000. IETF RFC 2818. http://tools.ietf.org/html/rfc2818

[BASE64] The Base16, Base32, and Base64 Data Encodings. October 2006. IETF RFC 4648. http://tools.ietf.org/html/rfc4648

2 Vocabulary

{Non-normative}

XML introduces the notion of elements. The equivalent notion in JSON is an object. XML introduces the notion of attributes. The equivalent notion in JSON is a member.

3 Overview of the translation mechanisms

3.1 Assumed default values

To avoid bloating the JSON request and response, certain parts of a request and response have default values which can then be omitted. As an example, the default value for the data-type of an attribute value is String (http://www.w3.org/2001/XMLSchema#string).

The user should refer to the XACML 3.0 specification document [XACML30] for a normative definition of the request and response elements.

3.2 Objects

3.2.1 Member names

Unless otherwise stated, JSON member names MUST match the XACML XML element and/or attribute names exactly, including case.

The following XML elements and attributes have been renamed:

The name of the XACML XML <Attributes> element has been changed in JSON to the member name "Category". It makes more sense to call the parent element that way since it represents an instance of a category from a XACML sense.
The <AttributeValue> element in the XML representation does not have an object counterpart in the JSON representation. The information it bears in XML is moved to the parent Attribute object in the JSON representation. A "Value" member has been introduced in the Attribute object to bear the information contained in the XML <AttributeValue> element as specified in section 4. The XACML request.
The AdviceId and the ObligationId attributes of the <Advice> and the <Obligation> XML elements respectively have been renamed to "Id" in JSON.

3.2.2 Object order

The order of the objects and values in XACML does not matter. Therefore, the order of objects and values in the serialized form (JSON) does not matter.

3.2.3 Object cardinality

When in the XACML specification an XML element occurs zero or more times, the JSON equivalent is an optional member with an array for the value. The array MAY be empty and this case is semantically equivalent to the member being omitted from the containing object.

When in the XACML specification an XML element occurs one or more times, the JSON equivalent is a mandatory member with an array for the value. The array MUST have at least one element.

The class diagram in section 4.1. Class Diagram states the cardinality and relationship between kinds of objects.

3.2.4 Null values

The JSON null value is not permitted, including as an element in an array. If an optional, non-array member has no value then it MUST be omitted from the containing object. A mandatory, non-array member MUST have a non-null value.

3.3 Data Types

This section defines how data-types are represented and handled in the JSON representation. Chapter 10, section 10.2.7 in the XACML 3.0 specification as well as section A.2 list the data-types that are defined in XACML. These are listed in the table below in section 3.3.1. It lists the shorthand value that MAY be used when creating a XACML attribute in the JSON representation.

3.3.1 Supported Data Types

The full XACML data type URI can also be used in JSON as the JSON shorthand type codes are a convenience, not a replacement.

It is also possible to omit the JSON "DataType" member for certain XACML data types when it can safely be inferred from the value of the attribute as shown in Table 1.

Table 1. JSON shorthand and rules of inference for XACML data types.

XACML data type identifier	JSON shorthand type code	Mapping / Inference Rule
http://www.w3.org/2001/XMLSchema#string	string	JSON string
http://www.w3.org/2001/XMLSchema#boolean	boolean	JSON boolean
http://www.w3.org/2001/XMLSchema#integer	integer	JSON number with no fractional portion and within the integer range defined by the XML schema in [XMLDatatypes].
http://www.w3.org/2001/XMLSchema#double	double	JSON number with fractional portion or out of integer range as defined in [XMLDatatypes].
http://www.w3.org/2001/XMLSchema#time	time	None – inference must fail.
http://www.w3.org/2001/XMLSchema#date	date	None – inference must fail.
http://www.w3.org/2001/XMLSchema#dateTime	dateTime	None – inference must fail.
http://www.w3.org/2001/XMLSchema#dayTimeDuration	dayTimeDuration	None – inference must fail.
http://www.w3.org/2001/XMLSchema#yearMonthDuration	yearMonthDuration	None – inference must fail.
http://www.w3.org/2001/XMLSchema#anyURI	anyURI	None – inference must fail.
http://www.w3.org/2001/XMLSchema#hexBinary	hexBinary	None – inference must fail.
http://www.w3.org/2001/XMLSchema#base64Binary	base64Binary	None – inference must fail.
urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name	rfc822Name	None – inference must fail.
urn:oasis:names:tc:xacml:1.0:data-type:x500Name	x500Name	None – inference must fail.
urn:oasis:names:tc:xacml:2.0:data-type:ipAddress	ipAddress	None – inference must fail.
urn:oasis:names:tc:xacml:2.0:data-type:dnsName	dnsName	None – inference must fail.
urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression	xpathExpression	None – inference must fail

For all of the XACML data types that cannot be inferred from the value, the following MUST be observed:

The JSON "DataType" member MUST be specified and the attribute value expressed in the XACML string representation of the value.
Implementation-specific (e.g. Javascript) code may choose to parse the XACML string values into internal numeric representations for internal use, such as for dateTime or duration (dayTimeDuration, yearMonthDuration) values, but the JSON transport representation must always express the attribute value in the serialized XACML string representation of the XACML data type.

3.3.2 Multiple values

In the case of an array of two or more values, and if the "DataType" member is not specified, it may not be possible to infer the "DataType" until all the values have been inspected.

Inference for multiple values works according to the inference rules as set in section 3.3.1. If a given data type cannot be inferred and there is no "DataType" member specified then the array of values will be considered as an array of string.

If an array of values contains integers and doubles only (excluding non-numerical values), then the inference will make the array an array of double.

Any other combination of values will make the inference fail and the array will be considered as an array of string.

3.3.3 The xpathExpression Datatype

Values of the xpathExpression data-type are represented as JSON objects. Each such object contains the following members:

Table 2 - Members of the xPathExpression Datatype

Member name	Type	Mandatory/Optional	Default value
"XPathCategory"	A string containing a URI or the shorthand notation defined in section 4.2.2.1	Mandatory	None
"Namespaces"	An *array* of NamespaceDeclaration *objects*	Optional	None
"XPath"	String	Mandatory	None

The "XPath" member contains the XPath expression [XPATH] from the XACML value. The "Namespaces" member contains namespace declarations for interpreting qualified names [NAMESPACES] in the XPath expression.

A NamespaceDeclaration object contains the following members:

Table 3 - Members of the NamespaceDeclaration Datatype

Member name	Type	Mandatory/Optional	Default value
"Prefix"	String	Optional	None
"Namespace"	A string containing a URI	Mandatory	None

Each NamespaceDeclaration object describes a single XML namespace declaration [NAMESPACES]. The "Prefix" member contains the namespace prefix and the "Namespace" member contains the namespace name. In the case of a namespace declaration for the default namespace the "Prefix" member SHALL be absent.

The "Namespaces" array MUST contain a NamespaceDeclaration object for each of the namespace prefixes used by the XPath expression. The "Namespaces" array MAY contain additional NamespaceDeclaration objects for namespace prefixes that are not used by the XPath expression. There SHALL NOT be more than one NamespaceDeclaration object for the same namespace prefix.

3.3.3.1 Example

{Non-normative}

This example shows the XML representation of an XACML attribute with a value of the xpathExpression data-type and its corresponding representation in JSON.

As XML:

<Attribute xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
AttributeId="urn:oasis:names:tc:xacml:3.0:content-selector">
<AttributeValue xmlns:md="urn:example:med:schemas:record"
   XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
   DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"
    >md:record/md:patient/md:patientDoB</AttributeValue>
</Attribute>

As JSON:

{

   "Attribute":{
      "AttributeId":"urn:oasis:names:tc:xacml:3.0:content-selector",
      "DataType":"xpathExpression",
      "Value":{
         "XPathCategory":

           "urn:oasis:names:tc:xacml:3.0:attribute-category:resource",
         "Namespaces":[{
           "Namespace": "urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
         },{
           "Prefix":"md",
           "Namespace":"urn:example:med:schemas:record"
         }],
         "XPath":"md:record/md:patient/md:patientDoB"
      }

}

3.3.4 Special numeric values

The following special numeric values are not supported by the profile. Should the request contain such values, the Policy Decision Point MUST reply with an Indeterminate result and a status value of urn:oasis:names:tc:xacml:1.0:status:syntax-error as defined in Appendix B, section 8 of [XACML30].

Additional behavior of the PDP when returning urn:oasis:names:tc:xacml:1.0:status:syntax-error is specified in sections 5.57 and B.8 of [XACML30].

IEEE 754-2008 NaN ("NaN")
IEEE 754-2008 positive infinity ("INF")
IEEE 754-2008 negative infinity ("-INF")
IEEE 754-2008 negative zero (-0)

3.4 Example

{Non-normative}

The example below illustrates equivalent possible notations:

Table 4 - Equivalent examples

Representation explicitly stating the data-type

Representation omitting the data-type

{

"Attribute":[{

"AttributeId":"document-id"

      "DataType":"integer"
      "Value" : 123
   }]

}

{

"Attribute":[{

      "AttributeId":"document-id"
      "Value":123
   }]

}

4 The XACML request

4.1 Class Diagram

The following class diagram represents the XACML request structure for the JSON representation. It is not a representation of the XACML request as expressed in XML.

The key differences are:

The <AttributeValue> element in the XML representation does not have a counterpart in the JSON representation. The information it bears in XML is moved to the parent Attribute object in the JSON representation.
There are 4 new objects for attributes belonging to the most commonly used categories.

XACML_3

4.2 Representation of the XACML request in JSON

An XACML request is represented as an object with a single member named "Request". The value of the "Request" member is a Request object.

4.2.1 The Request object representation

The Request object contains the following members:

Table 5 - Members of the Request object

Member name	Type	Mandatory/Optional	Default value
"ReturnPolicyIdList"	Boolean	Optional	false
"CombinedDecision"	Boolean	Optional	false
"XPathVersion"	String	Mandatory if the XACML request contains XPath expressions; otherwise, optional.	None
"Category"	An *array* of Category *objects*	Optional, but see section 4.2.2.2.	None
"Resource"	An *array* of Category *objects*	Optional, but see section 4.2.2.2.	None
"Action"	An *array* of Category *objects*	Optional, but see section 4.2.2.2.	None
"Environment"	An *array* of Category *objects*	Optional, but see section 4.2.2.2.	None
"AccessSubject"	An *array* of Category *objects*	Optional, but see section 4.2.2.2.	None
"RecipientSubject"	An *array* of Category *objects*	Optional, but see section 4.2.2.2.	None
"IntermediarySubject"	An *array* of Category *objects*	Optional, but see section 4.2.2.2.	None
"CodeBase"	An *array* of Category *objects*	Optional, but see section 4.2.2.2.	None
"RequestingMachine"	An *array* of Category *objects*	Optional, but see section 4.2.2.2.	None
"MultiRequests"	A MultiRequests *object*	Optional	None

The Category object corresponds to the XML <Attributes> element. Just like the <Attributes> element is specific to a given XACML attribute category, the Category object in JSON is specific to a given XACML attribute category.

The MultiRequests object serves to support the Multiple Decision Profile [XACMLMDP].

The representation of these objects is elicited in the following relevant sections.

Note that, in the XACML XML schema, the XML Request element contains a <RequestDefaults> element. To simplify things and since the <RequestDefaults> element contains a single <XPathVersion> element with a single value, the <RequestDefaults> element was flattened into a single member called "XPathVersion" as mentioned in the above table.

4.2.1.1 Example

{Non-normative}

{

"Request":{

"Category":[…],

"XPathVersion":"http://www.w3.org/TR/1999/REC-xpath-19991116"

}

4.2.2 The Category object representation

The Category object contains the following members:

Table 6 - Members of the Category object

Member name	Type	Mandatory/Optional	Default value
"CategoryId"	A string containing a XACML category URI or the shorthand notation defined in section 4.2.2.1	Mandatory for a Category *object* in the "Category" *member* *array*; otherwise, optional. See section 4.2.2.2.	None
"Id"	String	Optional	None
"Content"	String. The value must be escaped or encoded as explained in section 4.2.3.	Optional	None
"Attribute"	An *array* of Attribute *objects*	Optional	None

The Attribute object is defined in section 4.2.4, The Attribute object representation.

The Category object is the equivalent of the <Attributes> element in the XACML XML representation.

The structure and default values for the aforementioned are elicited in the following relevant sections.

4.2.2.1 Shorthand notation for standard XACML categories

The following table defines a shorthand notation for the standard categories defined in [XACML30].

Table 7 - Shorthand notation for standard XACML categories

Identifier	Short name
urn:oasis:names:tc:xacml:3.0:attribute-category:resource	Resource
urn:oasis:names:tc:xacml:3.0:attribute-category:action	Action
urn:oasis:names:tc:xacml:3.0:attribute-category:environment	Environment
urn:oasis:names:tc:xacml:1.0:subject-category:access-subject	AccessSubject
urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject	RecipientSubject
urn:oasis:names:tc:xacml:1.0:subject-category:intermediary-subject	IntermediarySubject
urn:oasis:names:tc:xacml:1.0:subject-category:codebase	Codebase
urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine	RequestingMachine

The shorthand notation MAY be used as described in sections 4.2.2.2 and 4.2.2.

4.2.2.2 Default Category objects

Category objects in the "Category" member array relate to various XACML attribute categories as indicated by their individual "CategoryId" member, which is a mandatory member only for these Category objects. To simplify the JSON representation, this profile also defines other members (of the Request object) with an array of Category objects for the value where the member names correspond to the short names defined in section 4.2.2.1. The Category objects in these arrays assume a default value for their "CategoryId" member, i.e., the short name of the containing member, so that it need not be explicitly written. The "CategoryId" member is optional for these Category objects, but if it is provided the value MUST be the same as the short name of the containing member.

The members with the short names have array values in order to cater for multiple decision requests as defined in [XACMLMDP].

The Request object MUST contain at least one Category object in one of its members.

4.2.2.3 Example

{Non-normative}

{

"Request":{

"Category":[{

"CategoryId":"custom-category",

"Attribute":[…]

},{

"CategoryId":"another-custom-cat",

"Attribute":[…]

}],

"AccessSubject":[{

"Attribute":[…]

}],

"Action":[{

"Attribute":[…]

},{

"Attribute":[…]

}]

}
}

4.2.3 The Content object representation

There are two possible ways to represent the XML content of a XACML request in the JSON representation: XML escaping or Base64 encoding. The request parser must determine whether XML escaping or Base 64 encoding is used. There are no members in the JSON request to indicate which is used.

In both cases, any XML content sent in a JSON request MUST include all namespace definitions needed to parse that content.

4.2.3.1 XML Escaping

The value of the "Content" member is a string which MUST contain an XML payload per the XACML specification.

XML content must be escaped before being inserted into the JSON request. JSON dictates double quotes (") be escaped using a backslash (\). This profile therefore follows this behavior.

In addition, since the XML content could itself contain backslashes and possibly the sequence \", it is important to also escape backslashes.

4.2.3.2 Base64 Encoding

In the case of Base64 encoding, the XML content shall be converted to its Base64 representation as per [BASE64].

4.2.3.3 Example

{Non-normative}

The following is an example using XML escaping as defined in 4.2.3.1.

{

"Request":{

"AccessSubject":[{

"Content": "<?xml version=\"1.0\"?><catalog><book id=\"bk101\"><author>Gambardella, Matthew</author><title>XML Developer's Guide</title><genre>Computer</genre><price>44.95</price><publish_date>2000-10-01</publish_date><description>An in-depth look at creating applications with XML.</description></book></catalog>"

}]

}

The following is an example using Base64 encoding as defined in 4.2.3.2.

{

"Request":{

"AccessSubject":[{

"Content": "PD94bWwgdmVyc2lvbj0iMS4wIj8+DQo8Y2F0YWxvZz48Ym9vayBpZD0iYmsxMDEiPjxhdXRob3I+R2FtYmFyZGVsbGEsIE1hdHRoZXc8L2F1dGhvcj48dGl0bGU+WE1MIERldmVsb3BlcidzIEd1aWRlPC90aXRsZT48Z2VucmU+Q29tcHV0ZXI8L2dlbnJlPjxwcmljZT40NC45NTwvcHJpY2U+PHB1Ymxpc2hfZGF0ZT4yMDAwLTEwLTAxPC9wdWJsaXNoX2RhdGU+PGRlc2NyaXB0aW9uPkFuIGluLWRlcHRoIGxvb2sgYXQgY3JlYXRpbmcgYXBwbGljYXRpb25zIHdpdGggWE1MLjwvZGVzY3JpcHRpb24+PC9ib29rPjwvY2F0YWxvZz4="

}]

}

4.2.4 The Attribute object representation

The Attribute object contains the following members:

Table 8 - Members of the Attribute Object

Member name	Type	Mandatory/ Optional	Default value
"AttributeId"	A string containing a XACML attribute URI	Mandatory	None
"Value"	An *array* of *elements* of the same type; either string, boolean, number (which maps to either a XACML integer or double as defined in Supported Data Types) or *object*.	Mandatory	None
"Issuer"	String	Optional	None
"DataType"	A string containing a XACML data type URI or the shorthand notation defined in section 3.3.1	Optional	The default value will be http://www.w3.org/2001/XMLSchema#string unless the data type can be safely assumed to be otherwise according to the rules set in sections 3.3.1 and 3.3.2.
"IncludeInResult"	Boolean	Optional	false

4.2.4.1 Example

{Non-normative}

{

"Attribute":[{

"AttributeId":"urn:oasis:names:tc:xacml:2.0:subject:role",

"Value":["manager","administrator"]

}]

}

4.2.5 The MultiRequests object representation

The MultiRequests object is optional in the JSON representation of XACML. Its purpose is to support the Multiple Decision Profile [XACMLMDP]. The MultiRequests object contains the following members:

Table 9 - Members of the MultiRequests object

Member name	Type	Mandatory/Optional	Default value
"RequestReference"	An *array* of one or more RequestReference *objects*	Mandatory	None

4.2.6 The RequestReference object representation

The RequestReference object contains the following members:

Table 10 - Members of the RequestReference object

Member name	Type	Mandatory/Optional	Default value
"ReferenceId"	An *array* of one or more strings. Each string MUST be the value of a Category *object’s* "Id" *member*.	Mandatory	None

4.2.6.1 Non-normative example

{

"MultiRequests":{

"RequestReference":[{

"ReferenceId":["foo1","bar1"]
},{

"ReferenceId":["foo2","bar1"]

},{

"ReferenceId":["foo3","bar1"]

}]

}

5 The XACML response

5.1 Class Diagram

5.2 Representation of the XACML response in JSON

An XACML response is represented as an object with a single, mandatory member named "Response". The value of the "Response" member is an array of one or more Result objects. There is no Response object as such. Instead it is replaced by the value of what would otherwise be its only member, an array of Result objects. This eliminates the nesting of <Result> elements in the <Response> element introduced in XACML’s XML schema.

The Result object representation is detailed hereafter.

5.2.1 The Result object representation

The Result object contains the following members:

Table 11 - Members of the Result object

Member name	Type	Mandatory/Optional	Default value
"Decision"	String. There are only 4 valid values: "Permit", "Deny", "NotApplicable", and "Indeterminate". The values are case-sensitive.	Mandatory	None
"Status"	A Status *object*	Optional	None
"Obligations"	An *array* of ObligationOrAdvice *objects*	Optional	None
"AssociatedAdvice"	An *array* of ObligationOrAdvice *objects*	Optional	None
"Category"	An *array* of Category *objects*	Optional	None
"PolicyIdentifierList"	A PolicyIdentifierList *object*	Optional	None

The JSON representation of the <Attributes> element in a XACML response is identical to the representation defined in section 4.2.2 The Category object representation.

5.2.2 The Status object representation

The Status object contains the following members:

Table 12 - Members of the Status object

Member name	Type	Mandatory/Optional	Default value
"StatusMessage"	String	Optional	None
"StatusDetail"	An *array* of JSON values	Optional	None
"StatusCode"	A StatusCode *object*	Optional	None

The StatusDetail array MAY contain arbitrary XML within strings, in which case the XML content must be escaped using the same technique as specified in section 4.2.3, The Content object representation.

The StatusDetail array MAY contain MissingAttributeDetail objects.

5.2.3 The MissingAttributeDetail object

The MissingAttributeDetail object in JSON contains the following members:

Table 13 - Members of the MissingAttributeDetail object

Member name	Type	Mandatory / Optional	Default value
"AttributeId"	A string containing a XACML attribute URI	Mandatory	None
"Value"	An *array* of *elements* of the same type; either string, boolean, number (which maps to either a XACML integer or double as defined in Supported Data Types) or *object*.	Optional	None
"Issuer"	String	Optional	None
"DataType"	A string containing a XACML data type URI or the shorthand notation defined in section 3.3.1	Optional	The default value will be http://www.w3.org/2001/XMLSchema#string unless the data type can be safely assumed to be otherwise according to the rules set in sections 3.3.1 and 3.3.2.
"Category"	A string containing a XACML category URI or the shorthand notation defined in section 4.2.2.1	Mandatory	None

5.2.4 The StatusCode object representation

The StatusCode object in JSON contains the following members:

Table 14 - Members of the StatusCode object

Member name	Type	Mandatory/Optional	Default value
"Value"	A string containing a XACML status code URI	Optional	"urn:oasis:names:tc:xacml:1.0:status:ok"
"StatusCode"	A StatusCode *object*	Optional	None

Note that the StatusCode object may contain a "StatusCode" member – hence potentially creating a recursive nesting of StatusCode objects.

5.2.4.1 Example

{Non-normative}

{
"Response":[{
"Decision": "Permit"

"Status":{

"StatusCode":{

"Value": "http://example.com"

}

}]
}

5.2.5 The ObligationOrAdvice object representation

The ObligationOrAdvice object contains the following members:

Table 15 - Members of the ObligationOrAdvice object

Member name	Type	Mandatory/Optional	Default value
"Id"	A string containing a XACML obligation or advice URI	Mandatory	None
"AttributeAssignment"	An *array* of AttributeAssignment *objects*	Optional	None

Note that the ObligationOrAdvice object maps to either an <Advice> or an <Obligation> element in the XACML XML representation. While in the XML representation, each element has an attribute called AdviceId or ObligationId respectively, in the JSON representation, the naming has been harmonized to "Id".

5.2.6 The AttributeAssignment object representation

The AttributeAssignment object contains the following members:

Table 16 - Members of the AttributeAssignment object

Member name	Type	Mandatory/Optional	Default value
"AttributeId"	A string containing a XACML attribute URI	Mandatory	None
"Value"	Variable	Mandatory	None
"Category"	A string containing a XACML category URI or the shorthand notation defined in section 4.2.2.1	Optional	None
"DataType"	A string containing a XACML data type URI or the shorthand notation defined in section 3.3.1	Optional	The default value depends on the inference rules defined in Supported Data Types.
"Issuer"	String	Optional	None

5.2.7 The PolicyIdentifierList object representation

The PolicyIdentifierList object contains the following members:

Table 17 - Members of the PolicyIdentifierList object

Member name	Type	Mandatory/Optional	Default value
"PolicyIdReference"	An *array* of IdReference *objects*	Optional	None
"PolicySetIdReference"	An *array* of IdReference *objects*	Optional	None

5.2.8 The IdReference object representation

The IdReference object representation contains the following members:

Table 18 - Members of the IdReference object

Member name

Type

Mandatory/Optional

Default value

"Id"

A string containing a XACML policy or policy set URI.

Represents the value stored inside the XACML XML <PolicyIdReference> or <PolicySetIdReference> element.

Mandatory

None

"Version"

String

Optional

None

6 Transport

The XACML request represented in its JSON format MAY be carried from a PEP to a PDP via an HTTP [HTTP] request as defined in the REST profile of XACML [XACMLREST].

HTTP Headers which may be used are:

Content-Type: application/xacml+json
Accept: application/xacml+json

6.1 Transport Security

{Non-normative}

The use of SSL/TLS [HTTPS] is RECOMMENDED to protect requests and responses as they are transferred across the network.

7 IANA Registration

The following section defines the information required by IANA when applying for a new media type.

7.1 Media Type Name

application

7.2 Subtype Name

xacml+json

7.3 Required Parameters

None.

7.4 Optional Parameters

version: The version parameter indicates the version of the XACML specification. Its range is the range of published XACML versions. As of this writing that is: 1.0, 1.1, 2.0, and 3.0. These and future version identifiers are of the form x.y, where x and y are decimal numbers with no leading zeros, with x being positive and y being non-negative.

7.5 Encoding Considerations

Same as for application/xml [RFC4627].

7.6 Security Considerations

Per their specification, application/xacml+json typed objects do not contain executable content.

XACML requests and responses contain information for which integrity and authenticity are important.

To counter potential issues, the publisher may use the transport layer’s security mechanisms to secure

xacml+json typed objects when they are in transit. For instance HTTPS, offers means to ensure the confidentiality and authenticity of the publishing party and the protection of the request/response in transit.

7.7 Interoperability Considerations

XACML 3.0 uses the urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 XML namespace URI. XACML 2.0 uses the urn:oasis:names:tc:xacml:2.0:policy XML namespace URI.

7.8 Applications which use this media type

Potentially any application implementing XACML, as well as those applications implementing specifications based on XACML or those applications requesting an authorization decision from a XACML implementation.

7.9 Magic number(s)

Per [RFC4627], this section is not applicable.

7.10 File extension(s)

Per [RFC4627], .json.

7.11 Macintosh File Type Code(s)

Text

7.12 Intended Usage

Common

8 Examples

{Non-normative}

8.1 Request Example

{Non-normative}

The following is a sample XACML request expressed in JSON.

{

"Request":{

"AccessSubject":[{

"Attribute":[{

"AttributeId":"subject-id",

"Value":"Andreas"

},{

"AttributeId":"location",

"Value":"Gamla Stan"

}]

}],

"Action":[{

"Attribute":[{

"AttributeId":"action-id",

"Value":"http://example.com/buy",

"DataType":"anyURI"

}]

}],

"Resource":[{

"Attribute":[{

"AttributeId":"book-title",

"Value":"Learn German in 90 days"

},{

"AttributeId":"currency",

"Value": "SEK"

},{

"AttributeId":"price",

"Value": 123.34

}]

}

8.2 Response Example

{Non-normative}

The following is a sample XACML response expressed in JSON.

{

"Response":[{

"Decision":"Permit"

}]

}

8.3 Request for Multiple Decisions Example

{Non-normative}

The following is a sample XACML request for multiple decisions expressed in JSON.

{

"Request":{

"AccessSubject":[{

"Id":"s1",

"Attribute":[{

"AttributeId":"com.acme.user.employeeId",

"Value":"Alice"

}]

}],

"Resource":[{

"Id":"r1",

"Attribute":[{

"AttributeId":"com.acme.object.objectType",

"Value":"record"

},{

"AttributeId":"com.acme.record.recordId",

"Value":"126",

"IncludeInResult":true

}]

},{

"Id":"r2",

"Attribute":[{

"AttributeId":"com.acme.object.objectType",

"Value":"record"

},{

"AttributeId":"com.acme.record.recordId",

"Value":"125",

"IncludeInResult":true

}]

}],

"Action":[{

"Id":"a1",

"Attribute":[{

"AttributeId":"com.acme.action.actionId",

"Value":"view",

"IncludeInResult":true

}]

},{

"Id":"a2",

"Attribute":[{

"AttributeId":"com.acme.action.actionId",

"Value":"edit",

"IncludeInResult":true

}]

},{

"Id":"a3",

"Attribute":[{

"AttributeId":"com.acme.action.actionId",

"Value":"delete",

"IncludeInResult":true

}]

}],

"MultiRequests":{

"RequestReference":[{

"ReferenceId":[

"s1",

"a1",

"r1"

]

},{

"ReferenceId":[

"s1",

"a2",

"r1"

]

}]

}

8.4 Multiple Decisions Response Example

{Non-normative}

The following is a sample XACML response to a request for multiple decisions expressed in JSON.

{

"Response":[{

"Decision":"Deny",

"Status":{

"StatusCode":{

"Value":"urn:oasis:names:tc:xacml:1.0:status:ok",

"StatusCode":{

"Value":"urn:oasis:names:tc:xacml:1.0:status:ok"

}

"Category":[{

"CategoryId":

"urn:oasis:names:tc:xacml:3.0:attribute-category:resource",

"Attribute":[{

"AttributeId":"com.acme.record.recordId",

"Value":"126",

"DataType":"http://www.w3.org/2001/XMLSchema#string"

}]

},{

"CategoryId":

"urn:oasis:names:tc:xacml:3.0:attribute-category:action",

"Attribute":[{

"AttributeId":"com.acme.action.actionId",

"Value":"view",

"DataType":"http://www.w3.org/2001/XMLSchema#string"

}]

},{

"Decision":"Deny",

"Status":{

"StatusCode":{

"Value":"urn:oasis:names:tc:xacml:1.0:status:ok",

"StatusCode":{

"Value":"urn:oasis:names:tc:xacml:1.0:status:ok"

}

"Category":[{

"CategoryId":

"urn:oasis:names:tc:xacml:3.0:attribute-category:resource",

"Attribute":[{

"AttributeId":"com.acme.record.recordId",

"Value":"126",

"DataType":"http://www.w3.org/2001/XMLSchema#string"

}]

},{

"CategoryId":

"urn:oasis:names:tc:xacml:3.0:attribute-category:action",

"Attribute":[{

"AttributeId":"com.acme.action.actionId",

"Value":"edit",

"DataType":"http://www.w3.org/2001/XMLSchema#string"

}]

}

9 Conformance

An implementation may conform to this profile if and only if both the XACML request and the response are correctly encoded into JSON as previously described in sections 3 through 5 and follows the transport requirements as specified in section 6.

Appendix A. Acknowledgements

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

Participants:

· Cyril Dangerville, Thales Group

· Rich Levinson, Oracle

· Hal Lockhart, Oracle

· Bill Parducci,

· Erik Rissanen, Axiomatics

· Anil Saldhana, Red Hat

· Remon Sinnema, EMC

· Danny Thorpe, Dell

· Paul Tyson, Bell Helicopters

Appendix B. Revision History

Revision	Date	Editor	Changes Made
WD 01	2 Jul 2012	David Brossard	Initial working draft
WD 02	9 Jul 2012	David Brossard	Integrated comments from XACML list. Enhanced the section on data-types. Added a class diagram for clarity. Changed tense to present. Removed overly explicit comparisons with XML representation.
WD 03	19 Jul 2012	David Brossard	Started work on the XACML response
WD 04	20 Aug 2012	David Brossard	Finalized work on the XACML response, added a note on HTTPS. Restructured the document to extract paragraphs common to the Request and Response section.
WD 05	20 Sep 2012	David Brossard	Took in comments from the XACML TC list (technical comments and typographical corrections)
WD 06	29 Oct 2012	David Brossard	Removed the Non-normative section in the appendix. Completed the conformance section. Added non-normative tags where needed. Also added a sample response example. Added the section on IANA registration.
WD07	15 Nov 2012	David Brossard	Removed the XPathExpression from the supported DataTypes. Fixed the examples as per Steven Legg’s email. Fixed the XML encoding of XML content as per conversations on the XACML TC list.
WD08	27 Nov 2012	David Brossard	Fixed the Base64 encoding section as per Erik Rissanen’s comments
WD09	24 Dec 2012	David Brossard	Addressed comments and fixed errors as per emails sent on the XACML TC list in December.
WD10	4 Feb 2013	David Brossard	Fixed the IANA registration section. Fixed inconsistent DataType spelling. DataType is always the XACML attribute and JSON property name. Data type refers to the English notion. Fixed the status XML content encoding to be consistent with the Request XML encoding technique. Fixed a non-normative section label. Fixed the formatting of JSON property names. Fixed the XACML to JSON data type inference by adding references to the relevant XML data types.
WD11	5 Feb 2013	David Brossard	Fixed the AttributeAssignment section
WD12	10 May 2013	David Brossard	Reinserted a section on the xpathExpression data type. Fixed the PolicyIdReference section (missing value). Fixed the Response example. Simplified the XPathVersion / RequestDefaults Removed unnecessary nesting in Response / Result Renamed Attributes to Category
WD13	14 June 2013	David Brossard	Fixed the final issue re. Category vs. Attributes.
WD14	12 July 2013	David Brossard	Cleaned up the documents and comments.
WD15	02 September 2013	David Brossard	Fixed document based on feedback from Steven Legg: The naming of Attributes vs. Category in section 5.2.2 Fixed the name of ObligationOrAdvice in section 5.2.6 Also fixed subjective line in introduction based on email xacml-comment from David Webber.
WD16	17 March 2014	David Brossard	Fixed issues with special numerical values: based on input from the XACML TC, special values (NaN, Inf, -0) are now excluded Rewrote section 3.4.2 and added reference to 3.4.1 Added a section defining the shorthand notation for standard XACML categories Added normative reference to XACML 3.0 standard Added optional category objects for all default categories in XACML 3.0 instead of the 4 most common ones only. Updated example in 4.2.4.1 Fixed the Transport section to reference the REST profile. Fixed broken samples Added references to IEEE 754-2008 rather than Javascript for the special numerical values Fixed the Content section to include the namespaces requirement Fixed the default value for XPathVersion to be in accordance with [XACML30]. Added the MissingAttributeValue object definition.
WD17	14 April 2014	David Brossard	Updated the profile title per conversation on the XACML TC list Updated section 3.2.1 on object names in JSON Fixed broken reference to 3.3.1 in 3.3.2 Updated the inference rule for double and integers to remove any doubt as to the potential datatypes Fixed wording in section 4.2.1 (much like vs. just like) Simplified the wording of section 4.2.2.2 Updated the example in section 4.2.2.3 Changed the shorthand name subject to access-subject to be consistent Added the Indeterminate behavior for invalid numerical values Fixed the base 64 encoding example in section 4.2.3.3. Fixed the examples (wrong attribute names, missing parents, missing curly braces) Changed the MS Word quotes into proper quotes
WD18	22 April 2014	David Brossard	Changed the shorthand names to use Title Case instead. resource becomes Resource, access-subject becomes AccessSubject, and so on. Updated the XPathCategory so that one can use the category shorthand notation as a valid value instead.
WD19	23 October 2014	David Brossard	Introduced formatting changes based on feedback received on xacml-comment Fixed section 6 content-type and accept Fixed the wording on StatusCode Added captions to tables
WD20	26 April 2018	Hal Lockhart	Merge in changes to references previously inserted in COS1 Correct Typos noted in Public Review Add Cyril Dangerville to Acknowledgements
WD21	24 May 2018	Steven Legg	Updated the XACML 3.0 reference. Changed JSON reference to RFC 8259. Dropped the reference to ECMA 262. Added a glossary for JSON syntax and used the terminology from RFC 8259 throughout the profile. Moved all the prose descriptions of object and array members into the tables. Removed all the choices between a single object and an array of objects. Now only arrays are allowed. Updated the examples to reflect the change. Removed null as an allowed value for the Content member. Disallowed the use of null anywhere. Clarified that empty arrays are allowed.
WD22	18 July 2018		Added Steven Legg as an editor. Changed the "Response" member to be mandatory. Added an example request and response for a request for multiple decisions. Fixed the cross-references. Reformatted the examples. Made numerous formatting corrections.
WD23	15 August 2018		Imported the class diagrams in Enhanced MetaFile format (a vector art format) to improve the document display in HTML. Removed hyperlinks and used consistent font size in JSON examples.