OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Compound Attributes - Was: [xacml] Minutes for 27 April 2017 TC Meeting


Tiny point re: CVs :   Might want to make them 3-part!  Code base, version, key.  Of course the first two could be concatenated but the two are really separate variables. 

Martin

Sent from my iPad

> On Apr 28, 2017, at 2:25 AM, Steven Legg <steven.legg@viewds.com> wrote:
> 
>> On 28/04/2017 6:56 AM, rich levinson wrote:
>>   Documentation of HL7 data types: ref from David wrt "compound attributes":
>>     https://lists.oasis-open.org/archives/xacml/201704/msg00003.html
>>        compound attrs: variation of xml
>>     martin: datatype was sort of a code list: needed or covered?
>>      look up official country code:
>>      need datatype for "enumerated lists"
>>     rich: maybe have a key:value pair as a datatype?
> 
> Isn't a key:value pair an XACML attribute? :-)
> 
> I would have described the HL7 data types as multi-part identifiers, but as the
> IHE-XACML binding is only interested in at most two parts, and one mandatory part
> is an OID, it would have been a viable approach to treat each OID as an XACML
> attribute id and the other part as the XACML attribute value, thus avoiding the
> need for new data-types and functions.
> 
> That aside, the entities profile provides two ways to represent
> multi-part identifiers (or key:value pairs).
> 
> A value of the CV data-type would appear something like this according to HL7:
> 
>  <xacml:AttributeValue dataType="urn:hl7-org:v3#CV">
>    <CodedValue code="1" codeSystem="1.0.14265.1"/>
>  </xacml:AttributeValue>
> 
> Using the entities profile it could still be represented as XML without defining
> a new data-type:
> 
>  <xacml:AttributeValue DataType="urn:oasis:names:tc:xacml:3.0:data-type:entity">
>    <xacml:Content>
>      <CodedValue code="1" codeSystem="1.0.14265.1" />
>    </xacml:Content>
>  </xacml:AttributeValue>
> 
> The parts of the value would have to be extracted using XPath and the
> attribute-selector function.
> 
> Alternatively, using the entities profile, the parts could be represented as
> nested attributes:
> 
>  <xacml:AttributeValue DataType="urn:oasis:names:tc:xacml:3.0:data-type:entity">
>    <xacml:Attribute IncludeInResult="false" AttributeId="urn:example:hl7:attribute:code">
>      <xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string";
>         >1</xacml:AttributeValue>
>    </xacml:Attribute>
>    <xacml:Attribute IncludeInResult="false" AttributeId="urn:example:hl7:attribute:codeSystem">
>      <xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string";
>         >1.0.14265.1</xacml:AttributeValue>
>    </xacml:Attribute>
>  </xacml:AttributeValue>
> 
> The parts of the value would be extracted using the attribute-designator function.
> 
> The tricky part is writing XACML expressions that have the same effect as the
> new HL7 functions. The CV-equal and II-equal functions are straightforward, if a
> little verbose. The II-to-string and II-match functions are doable, but contorted.
> It would be much easier if there were an XACML function that behaved like the
> Java/C ternary operator "?:", i.e., if the first argument is true then return the
> second argument, otherwise return the third argument. The remaining functions
> involve transformations that could perhaps be done in the PEP and PIP rather than
> the PDP.
> 
> It would be handy for policy writers using compound attributes if XACML supported
> user-defined functions (think of a variable definition with parameters). To better
> support use cases with compound attributes I would add user-defined functions and
> a ternary operator. Representing compound attributes and processing them are
> already covered by the entities profile.
> 
> Regards,
> Steven
> 
> ---------------------------------------------------------------------
> 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 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]