[xacml] xacml model subcommittee - minutes of Jan.14 concall

[Pierangela Samarati <samarati@pinky.crema.unimi.it>]

MINUTES OF THE POLICY MODEL SUBCOMMITTEE (MONDAY, JAN. 14 2002)
===============================================================

PRESENT
* Carlisle Adams (Entrust)
* Anne Anderson (Sun) 
* Ernesto Damiani (Unimi)
* Pilz Gilbert
* Simon Godik (Crosslogix)
* Polar Humenn
* Michiharu Kudoh (IBM)
* Hal Lockhart (Entegrity)
* Fred Moses (EntitleNet)
* Tim Moses (Entrust)
* Pierangela Samarati (Unimi) -- scribe
* Sekhar Vajjhala (Sun)
* Yu 

---------------------------------------------------------------

Sekhar points out that there are problems in representing J2SE policy
with XACML due to limitations of SAML definitions.  One of the
problems is that saml:Action is currently specified as a
"string". Making Action an abstract type would allow it to be
extended. This would allow the content model to be defined by a schema
external to the SAML specification.  Thus what constitues an action
could be determined by the J2SE schema. Hal remarks that it is not yet
clear whether we can affect changes to SAML, so not to worry about
SAML limitations and possible requests for extensions. Anne says it's
ok if we can go ahead with working not inheriting SAML limitations
(going beyond SAML).  It is agreed to mark this problem down as an
open issue.

****ACTION: Sekhar to send to Ken for posting

Hal says he is not clear about whether XACML should be able to
represent the Java security model. Gil comments that XACML would be
limited if it cannot express it. Hal notes that what XACML should be
able to represent are the same requirements that Java security model
represents, but not necessarily in the same way (i.e., representing
the same authorizations). 

Tim asks us to decide whether we proceed on the assumptions that SAML
will accept our changes. Hal says he has always assumed that but he is
not sure w.r.t. this (it requires a little judgement); probably some
changes can be incorporated in SAML.

***ACTION: Sekhar and Hal to establish a liason between SAML and XACML

The second problem is Sekhar brings up is that saml:AuthorizationQuery
requires actions, while they appear optional for XACML. Simon points
out that actions are not optional for XACML. The current schema allows
actions to be missing in the target. Ann points out that the semantics
of a missing action should be defined. The semantics that Tim had in
mind is that if the action field is missing it applies to all the
actions. Paul points out that missing actions with a semantics that
applies to all actions breaks monotonicity in the behavior, so it
would be better to have a reserved simbol to mean ``all actions''. Tim
to enforce corrections on the draft. Anne suggests to leave the issue
open (Java allows empty element action, so she would like to check
that we do not loose expressiveness in always requiring an actions).

****ACTION: Sekhar to send to Ken for posting

The third problem that Sekhar points out that is XACML assumes a
single subject in AuthorizationQuery.  saml:AuthorizationQuery
currently only contains a single Subject. While a saml:Subject can
support multiple NameIdentifier or SubjectConfirmation or
AssertionSpecifier elements, it is required that they all belong to
the same principal. So a single subject cannot be used for unrelated
principals. In J2SE, there is a need to base access control on
multiple principals which are not related and this therefore points to
to a need for more than one Subject in the saml:AuthorizationQuery.
Hal remarks that he has also brought up the problems of multiple
subjects (e.g., requestor and recipient), but it was agreed to keep
the model simple. Simon points that even if the principal is a single
one the other principals (e.g., the writer of the code) can be seen as
attributes. Tim points out that the deficiency is in SAML that has no
way of communicating information like executing principal.
It is decided to mark this down as an open issue.

****ACTION: Sekhar to send to Ken for posting


How do we distinguish between attributes in the query vs attributes
that must be retrieved from an authority. Carlisle: attributes in the
query are provided to you as SAML assertions. If you do not have 

Pierangela enquires about policies being boolean expressions of
rules. It is clarified that what is called `rule' in the current draft
is not the concept of authorization rule that was assumed by this
subcommittee in the progress document.  Follows a long discussion on
the format of rules. Tim reports that the proposal in the current
draft has been taken from ANSI and ISO proposals. Pierangela points
out that the current draft seems to `index' with respect to the target
(pair action resource) by explicitely attaching the complex boolean
expression on principals/environments/resources. Concepts that in most
approaches would be though of different authorization rules are here
all combined. Pierangela says that while the proposal in the current
draft seems very appealing as an interchange policy format it may be
complicated instead to use as a specification language (administrators
should explicitely define the boolean expression of conditions
attached to a target and make sure that the result is as
intended). After a while the administation task may become very
complicated. It is noted that this discussion is related to the use of
triplets (connected to the use of declarative rules for the
specifications).
Anne and Ernesto note that for people to better understand the pros
and cons of the two approaches also a proposal (syntax and some
examples of specifications) explaining how declarative rules would
look like should be presented to the group.

**** ACTION: Simon to write a proposal and submit to the group

Follows a discussion on negative authorization. Tim says that negative
authorizations are supported in the current proposal by the NOT
operator. E.g., to say that ``administrators shall not write a medical
element'' you would specify ``NOT role=administrator'' in the
policy. It is objected that the use of NOT does not have the same
semantics as a negative authorization. For instance, suppose there is
another document with the same (or instersecting) target that says
that ``Bob'' write a record (which happens to be a medical record),
and Bob happens to have role-administrator. In this case Bob will be
able to have access in virtue of the other authorization. If you want
the NOT to have the same effect of the deny you have to ensure that
any other policy will be ANDED with the NOT. The discussion is left
open (its resolution also depends on how the previous issue will be
solved).

It is noted that the definition of ``Policy conflict'' now appearing
in the glossary (page 4, line 94-95) does not apply anymore (the
policy specification as in the current draft cannot bring conflicts).
Another change to the glossary to be enforce is that the number of
preconditions in a rule can be ``zero or more'', not ``one or more''
as currently stated (page 5, line 110).

**** ACTION: Tim to change the glossary accordingly.

Next concall will be Monday Jan 21 usual time.