[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
Hi Rich, On 29/04/2017 5:14 AM, rich levinson wrote:
Hi Steven, What I was thinking (off the cuff) was something like the following: 1. 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 2. Define a new datatype called "keyvaluepair", which would have a form such as: <key>:<value> 3. 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.
No operations can be performed on the list unless new XACML functions are also defined to do the processing. I described three ways that XACML, as it is currently defined, could handle key/value pairs without defining a new data type or new functions.
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.
A new data type is neither sufficient nor necessary.
Isn't that obvious from the minutes ? :)
It is what I assumed you meant. Regards, Steven
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=
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]