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

[William Parducci <bill@parducci.net>]

All,

The Jira instance is being deprecated. Hall and I are talking to TC Admin about an alternative solution.

Stay tunedâ

b

> On Jul 26, 2023, at 8:16 PM, Steven Legg <steven.legg@viewds.com> wrote:
> 
> 
> Hi Cyril,
> 
> On 26/07/2023 11:11 am, Mr. Cyril Dangerville wrote:
>> 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?
> 
> We have barely used it in the past so I doubt anyone would mind. We can give it a try
> if no one objects.
> 
>>> 
>>>> 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?
> 
> I meant adding <xs:element ref="xacml:Expression" minOccurs="0"/> as a child of
> TargetType, if we are talking about an XACML 3.0 extension.
> 
> If we are talking about XACML 4.0 then I would suggest making the type of <Target> the
> same as <Condition> and throw out <AnyOf>, <AllOf> and <Match>. It has the same
> expressive power as adding <VariableReference> to <Match>.
> 
>>>> 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.
> 
> That would be a much safer way to do it. I would prefer to see the parameters being
> strongly typed, e.g.,
>    <InputParameter Name="xxx" DataType="http://www.w3.org/2001/XMLSchema#string"/>
> 
> I had an idea of adding parameters to variable definitions and references, which would
> effectively allow user-defined functions. It would make sense to align the parameter
> definitions.
> 
>> 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>.
> 
> We already have the precedent of arguments to functions (in an <Apply> element)
> appearing in order without any extra wrapping. I would prefer to do the same with
> arguments to a Policy(Set) reference (or a variable reference) to avoid clutter in
> the policies. PAPs are always free to present these things in more meaningful ways to
> users.
> 
>> 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.
> 
> IdReferenceType can't be extended by adding child elements, but we are already talking
> about adding extra things at the next level up (PolicyType, PolicySetType) so we could
> always define a Policy(Set)ParameterizedIdReference element and add it to the
> alternatives alongside Policy(Set)IdReference.
> 
> Regards,
> Steven
> 
>>> 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
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php