COMPARISON
AuthZEN vs XACML
AuthZEN focuses on interoperable JSON authorization decision exchange across PDP/PEP/PIP/PAP components; XACML defines an XML policy language and request/response model. EmpowerNow includes product‑level extension fields like constraints, obligations, and TTL in decisions for practical enforcement — these are not part of the current AuthZEN specification.
| Dimension | XACML | AuthZEN |
|---|---|---|
| Primary scope | Policy language + XML request/response | Decision transport + interop between auth components |
| Message format | XML | JSON |
| Decision payload | Permit/Deny (+ obligations/advice) | Permit/Deny (EmpowerNow adds extensions: constraints/obligations/TTL) |
| Policy authoring | XACML policy, combining algorithms | Out of scope (WG focuses on interop; various PAPs) |
| Gateway integration | Adapters vary by vendor | Gateway/Service PEPs consume JSON decisions |
| Developer ergonomics | Steeper (XML, policy semantics) | Simpler (JSON messages) |
| Performance & streaming | XML parsing; vendor‑specific tuning | JSON streaming‑friendly |
| Audit/receipts | Not standardized in core | Out of scope; pairs well with receipts |
AuthZEN Working Group
The OpenID AuthZEN Working Group documents common authorization patterns and standardizes mechanisms to communicate authorization information between components for better deployability and interoperability.
Examples
XACML request (XML)
<Request CombinedDecision="false" ReturnPolicyIdList="false">
<Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
<Attribute AttributeId="user.role" IncludeInResult="false">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">employee</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
<Attribute AttributeId="resource.type">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">document</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<Attribute AttributeId="action.id">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">view</AttributeValue>
</Attribute>
</Attributes>
</Request> AuthZEN request (JSON)
{
"subject": { "role": "employee" },
"resource": { "type": "document" },
"action": { "id": "view" },
"context": {}
} Decision shape
AuthZEN specifies decision exchange; EmpowerNow adds optional extension fields used by PEPs for runtime enforcement.
{
"decision": "Permit",
"ttl": 3000,
"constraints": { "egress_allow": ["*.example.com"] },
"obligations": [ { "type": "audit_log", "reason": "policy:finance" } ]
} Migration playbook
- Inventory policies and attributes; keep ABAC model.
- Map XACML categories to AuthZEN
subject/action/resource/contextJSON objects. - Introduce a PDP facade that can return AuthZEN decisions alongside existing XACML responses.
- Adopt PEP middleware in gateways/services to consume JSON decisions and enforce extension fields.
- Run dual for a period; deprecate XML flows per application as enforcement shifts to JSON.
FAQ
- Is AuthZEN a policy language? No. AuthZEN focuses on decision exchange and interoperability, not policy syntax.
- Do I rewrite policies? Usually no. Keep ABAC logic and map attributes/categories to JSON shapes.
- Can both coexist? Yes. Use a PDP adapter/facade to emit JSON decisions while XACML remains during transition.
- Where do constraints/obligations come from? They are EmpowerNow extensions carried in decisions for practical enforcement, not part of the current AuthZEN spec.