YAML profile for policies

[cdanger]

Define a YAML format for XACML policies (Policy/PolicySet).

Suggestion: use a schema to define the format, e.g. JSON schema. This would make it easy to use with Vscode YAML plugin.

[cdanger]

Suggestion: wait for the new XACML 4.0 schema (proposal) to be finalized before this, as significant changes to the core schema are being discussed in several issues (e.g. #11 ). In the end, the YAML schema to be proposed here should be aligned with the proposed XACML 4.0 core schema.

[davidjbrossard]

@cdanger I need to come back on the TC now that I moved to Axio again. My vote would be to use ALFA. It's easier to read than yaml and already has some adoption.

[steven-legg]

Hi David, welcome back.

@cdanger I need to come back on the TC now that I moved to Axio again. My vote would be to use ALFA. It's easier to read than yaml and already has some adoption.

This begs the question: what is the context of use? At the moment policies only appear in protocol messages through XACMLAuthzDecisionQuery and the response to XACMLPolicyQuery (both from the SAML profiles) where only the XML representation is specified. The REST profile allows XACMLAuthzDecisionQuery when using the XML representation, but the JSON request representation doesn't support the option to include policies in the request. If we were to extend the JSON profile to include policies (and/or define a JSON equivalent for XACMLPolicyRequest) then the natural representation would be JSON. Any other representation would have to be carried as an escaped string, which is ugly and inconvenient. It hasn't been mentioned, but we could contemplate a YAML REST profile with YAML equivalents for XACMLAuthzDecisionQuery and XACMLPolicyQuery. XML, JSON and YAML are generic formats for structured data that work just as well for protocol messages, but ALFA is something else. A similar ALFA REST profile would be an oddity.

The discussions on representations haven't strayed away from the assumption that there will be a lossless mapping between policies in different representations. ALFA is starting to move away from that. The bag overloading feature is an example of implicit existential quantification, but it barely scratches the surface of what can be done if ALFA were to support the entities profile (which it must to be a complete alternative to the XML representation). I have a compact string representation for expressions based on OData principles that leverages the entities profile to aggressively exploit implicit quantification. An effect of that is that there are numerous ways to translate the string into XACML XML and vice versa; all equivalent, but structurally different. A policy wouldn't necessarily look the same if round tripped so I contrive to only translate in one direction, which makes the representation less than ideal for interchanging policies between implementations. A new version of ALFA turbo-charged by the entities profile would see the same effect. We don't have this concern translating between XML, JSON and YAML at the purely syntactic level. ALFA and my string representation are operating at a more abstract level.