OASIS eXtensible Access Control Markup Language (XACML) TC

Steven, After a quick look at Section A.3.12 it looks to me that the functions I have in mind would work fine with all the higher order bag functions. The text merely says the "worker" function invoked by the hobf must be a " ... Boolean function that takes n arguments of primitive types." The functions I am proposing are Boolean functions of two arguments of IP of DNS types. For example in abbreviated form, I am proposing: IPmatch( IPpattern, IPvalue ) I believe this would allow: Any-of( IPmatch(), IPpattern, bag-of-IP-values ) Or as in the examples in A.3.12: Any-of( IPmatch(), IPpattern, IP-bag( IPval1, IPval2, IPval3)) Does that make sense or am I missing something? Hal

Hi Hal, On 15/11/2013 7:18 AM, Hal Lockhart wrote: Steven, After a quick look at Section A.3.12 it looks to me that the functions I have in mind would work fine with all the higher order bag functions. The text merely says the "worker" function invoked by the hobf must be a " ... Boolean function that takes n arguments of primitive types." The functions I am proposing are Boolean functions of two arguments of IP of DNS types. For example in abbreviated form, I am proposing: IPmatch( IPpattern, IPvalue ) I believe this would allow: Any-of( IPmatch(), IPpattern, bag-of-IP-values ) Or as in the examples in A.3.12: Any-of( IPmatch(), IPpattern, IP-bag( IPval1, IPval2, IPval3)) Does that make sense or am I missing something? I was talking about functions in the two preceding sections, specifically: type-is-in, type-intersection, type-at-least-one-member-of, type-union, type-subset and type-set-equals. These functions directly or indirectly depend on a type-equal function. The ipAddress and dnsName data-types are the odd ones out in the core specification because they don't have these type-* functions. The type-is-in, type-at-least-one-member-of, type-subset and type-set-equals functions can be simulated with higher-order bag functions or quantified expressions, but not as compactly. The type-intersection function can only be approximated (duplicates would be retained). There is no substitute for the type-union function. Regards, Steven Hal

I don't see any problem with defining value equal functions. The only reason I wasn't planning to was because I didn't think matching an exact IP address or DNS name would be useful very often. A policy that says IP must be exactly such and such doesn't seem scalable. And matching for example, the IP of the Subject with the IP of the Resource is not like matching the Subject with Resource owner or matching the Subject's clearance with the Resource classification. Similarly I can't think of many cases where you would have a bag of say IP values and want to see if a specific one is present. The converse case of wanting to see if a single value matches a bunch of possibilities seems well covered by the use of a wildcard pattern. I will go ahead and add ipAddress-value-equal and dnsName-value-equal functions. BTW, do you have usecases in mind of are you just looking for regularity? Hal >
Original Message----- > From: Steven Legg [ mailto:steven.legg@viewds.com ] > Sent: Thursday, November 14, 2013 4:52 PM > To: Hal Lockhart; xacml@lists.oasis-open.org > Subject: Re: Using higer-order bag functions with IP & DNS functions > > > Hi Hal, > > On 15/11/2013 7:18 AM, Hal Lockhart wrote: > > Steven, > > > > After a quick look at Section A.3.12 it looks to me that the > functions I have in mind would work fine with all the higher order bag > functions. The text merely says the "worker" function invoked by the > hobf must be a " ... Boolean function that takes n arguments of > primitive types." The functions I am proposing are Boolean functions of > two arguments of IP of DNS types. > > > > For example in abbreviated form, I am proposing: > > > > IPmatch( IPpattern, IPvalue ) I believe this would allow: > > > > Any-of( IPmatch(), IPpattern, bag-of-IP-values ) > > > > Or as in the examples in A.3.12: > > > > Any-of( IPmatch(), IPpattern, IP-bag( IPval1, IPval2, IPval3)) > > > > Does that make sense or am I missing something? > > I was talking about functions in the two preceding sections, > specifically: > type-is-in, type-intersection, type-at-least-one-member-of, type-union, > type-subset and type-set-equals. These functions directly or indirectly > depend on a type-equal function. The ipAddress and dnsName data-types > are the odd ones out in the core specification because they don't have > these > type-* functions. > > The type-is-in, type-at-least-one-member-of, type-subset and type-set- > equals functions can be simulated with higher-order bag functions or > quantified expressions, but not as compactly. The type-intersection > function can only be approximated (duplicates would be retained). There > is no substitute for the type-union function. > > Regards, > Steven > > > > > Hal > > >

Hi Hal, On 15/11/2013 9:28 AM, Hal Lockhart wrote: I don't see any problem with defining value equal functions. The only reason I wasn't planning to was because I didn't think matching an exact IP address or DNS name would be useful very often. A policy that says IP must be exactly such and such doesn't seem scalable. And matching for example, the IP of the Subject with the IP of the Resource is not like matching the Subject with Resource owner or matching the Subject's clearance with the Resource classification. Similarly I can't think of many cases where you would have a bag of say IP values and want to see if a specific one is present. The converse case of wanting to see if a single value matches a bunch of possibilities seems well covered by the use of a wildcard pattern. I will go ahead and add ipAddress-value-equal and dnsName-value-equal functions. BTW, do you have usecases in mind of are you just looking for regularity? I was just noting the irregularity. I don't have any specific use cases in mind. If no one would find the extra functions useful, then you needn't define them. The union functions might be a special case since they are the only way we have to combine bags of values, which is sometimes convenient, though bag merging functions that did not care about duplicates (and therefore wouldn't need a type-equal function) would likely be just as useful. Regards, Steven Hal
Original Message----- From: Steven Legg [ mailto:steven.legg@viewds.com ] Sent: Thursday, November 14, 2013 4:52 PM To: Hal Lockhart; xacml@lists.oasis-open.org Subject: Re: Using higer-order bag functions with IP & DNS functions Hi Hal, On 15/11/2013 7:18 AM, Hal Lockhart wrote: Steven, After a quick look at Section A.3.12 it looks to me that the functions I have in mind would work fine with all the higher order bag functions. The text merely says the "worker" function invoked by the hobf must be a " ... Boolean function that takes n arguments of primitive types." The functions I am proposing are Boolean functions of two arguments of IP of DNS types. For example in abbreviated form, I am proposing: IPmatch( IPpattern, IPvalue ) I believe this would allow: Any-of( IPmatch(), IPpattern, bag-of-IP-values ) Or as in the examples in A.3.12: Any-of( IPmatch(), IPpattern, IP-bag( IPval1, IPval2, IPval3)) Does that make sense or am I missing something? I was talking about functions in the two preceding sections, specifically: type-is-in, type-intersection, type-at-least-one-member-of, type-union, type-subset and type-set-equals. These functions directly or indirectly depend on a type-equal function. The ipAddress and dnsName data-types are the odd ones out in the core specification because they don't have these type-* functions. The type-is-in, type-at-least-one-member-of, type-subset and type-set- equals functions can be simulated with higher-order bag functions or quantified expressions, but not as compactly. The type-intersection function can only be approximated (duplicates would be retained). There is no substitute for the type-union function. Regards, Steven Hal

Hal, Steven, I could see some use cases for ipAddress-value-equal and dnsName-value-equal in SCADA scenarios where you want to deny operation from all but a specific host or device. -gil
Original Message----- From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Steven Legg Sent: Friday, 15 November 2013 1:40 PM To: Hal Lockhart; xacml@lists.oasis-open.org Subject: [xacml] Re: Using higer-order bag functions with IP & DNS functions Hi Hal, On 15/11/2013 9:28 AM, Hal Lockhart wrote: > I don't see any problem with defining value equal functions. The only reason I wasn't planning to was because I didn't think matching an exact IP address or DNS name would be useful very often. A policy that says IP must be exactly such and such doesn't seem scalable. And matching for example, the IP of the Subject with the IP of the Resource is not like matching the Subject with Resource owner or matching the Subject's clearance with the Resource classification. > > Similarly I can't think of many cases where you would have a bag of say IP values and want to see if a specific one is present. The converse case of wanting to see if a single value matches a bunch of possibilities seems well covered by the use of a wildcard pattern. > > I will go ahead and add ipAddress-value-equal and dnsName-value-equal functions. > > BTW, do you have usecases in mind of are you just looking for regularity? I was just noting the irregularity. I don't have any specific use cases in mind. If no one would find the extra functions useful, then you needn't define them. The union functions might be a special case since they are the only way we have to combine bags of values, which is sometimes convenient, though bag merging functions that did not care about duplicates (and therefore wouldn't need a type-equal function) would likely be just as useful. Regards, Steven > > Hal > >>
Original Message----- >> From: Steven Legg [ mailto:steven.legg@viewds.com ] >> Sent: Thursday, November 14, 2013 4:52 PM >> To: Hal Lockhart; xacml@lists.oasis-open.org >> Subject: Re: Using higer-order bag functions with IP & DNS functions >> >> >> Hi Hal, >> >> On 15/11/2013 7:18 AM, Hal Lockhart wrote: >>> Steven, >>> >>> After a quick look at Section A.3.12 it looks to me that the >> functions I have in mind would work fine with all the higher order >> bag functions. The text merely says the "worker" function invoked by >> the hobf must be a " ... Boolean function that takes n arguments of >> primitive types." The functions I am proposing are Boolean functions >> of two arguments of IP of DNS types. >>> >>> For example in abbreviated form, I am proposing: >>> >>> IPmatch( IPpattern, IPvalue ) I believe this would allow: >>> >>> Any-of( IPmatch(), IPpattern, bag-of-IP-values ) >>> >>> Or as in the examples in A.3.12: >>> >>> Any-of( IPmatch(), IPpattern, IP-bag( IPval1, IPval2, IPval3)) >>> >>> Does that make sense or am I missing something? >> >> I was talking about functions in the two preceding sections, >> specifically: >> type-is-in, type-intersection, type-at-least-one-member-of, >> type-union, type-subset and type-set-equals. These functions directly >> or indirectly depend on a type-equal function. The ipAddress and >> dnsName data-types are the odd ones out in the core specification >> because they don't have these >> type-* functions. >> >> The type-is-in, type-at-least-one-member-of, type-subset and >> type-set- equals functions can be simulated with higher-order bag >> functions or quantified expressions, but not as compactly. The >> type-intersection function can only be approximated (duplicates would >> be retained). There is no substitute for the type-union function. >> >> Regards, >> Steven >> >>> >>> Hal >>> >> --------------------------------------------------------------------- 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

Actually you can use the match functions to do anything that you can do with the equal functions except use them as an argument to the bag and set functions. No worries. (always wanted to say that to an Aussie ;) I am including the equal functions as well as the match functions. Hal >
Original Message----- > From: Gil Kirkpatrick (ViewDS) [ mailto:gil.kirkpatrick@viewds.com ] > Sent: Friday, November 15, 2013 3:12 PM > To: Steven Legg; Hal Lockhart; xacml@lists.oasis-open.org > Subject: RE: [xacml] Re: Using higer-order bag functions with IP & DNS > functions > > Hal, Steven, > > I could see some use cases for ipAddress-value-equal and dnsName-value- > equal in SCADA scenarios where you want to deny operation from all but > a specific host or device. > > -gil > >
Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On > Behalf Of Steven Legg > Sent: Friday, 15 November 2013 1:40 PM > To: Hal Lockhart; xacml@lists.oasis-open.org > Subject: [xacml] Re: Using higer-order bag functions with IP & DNS > functions > > > Hi Hal, > > On 15/11/2013 9:28 AM, Hal Lockhart wrote: > > I don't see any problem with defining value equal functions. The only > reason I wasn't planning to was because I didn't think matching an > exact IP address or DNS name would be useful very often. A policy that > says IP must be exactly such and such doesn't seem scalable. And > matching for example, the IP of the Subject with the IP of the Resource > is not like matching the Subject with Resource owner or matching the > Subject's clearance with the Resource classification. > > > > Similarly I can't think of many cases where you would have a bag of > > say IP > values and want to see if a specific one is present. The converse case > of wanting to see if a single value matches a bunch of possibilities > seems well covered by the use of a wildcard pattern. > > > > I will go ahead and add ipAddress-value-equal and dnsName-value-equal > functions. > > > > BTW, do you have usecases in mind of are you just looking for > regularity? > > I was just noting the irregularity. I don't have any specific use cases > in mind. > If no one would find the extra functions useful, then you needn't > define them. > > The union functions might be a special case since they are the only way > we have to combine bags of values, which is sometimes convenient, > though bag merging functions that did not care about duplicates (and > therefore wouldn't need a type-equal function) would likely be just as > useful. > > Regards, > Steven > > > > > Hal > > > >>
Original Message----- > >> From: Steven Legg [ mailto:steven.legg@viewds.com ] > >> Sent: Thursday, November 14, 2013 4:52 PM > >> To: Hal Lockhart; xacml@lists.oasis-open.org > >> Subject: Re: Using higer-order bag functions with IP & DNS functions > >> > >> > >> Hi Hal, > >> > >> On 15/11/2013 7:18 AM, Hal Lockhart wrote: > >>> Steven, > >>> > >>> After a quick look at Section A.3.12 it looks to me that the > >> functions I have in mind would work fine with all the higher order > >> bag functions. The text merely says the "worker" function invoked by > >> the hobf must be a " ... Boolean function that takes n arguments of > >> primitive types." The functions I am proposing are Boolean functions > >> of two arguments of IP of DNS types. > >>> > >>> For example in abbreviated form, I am proposing: > >>> > >>> IPmatch( IPpattern, IPvalue ) I believe this would allow: > >>> > >>> Any-of( IPmatch(), IPpattern, bag-of-IP-values ) > >>> > >>> Or as in the examples in A.3.12: > >>> > >>> Any-of( IPmatch(), IPpattern, IP-bag( IPval1, IPval2, IPval3)) > >>> > >>> Does that make sense or am I missing something? > >> > >> I was talking about functions in the two preceding sections, > >> specifically: > >> type-is-in, type-intersection, type-at-least-one-member-of, > >> type-union, type-subset and type-set-equals. These functions > directly > >> or indirectly depend on a type-equal function. The ipAddress and > >> dnsName data-types are the odd ones out in the core specification > >> because they don't have these > >> type-* functions. > >> > >> The type-is-in, type-at-least-one-member-of, type-subset and > >> type-set- equals functions can be simulated with higher-order bag > >> functions or quantified expressions, but not as compactly. The > >> type-intersection function can only be approximated (duplicates > would > >> be retained). There is no substitute for the type-union function. > >> > >> Regards, > >> Steven > >> > >>> > >>> Hal > >>> > >> > > > --------------------------------------------------------------------- > 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 > >