OASIS eXtensible Access Control Markup Language (XACML) TC

The URIs take up a lot of real estate in a policy even in XML but it will be more apparent in a less verbose syntax like YAML, and most of it is repetitive. A good-quality PAP would shield the policy writer from that, but there aren't many of those and it seems the common PAP experience isn't much better than a plain text editor, so making the text more readable would be an advantage for perception and practical reality for many. Reducing the byte size of the policies doesn't hurt either.

You are clearly looking for something that is part of the core language, that is faithfully preserved in translations between the different policy syntaxes, rather that applying some sort of preprocessing. That means that the type of a field like DataType can't just be anyURI anymore. It also needs to be able to carry the name of an entity and optional extra text (typically a suffix). We already have a data-type called entity so we should use a different name for these things. For the sake of argument I'll call them labels. So a field like DataType needs to be able to hold a URI or a text string with embedded label names. We could try to express that in the policy syntax type system (XML Schema, JSON Schema, ...). However, if we restrict the use of labels to fields for URIs (the main culprits) then we could just define an IdentifierType as a replacement for the current anyURI that is formally a string in the type system but in prose is required to be a URI after the substitution of any label names.

You alluded to global variables so I assume you are thinking that the label definitions are constructs separate from policies. That certainly reduces duplication since many policies can then share the same label definitions. An advantage of URIs is that they are globally unique. The appeal of labels is that they are short and simple, so not globally unique. Any situation where policies from different sources are composed together runs the risk of label name conflicts. To avoid that I suggest lumping label definitions into collections that are identified with a URI, and have policies list, by URI, any collections they are using. Policies from different sources would bring their own label collections, which they unambiguously reference, avoiding name conflicts.

We could define a standard label collection for all the standard-defined URIs as a convenience.

<?xml version="1.0" encoding="UTF-8"?> <Policy xmlns="urn:oasis:names:tc:xacml:4.0:core:schema" PolicyId="http://example.com/test" Version="1.0"    CombiningAlgId="urn:test:my-custom-combining-alg">    <CombinerParameter ParameterName="p1">        <AttributeValue DataType="^string">a</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p2">        <AttributeValue DataType="^string">b</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p3">        <PolicyId>http://example.com/P1</PolicyId/>        <AttributeValue DataType="^string">c</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p4">        <PolicyId>http://example.com/P1</PolicyId>        <AttributeValue DataType="^string">d</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p5">        <AttributeValue DataType="^string">e</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p6">        <AttributeValue DataType="^string">f</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p7">        <PolicyId>http://example.com/PS1</PolicyId>        <AttributeValue DataType="^string">g</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p8">        <PolicyId>http://example.com/PS1</PolicyId>        <AttributeValue DataType="^string">h</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p9">        <AttributeValue DataType="^string">i</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p10">        <AttributeValue DataType="^string">j</AttributeValue>    </CombinerParameter>    <PolicyIdReference>http://example.com/P1</PolicyIdReference>    <PolicyIdReference>http://example.com/PS1</PolicyIdReference> </Policy>

The URIs take up a lot of real estate in a policy even in XML but it will be more apparent in a less verbose syntax like YAML, and most of it is repetitive. A good-quality PAP would shield the policy writer from that, but there aren't many of those and it seems the common PAP experience isn't much better than a plain text editor, so making the text more readable would be an advantage for perception and practical reality for many. Reducing the byte size of the policies doesn't hurt either.

You are clearly looking for something that is part of the core language, that is faithfully preserved in translations between the different policy syntaxes, rather that applying some sort of preprocessing. That means that the type of a field like DataType can't just be anyURI anymore. It also needs to be able to carry the name of an entity and optional extra text (typically a suffix). We already have a data-type called entity so we should use a different name for these things. For the sake of argument I'll call them labels. So a field like DataType needs to be able to hold a URI or a text string with embedded label names. We could try to express that in the policy syntax type system (XML Schema, JSON Schema, ...). However, if we restrict the use of labels to fields for URIs (the main culprits) then we could just define an IdentifierType as a replacement for the current anyURI that is formally a string in the type system but in prose is required to be a URI after the substitution of any label names.

You alluded to global variables so I assume you are thinking that the label definitions are constructs separate from policies. That certainly reduces duplication since many policies can then share the same label definitions. An advantage of URIs is that they are globally unique. The appeal of labels is that they are short and simple, so not globally unique. Any situation where policies from different sources are composed together runs the risk of label name conflicts. To avoid that I suggest lumping label definitions into collections that are identified with a URI, and have policies list, by URI, any collections they are using. Policies from different sources would bring their own label collections, which they unambiguously reference, avoiding name conflicts.

We could define a standard label collection for all the standard-defined URIs as a convenience.

<?xml version="1.0" encoding="UTF-8"?> <Policy xmlns="urn:oasis:names:tc:xacml:4.0:core:schema" PolicyId="http://example.com/test" Version="1.0"    CombiningAlgId="urn:test:my-custom-combining-alg">    <CombinerParameter ParameterName="p1">        <AttributeValue DataType="^string">a</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p2">        <AttributeValue DataType="^string">b</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p3">        <PolicyId>http://example.com/P1</PolicyId/>        <AttributeValue DataType="^string">c</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p4">        <PolicyId>http://example.com/P1</PolicyId>        <AttributeValue DataType="^string">d</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p5">        <AttributeValue DataType="^string">e</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p6">        <AttributeValue DataType="^string">f</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p7">        <PolicyId>http://example.com/PS1</PolicyId>        <AttributeValue DataType="^string">g</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p8">        <PolicyId>http://example.com/PS1</PolicyId>        <AttributeValue DataType="^string">h</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p9">        <AttributeValue DataType="^string">i</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p10">        <AttributeValue DataType="^string">j</AttributeValue>    </CombinerParameter>    <PolicyIdReference>http://example.com/P1</PolicyIdReference>    <PolicyIdReference>http://example.com/PS1</PolicyIdReference> </Policy>

> I'm sure we can find something if the idea makes sense to pursue by the TC ("notion", "ref"...doodad? ��)

Shortcut?

We would want to be able to easily tell the difference between a literal URI and a label surrounded by URI parts without imposing the need to apply escaping to any characters in a URI. These characters aren't allowed in a URI: "<>\^`{|} so we can use any of them to introduce a label. Your example used ^ at the start. That's okay, but without a distinct end character the label can only be followed by URI characters that can't be part of a label name, so ^label/foo is good but ^labelfoo isn't. If we wrap the label there is no restriction on what follows, e.g., <label>foo or {label}foo . And do we have a special case for a field value that is just a label name? So DataType="^string" or DataType="{string}" is the same as DataType="string". This would align with what the JSON REST profile is already doing.

The URIs take up a lot of real estate in a policy even in XML but it will be more apparent in a less verbose syntax like YAML, and most of it is repetitive. A good-quality PAP would shield the policy writer from that, but there aren't many of those and it seems the common PAP experience isn't much better than a plain text editor, so making the text more readable would be an advantage for perception and practical reality for many. Reducing the byte size of the policies doesn't hurt either.

You are clearly looking for something that is part of the core language, that is faithfully preserved in translations between the different policy syntaxes, rather that applying some sort of preprocessing. That means that the type of a field like DataType can't just be anyURI anymore. It also needs to be able to carry the name of an entity and optional extra text (typically a suffix). We already have a data-type called entity so we should use a different name for these things. For the sake of argument I'll call them labels. So a field like DataType needs to be able to hold a URI or a text string with embedded label names. We could try to express that in the policy syntax type system (XML Schema, JSON Schema, ...). However, if we restrict the use of labels to fields for URIs (the main culprits) then we could just define an IdentifierType as a replacement for the current anyURI that is formally a string in the type system but in prose is required to be a URI after the substitution of any label names.

You alluded to global variables so I assume you are thinking that the label definitions are constructs separate from policies. That certainly reduces duplication since many policies can then share the same label definitions. An advantage of URIs is that they are globally unique. The appeal of labels is that they are short and simple, so not globally unique. Any situation where policies from different sources are composed together runs the risk of label name conflicts. To avoid that I suggest lumping label definitions into collections that are identified with a URI, and have policies list, by URI, any collections they are using. Policies from different sources would bring their own label collections, which they unambiguously reference, avoiding name conflicts.

We could define a standard label collection for all the standard-defined URIs as a convenience.

<?xml version="1.0" encoding="UTF-8"?> <Policy xmlns="urn:oasis:names:tc:xacml:4.0:core:schema" PolicyId="http://example.com/test" Version="1.0"    CombiningAlgId="urn:test:my-custom-combining-alg">    <CombinerParameter ParameterName="p1">        <AttributeValue DataType="^string">a</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p2">        <AttributeValue DataType="^string">b</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p3">        <PolicyId>http://example.com/P1</PolicyId/>        <AttributeValue DataType="^string">c</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p4">        <PolicyId>http://example.com/P1</PolicyId>        <AttributeValue DataType="^string">d</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p5">        <AttributeValue DataType="^string">e</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p6">        <AttributeValue DataType="^string">f</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p7">        <PolicyId>http://example.com/PS1</PolicyId>        <AttributeValue DataType="^string">g</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p8">        <PolicyId>http://example.com/PS1</PolicyId>        <AttributeValue DataType="^string">h</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p9">        <AttributeValue DataType="^string">i</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p10">        <AttributeValue DataType="^string">j</AttributeValue>    </CombinerParameter>    <PolicyIdReference>http://example.com/P1</PolicyIdReference>    <PolicyIdReference>http://example.com/PS1</PolicyIdReference> </Policy>

> I'm sure we can find something if the idea makes sense to pursue by the TC ("notion", "ref"...doodad? ��)

Shortcut?

We would want to be able to easily tell the difference between a literal URI and a label surrounded by URI parts without imposing the need to apply escaping to any characters in a URI. These characters aren't allowed in a URI: "<>\^`{|} so we can use any of them to introduce a label. Your example used ^ at the start. That's okay, but without a distinct end character the label can only be followed by URI characters that can't be part of a label name, so ^label/foo is good but ^labelfoo isn't. If we wrap the label there is no restriction on what follows, e.g., <label>foo or {label}foo . And do we have a special case for a field value that is just a label name? So DataType="^string" or DataType="{string}" is the same as DataType="string". This would align with what the JSON REST profile is already doing.

The URIs take up a lot of real estate in a policy even in XML but it will be more apparent in a less verbose syntax like YAML, and most of it is repetitive. A good-quality PAP would shield the policy writer from that, but there aren't many of those and it seems the common PAP experience isn't much better than a plain text editor, so making the text more readable would be an advantage for perception and practical reality for many. Reducing the byte size of the policies doesn't hurt either.

You are clearly looking for something that is part of the core language, that is faithfully preserved in translations between the different policy syntaxes, rather that applying some sort of preprocessing. That means that the type of a field like DataType can't just be anyURI anymore. It also needs to be able to carry the name of an entity and optional extra text (typically a suffix). We already have a data-type called entity so we should use a different name for these things. For the sake of argument I'll call them labels. So a field like DataType needs to be able to hold a URI or a text string with embedded label names. We could try to express that in the policy syntax type system (XML Schema, JSON Schema, ...). However, if we restrict the use of labels to fields for URIs (the main culprits) then we could just define an IdentifierType as a replacement for the current anyURI that is formally a string in the type system but in prose is required to be a URI after the substitution of any label names.

You alluded to global variables so I assume you are thinking that the label definitions are constructs separate from policies. That certainly reduces duplication since many policies can then share the same label definitions. An advantage of URIs is that they are globally unique. The appeal of labels is that they are short and simple, so not globally unique. Any situation where policies from different sources are composed together runs the risk of label name conflicts. To avoid that I suggest lumping label definitions into collections that are identified with a URI, and have policies list, by URI, any collections they are using. Policies from different sources would bring their own label collections, which they unambiguously reference, avoiding name conflicts.

We could define a standard label collection for all the standard-defined URIs as a convenience.

<?xml version="1.0" encoding="UTF-8"?> <Policy xmlns="urn:oasis:names:tc:xacml:4.0:core:schema" PolicyId="http://example.com/test" Version="1.0"    CombiningAlgId="urn:test:my-custom-combining-alg">    <CombinerParameter ParameterName="p1">        <AttributeValue DataType="^string">a</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p2">        <AttributeValue DataType="^string">b</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p3">        <PolicyId>http://example.com/P1</PolicyId/>        <AttributeValue DataType="^string">c</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p4">        <PolicyId>http://example.com/P1</PolicyId>        <AttributeValue DataType="^string">d</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p5">        <AttributeValue DataType="^string">e</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p6">        <AttributeValue DataType="^string">f</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p7">        <PolicyId>http://example.com/PS1</PolicyId>        <AttributeValue DataType="^string">g</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p8">        <PolicyId>http://example.com/PS1</PolicyId>        <AttributeValue DataType="^string">h</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p9">        <AttributeValue DataType="^string">i</AttributeValue>    </CombinerParameter>    <CombinerParameter ParameterName="p10">        <AttributeValue DataType="^string">j</AttributeValue>    </CombinerParameter>    <PolicyIdReference>http://example.com/P1</PolicyIdReference>    <PolicyIdReference>http://example.com/PS1</PolicyIdReference> </Policy>