OASIS eXtensible Access Control Markup Language (XACML) TC

Hello Steven, >

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

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