OASIS eXtensible Access Control Markup Language (XACML) TC

Time: 4:30 PM EST (-0400 GMT/DT) ^-------^^ Tel: 1-712-775-7031 Access Code: 620-103-760 Minutes for 27 April 2017 TC Meeting I. Roll Call & Minutes Roll Call: attendees: Steven Legg Rich Levinson Hal Lockhart Bill Parducci Martin Smith bill: we have quorum Approve Minutes for 13 April 2017 - updated w correct date in subject line: https://lists.oasis-open.org/archives/xacml/201704/msg00009.html hal: any obj to unan: none heard minutes approved II. Administrivia ACM Paper uploaded by David: ACM paper on how to implement ABAC / XACML (requires membership) "A Systematic Approach to Implementing ABAC" In this paper we discuss attribute-based access control (ABAC), and how to proceed with a systematic implementation of ABAC across an enterprise. The paper will cover the different steps needed to be successful. http://dl.acm.org/citation.cfm?id=3041051 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? hal: we welcome suggestions martin: ref to codeset, then key to any value in code set hal/martin: deferencible url? bill: json? martin: authoritative issuer, version number, ... medical procedures subject to ongoing change: how to manage Groups - Updated core spec uploaded https://lists.oasis-open.org/archives/xacml-comment/201704/msg00003.html redline version: https://lists.oasis-open.org/archives/xacml/201704/msg00008.html III. Issues Errata Status Action for tc from last mtg minutes: from Hal: I am going to walk through the document that I posted to the list: https://lists.oasis-open.org/archives/xacml/201704/msg00001.html The TC is encouraged to review and discuss the proposed actions before the next meeting. Groups - xacml-3.0-core-spec-errata01-wd05.doc uploaded https://lists.oasis-open.org/archives/xacml/201704/msg00002.html discussion from 15-day public review or errata doc: hal and cyril dangerville: https://lists.oasis-open.org/archives/xacml/201704/msg00001.html https://lists.oasis-open.org/archives/xacml-comment/201704/msg00003.html hal: approve wd as committee specification draft confirm no substantive changes ask tc admin to conduct 15-day review we will vote on this next time Break the Glass (for ref): Bill: A draft document was posted by David Chadwick on the XACML email list: https://lists.oasis-open.org/archives/xacml/201102/doc00000.doc martin: seems like could be supported w core xacml rich: basically agrees, but there are other perspectives that need to be considered. hal: yes, but there was request to extend spec w signals which was an issue that was never resolved to move forward. IV. mtg adjourned 4:55PM EDT next mtg w weeks: may 11, 2017

On 28/04/2017 6:56 AM, rich levinson wrote: Break the Glass (for ref): Bill: A draft document was posted by David Chadwick on the XACML email list: https://lists.oasis-open.org/archives/xacml/201102/doc00000.doc martin: seems like could be supported w core xacml rich: basically agrees, but there are other perspectives that need to be considered. In one of the implementation options the document offers there are requirements placed on the context handler that are outside core XACML. However I think the proposal is more complicated than it needs to be. Rather than deny access and provide an obligation (really it's advice) that tells the PEP that the user is allowed to break the glass and try again, I would provide a Permit result and an obligation that says that access is permitted only if (because it's an obligation) the user elects to break the glass. If the PEP doesn't understand then the result becomes Deny. If the PEP understands but is unable or unwilling to proceed with the glass breaking the result still becomes Deny. If the PEP follows through with obtaining user consent and the user agrees then access is permitted without any follow up requests to the PDP. If the user isn't permitted to break the glass to get access then the result wouldn't be Permit in the first place. The preceding doesn't require any special support from the context handler, PDP or PAP. If the obligation identifies which "pane" of glass needs to be broken then any subsequent authorization requests requiring the same pane to be broken can proceed without delay because the PEP and user already broke that pane. It is left to the PEP to decide when to "fix" the pane, as appropriate to the context, without bothering the PDP with a ResetBreakTheGlass action or the need to keep state. Whether going with a deny solution or permit solution, the most challenging part is designing the policies such that, respectively, the Deny obligation isn't returned when the user isn't allowed to break the glass, or the Permit obligation isn't returned when the user has access anyway without breaking the glass. Regards, Steven

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

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

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 >

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=  

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=

Hi Steven, I agree that the entities profile is probably a good soln to this issue, however, I was responding to your question: Isn't a key:value pair an XACML attribute? :-) , which I interpreted to mean that you were assuming that I was considering the attribute element tag as the name, and the attributevalue/value as the value. Is there another way to interpret your question? :-)   Thanks,   Rich On 5/1/2017 12:08 AM, Steven Legg wrote: 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.     https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.oasis-2Dopen.org_xacml_3.0_xacml-2D3.0-2Dcore-2Dspec-2Dos-2Den.html-23-5FToc325047176&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=Z43JkK9J65DJhBmvLihVAQ3GqVX1le6wxT0aioKqMwY&s=bVBgpiIYzgxlMUCNdWbqK_jVTnnmH2f9Lfl98WHwUik&e=  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=