Hi Steven,
What I was thinking (off the cuff) was something like the following:
Use the multivalue attribute property, where multiple
instances of the
same attributevalue are treated as multiple values.
http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html#_Toc325047176
Define a new datatype called "keyvaluepair", which would have
a form such as:
<key>:<value>
When multiple attribute values of this type are defined within
the same attribute element,
or attribute entities within the same attributes element and w
same metadata (issuer, attr-id),
this would result in a "bag" of <key>:<value>
"values",
which can be interpreted as an enumerated list of
"keyvaluepair"s, w attr-id being the
attribute parent's attr-id.
So, basically the result is a named list of "keyvaluepair"s
Operations on this list could be done such as finding all values
w a given key, etc.
So, I think the key chg would be that a new datatype that
contains both a key and a value
would be sufficient to provide this capability.
Isn't that obvious from the minutes ? :)
Rich
On 4/28/2017 2:25 AM, Steven Legg
wrote:
On 28/04/2017 6:56 AM, rich levinson wrote:
Documentation of HL7 data types: ref
from David wrt "compound attributes":
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.oasis-2Dopen.org_archives_xacml_201704_msg00003.html&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=d-u_sjFedLXxRM5j2ZvcP8YE0FDaC5SEScbzLF8vUtE&s=GDvg2ecIa4LN97ZqdgbXDffAjwIrTzFPXL1w4Szvnqg&e=
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:AttributeValuedataType="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:AttributeValueDataType="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:AttributeValueDataType="urn:oasis:names:tc:xacml:3.0:data-type:entity">
<xacml:AttributeIncludeInResult="false"AttributeId="urn:example:hl7:attribute:code">
<xacml:AttributeValueDataType="http://www.w3.org/2001/XMLSchema#string">1</xacml:AttributeValue>
</xacml:Attribute>
<xacml:AttributeIncludeInResult="false"AttributeId="urn:example:hl7:attribute:codeSystem">
<xacml:AttributeValueDataType="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://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_apps_org_workgroup_portal_my-5Fworkgroups.php&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=d-u_sjFedLXxRM5j2ZvcP8YE0FDaC5SEScbzLF8vUtE&s=KD2w4mTFo4Sjl-BEeRXK56gKnjSEkAtnm9wybNWTsAY&e=
