[xacml] Dec-17-01 policy model raw notes

[Simon Godik <sgodik@crosslogix.com>]

Title: [xacml] Dec-17-01 policy model raw notes

Attached are --raw-- notes of dec 17, 2001 policy model subcom conf call.

<<pm-dec-17-01.txt>>
Simon Godik

pm subcom call on dec-17-2001

Carlisle,
Polar,
Ann Anderson,
Michiharu,
Sekhar,
Tim Moses,
Ernesto,
Simon,
Gil.

Ernesto: Some procedural issues were discussed.

Carlisle: pierangela would maintain a list of issues in the subcommitte
and she would sent this list to Ken, who would post it on the web site.

Ernesto: Document is slowly taking shape. We should point to this document
out of the issues list.

Tim: Some sence of sequence or priority would be helpful. Mechanism for agreeing
on priority will be helpful.

Sekhar: Whoever cares about an issue can write it up.

Carlisle: That might introduce delay into the process.

Tim: It's important to submit a proposal with an issue.

Ernesto: Competing solutions are listed together with issues.
If there are some proposed solutions to the issue specify competing
solutions. Pierangela will maintain and edit issues list.

Ernesto: We agree that we follow recom of tc to prepare issue list.
If there is a solutions that should be listed with the issue.
We will priorities issues.

Ernesto: We asked for submissions of policy test cases.

Ann Anderson: Are we going to discuss mins of the last meetings.
Grant or deny attribute was not agreed, but just proposed.
Questions about last 2 paragraphs.

Ernesto: Should we discuss 2 last paragraphs?

Ann: There was discussion of this, but there was no decision made.
I propose to discuss it within a context of a use case.

Ernesto: We discussed diffs between compositions of policies and
outcomes of policy decisions. The wording in the minutes are too strong.
There was no agreement on this.

Tim: If we have a list of reqs on the syntax, we could then ask submitter
to explain how requirement is met.

Saikar: It sounds good to collect all reqs. Then come out with proposed syntax.

Ernesto: let's start in cronological order.

Tim: Looking at the submission we seem to have req to identify the policy, the target of the policy,
issuer of the policy, locate and evaluate attributes of at least 3 things. We need to make comparisons
among attributes. Hierarchy is not a req on xacml syntax. In my proposal appears to be no need to
identify attributes of specific ... I have taken it as an assumption that we are using the components
of saml as input and if you want to apply this lang in non-saml context then there is a translation step.

Gil: This is more than assumption. It's in a charter.

Sekhar: Charter is intended to work with other standard bodies. J2SE is a use case that does not require
the use of saml

Tim: We will end up with #any element and explain how to use it.
There is no too much else. There is no preconcieved support for any particular relationships between
subjects, or resources. We need to explain how it should be used under particular circumstances.

Ann: What special case?

Tim: Special case for hiearchies. My answer is no.

Ann: Were you also saying that there is no need to call out subjects or resource attributes.

Tim: This is currently the case. Predicate element goes on to describe relation between principal and resource.
It's a mixture of attributes of both of these things.

Ann: I agree with that.

Ernesto: I wanted all predicates to be xpath expr on saml assertions. last mo some interesting considerations
were made on how to use xacml. It would be artifitial to translate everything to saml.
It is probably is in issue.

Tim: We should note it as an issue.

Tim: I offer to take an counter position and see what should be implied if it is all saml.

Ernesto: In the last couple of con calls I've heard access to interfaces, programming langs.

Gil: Many people in a saml group think that xacml tries to take on to much.
By removing saml restriction we will never be done. I admit these problems need to be solved.

Carlisle: I agree. It's reasonable to define universe for input as saml for xacml 1.0

Polar: You need to define what input should be. Take x509 and transform it to saml.

Carlisle: We can put it on the issues list. For 1.0 confine ourselves to saml.

Sekhar: There are 2 use models: Use a syntax and no saml assertions. Use case 2 really required saml intercations
with pep. All the issues will be considered as use case 2.
Req for j2se is that you could use xacml syntax. The use model is that if you have j2se platform and xacml
policy provider, there should be no need to use saml azn query to query pdp.

Ernesto: We need to support saml. We will champion additional saml bindings.

Gil: sound good to me.

Ernesto: Comment on Tim's policy case. There is one thing. Do we want support separation between
principals, resources, environment, etc. I was under the impression it is an open question.

Tim: I'm not sure there is a conclusion. I think Ann offered support for my position. Simon is for
more explicit syntax. We can make principal, res, etc an attribute. We did not resolve a question.

Ernesto: we could have add syntactic sugar.

Polar: Having syntactic sugar is fine. Do they have to be in a base syntax?

Ann: Problem with putting it in the base there is an issue with assertions with combinations of principal
and environment. There could be other types of attributes (like codesource). Then syntactic sugar is getting
in the way of what a policy is doing.

Carlisle: I agree with that. It looks like pa tool. I want all the policies of this particular resource.
My preference for the base spec is not to have it.

Ernesto: Majority is for not having syntactic sugar. I would like to have a decisions on it.
We can keep it as an open issue.

Ernesto: Hiearchies support is interesting. I would like to submit possible solutions for it.


Ernesto: Next policy case - Ann's.

Ann: This was taken from real life situation. The idea is a number of policy issuers. It imposes some performance
impact on deny. Deny applies within a signle policy. When that deny is supposed to overwrite deny's from
other sources than there is performance implications. We would like subpolicies to be self contained.

Ann: There is also an idea that somehow policy retrieval point supplies pdp with complete policy to be evaluated.
Policy retrieval point should be retrieving separate policy components as needed. If policy A grants access
then there is no need to retrieve policy B.

Ernesto: I would like to clarify: would we want the granularity of a dialog between prp and pdp as a single rule?

Tim: In my mind, the expectation is you get the whole thing. We should accept suggestion and discuss it
when we start doing bindings.

Ann: Ability to describe matching rules. It seems to me that current exp that you can use regular
expr is limited. If the principal's name is x500 dn you can not compare it against a simple string,
because there are canon rules. xacml cold specify that there has to be canonical expression for every
attribute.

Ernesto: There will be cases where you want simple canonicalization.

Polar: We should have regexp, dates, simple types.

Ann: Postconditions has the same sort of problems that deny has. If elements has post-cond associated with them
you do not know which one is going to be evaluated.

Tim: We already discussed that issue.

Ernesto: action-resource bindings --- keep it as an issue.

Tim: we made a small attempt to address this issue in version 7. So the question is not forgotten.

Ernesto: Should we support resource-action binding in the language. Simon will champion this issue.

Ernesto: Discussion that we had on a explicit deny. Do we want it or not?

Ann: Michiharu's use case goes into that in more detail.

Ernesto: Next case.

Michiharu: Policy test case I posted was about xml resource. This means that xml resource consist of many
subelems and attributes. Document consist of use case discr and policy specification and some requirements
and policy spec based on currently proposed xacml syntax. Let me start with use case description. Suppose
that there is xml inst document- order req. But that xml contains some sensitive info under secret element.
Security admin may have to specify policy to hide this element. Sample policy is when internal user submits
access req, every element is accessible, if access req comes from external user, than you may not read any
element below secret element. I made 3 policy specs. First one is grant only policy. I think this completly
conform to xacml policy model. Second one has only grant semantics, but it use different algorithms for propogation.
The 3rd policy described using grant and deny and propogation. In the grant only policy there is no big difference.
The 3rd policy I used explicit deny element. For example, if principal is internal user and resource is the root
not the return value is grant. If the principal is ext user and resource element is secret or any descendant then
response is deny. We need some conflict resolution mechanizm. If deny takes precedence, than deny response
is computed. From this use case requirements are: ability to describe grant and deny as well as grant only policy.
The point is to provide syntax and semantics with extensibility and flexibility. Ability to support tripple
based synatx on res-act-subject. I wrote sample specification for the policy. If you see specification I think
there is a big difference between intuitive meaning of the policy. If we use triple type policy specification,
it is short and easy to understand. I agree that deny must be supported in xacml conformance processor. Important
point is how to provide extensibility to support semantics other than grant. We need to specify extension
architecture of xacml.

Ernesto: Do we want grant and deny? Or just grant with addition of nessary cond. This could be as easy as an
element with the value of grant. I believe there is an issue here. The other issue is syntactic triplet base policy.
We already have an open issue for that. Do we want to support grant semantics only?

Ann: This specific example could be handled with grant semantics only.

Michiharu: I think you are right. This is not exhaustive policy. What I intended was if you assume that negative
equalifty element that rule must be written in all rules of the policy. This is one way to write a policy.
But that is one way to do that. I propose that xacml should be flexible enough to allow deny type of policy.

Gil: Policy tree is expressed as an hierarchy with default deny. You can use a sparse model. As soon as you introduce
deny I try to do policy eval I have to parse the whole tree. This can get very expensive.

Michiharu: This is not distributed case.

Ernesto: Let's put it down as an issue, and Michiharu would like to champion it.