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


Personally, I think that version stuff belongs in a PDP metadata reference. The reasoning being that it is horribly inefficient to version every value, particularly when such things are generally managed as part of a larger specification. This also has the benefit of making interoperability easier when viewed as part of the larger context (profiles supported, custom extensions, etc.)

b

> On Apr 28, 2017, at 4:56 AM, BFC.McLean <bfc.mclean@gmail.com> wrote:
> 
> 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 
> 
> ---------------------------------------------------------------------
> 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]