Re: [xacml] List of pending issues (backlog)?

["Mr. Cyril Dangerville" <cyril.dangerville@thalesgroup.com>]

Hello Steven,

> -----Original Message-----
> From: xacml@lists.oasis-open.org <xacml@lists.oasis-open.org> On Behalf
> Of Steven Legg
> Sent: vendredi 21 juillet 2023 01:52
> To: xacml@lists.oasis-open.org
> Subject: Re: [xacml] List of pending issues (backlog)?
> 
> 
> Note to everyone: Cyril's original message went to my spam folder and it
> seems to be a common experience. Mark it as not spam if you see the same
> thing.
> 
> Hi Cyril,
> 
> On 20/07/2023 9:53 am, DANGERVILLE Cyril wrote:
> > Hello all,
> >
> > I have (re)joined the XACML TC recently, and as I have a few issues to add
> to the TCÂs Âbacklog for later discussion, I am looking for a place in the TC
> workspace where you keep track of pending issues. Is there such a place?
> >
> > IÂve seen the ÂWishlist page on the wiki but seems quite old.
> 
> That page would be the place. We have been remiss in keeping it up to date.
> Feel free to refresh it.

[DANGERVILLE Cyril] OK. In the meantime, I found out there is a JIRA in the TC workspace. To start and follow the work on a specific issue, I think JIRA is more efficient.
https://tools.oasis-open.org/issues/browse/XACML 
Is it OK to use the JIRA for that?

> 
> > To give an idea, some issues of interest to me:
> >
> > 1)Changes to XACML core spec:
> >
> > a.Backward-compatible / non-breaking changes:
> >
> > i.Add <VariableRefence> as third choice in Target <Match> (in addition
> > to AttributeDesignator, AttributeSelector)
> 
> I would like to go further and let the Target have a full Expression. The
> difference between Target and Condition is supposedly to facilitate policy
> (set) indexing.
> However, I've found that some functions allowed in a target are impractical
> to index while many things allowed in a Condition, but not in a Target, are
> eminently indexable.
> I actually build indexes over both the Target and Condition so the difference
> between their expressiveness is more a hindrance than a help.
> 
 
[DANGERVILLE Cyril] OK just to clarify for me, do you mean to replace the <xs:choice> (AttributeDesignator/AttributeSelector) with simply <xs:element ref="xacml:Expression"/> in the <Match> definition?

> > ii.Add <VariableDefinition>s as optional elements in <PolicySet> and
> > <Rule> (like in <Policy>)
> 
> Yes for PolicySet. It does raise the question of the scope of the variable
> definition.
> Does it only apply to embedded policy sets, policies and rules, or does it also
> apply to referenced policy sets and policies? I don't mind whether rules have
> variable definitions.
> 

[DANGERVILLE Cyril] Yes, important question. 
So in my proposal (based on functional programming), the VariableDefinition scope only applies to the embedded policy sets, policies and rules;
but if you need to use variables in referenced Policy(Set), you can pass them as *arguments*, meaning...as part of the change proposal...

1) Policies/PolicySets may take input parameters (zero or more) that have to be declared explicitly in the Policy/PolicySet, e.g. <InputParameter Name="xxx"....> (not to be confused with CombinerParameter), each with an optional default value in case it is not assigned in the Policy(Set) reference. 
This is basically the same thing as <xsl:param>s in XSLT templates.

2) Policy(Set)IdReferences may have *arguments*, i.e. parameter assignment expressions (similar to AttributeAssignmentExpressions) matching the input parameters of the referenced Policy(Set), e.g. <ParameterAssignmentExpression ParameterName="xxx">the value expression</ParameterAssignmentExpression>. The value expression can be any Expression, so for instance a <VariableReference> to pass a variable value. 
This is basically the same thing as <xsl:with-param>s in XSLT <xsl:call-template>.  

One issue with 2) though is that it may require a change to the XML schema for Policy(Set)IdReference to support these parameter assignment expressions, which is not backward-compatible.

> More generally I would like to have the option of variable definitions as free-
> floating global constructs that can be referenced from any rule, policy or
> policy set, perhaps with a top-level import statement in the rule, policy or
> policy set to signal the dependency and enable the referencing.
> 

[DANGERVILLE Cyril] I think we'll need a dedicated thread - JIRA issue? ;-) -  to discuss all details.

> > iii.Support JsonPath evaluation in <AttributeDesignator>,  by adding
> optional attribute ÂcontentType (for example) = ÂJSON or ÂXML (ÂXML is the
> default value), to indicate whether the <Content> must be processed as
> ÂJSON object instead of XML, and the ÂPath handled as JsonPath according
> to this draft RFC: https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/
> <https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/>. For this one, it
> may be safer to wait it become an IETF standard. But itÂs good to anticipate.
> 
> Obviously you mean <AttributeSelector>. Since we now have a JSON profile,
> providing support for JSONPath makes sense.

[DANGERVILLE Cyril] Yes, my mistake! I mean <AttributeSelector> for sure.

> 
> > b.Breaking/non-backward-compatible changes to XACML core spec,
> therefore to be considered rather for XACML 4.0:
> >
> > i.XSD simplification: replace Obligation/Advice(Expression) elements
> > with one PepAction(Expression) element and a XML attribute
> > required=Âtrue (for Obligation) or Âfalse (for Advice)
> 
> Yes. It would save duplicating code to process two things that are almost, but
> not quite, the same structure.
> 
> It could be done in XACML 3.0 by adding an Optional attribute to Obligation
> and deprecating the use of Advice.
> 
> > 2)New profiles:
> >
> > a.YAML Profile of XACML: for writing XACML policies in YAML.
> 
> I don't object to a YAML representation for policies, but I would prefer to see
> a JSON representation first (or at the same time).
> 

[DANGERVILLE Cyril] OK let's add that to the list. 
FYI, as part of our AuthzForce project, I have defined a JSON schema for policies, as well as for the Request/Response based on the JSON Profile of XACML. (These Request and Response schemas have been reused in the draft GEOXACML 3.0 JSON PROFILE.)

KR,
Cyril

> Regards,
> Steven
> 
> >
> > Kind regards,
> >
> > Cyril