RE: [xacml] Structured names]

[bill parducci <bill.parducci@overxeer.com>]

the problem that tim has present--as i understand it-- is that we have to decide two things:

1. do we wish to allow subject names that inherently reference multiple subject entities

2. what nomenclature will allow the policy writer to specify the intent of the policy in this respect

i have made the supposition that the answer to #1 is yes, i therfore will go directly to my proposal for handling #2.

any rfc1035 (dns) name below this can act as both a leaf node and branch node (e.g. overxeer.com, www.overxeer.com both resolve to physical IP addresses). the way that this is overcome (at lest with respect to identifying a specific entity on any give hostname) is through the use of the '@' symbol (which is how overxeer.com is thought of by bind: '@.overxeer.com'... at least in the configs anyway) this same model is used by e-mail, secure shell, etc.

therefore i propose that we use '@[name]' to refer to a specific subject entity using the same format as that used by e-mail, et al . now comes the tricky part. because we are working from subsets that are read right to left (in terms of granularity) we must evaluate from right to left. this can be done at the node level ('com.medico', lots of opportunity for nutty things to happen) or at the char level ('moc.ocidem', much easier to guarantee accuracy and i *think* the direction that the members of the function definition cabal are leaning towards).

operationally, i see it working like this:
(in all cases using the humenn-kudoh-engovatov superhyrid/celebrity death match string-match algorithm :o)

1.
resource: X
subject: y@medico.com
rule: allow @medico.com to read X
subject evaluation: does 'moc.ocidem@' string-match [the left 11 chars of] 'moc.ocidem@y'
result: TRUE

2.
resource: X
subject: z@medico.com
rule: allow @medico.com to read X
subject evaluation: does 'moc.ocidem@' string-match [the left 11 chars of] 'moc.ocidem@y'
result: TRUE

3.
resource: X
subject: y@east.medico.com
rule: allow @medico.com to read X
subject evaluation: does 'moc.ocidem@' string-match [the left 11 chars of] 'moc.ocidem.tsae@y'
result: FALSE

4.
resource: X
subject: y@east.medico.com
rule: allow medico.com to read X
subject evaluation: does 'moc.ocidem@' string-match [the left 10 chars of] 'moc.ocidem.tsae@y'
result: TRUE

in this manner it is very easy for the policy writer to convey exactly what the intended subject scope is for the rule/policy. it is also very easy to map to existing systems since this is a common ID structure on the 'net.

does this make sense?

b