RE: [xacml] [glossary] Second Comments

[Michiharu Kudoh <KUDO@jp.ibm.com>]

Hal,

> ...
>last touched in 1996, which is a long time in this industry, so I think we
>should feel free to use its good ideas and reject other terms. For
example,
>10181-3 uses ADF and AEF which have since been replaced (in the IETF and
>OASIS) by PDP and PEP respectively. It also uses the rather cumbersome
terms
>ACI and ADI in place of what we are calling evidence.

I completely agree with you. I just wanted to say that 10181-3 is a good
place
to start and nice to understand their notions. But if their definitions are
out
of date, we should reject it and create a new one. That's why I did not
claim
using anything about ACI and ADI terms. :-)

>...
>of the identity of a system entity. What I proposed in the previous
concall
>was that we consider using Principal to refer to the abstract entity that
is
>authenticated and Subject to represent the information used to identify or
>describe the principal. If this suggestion is not accepted, I suggest we
>drop one term and use the other exclusively.

Is it ok to understand that "Principal" means Initiator or Requester, and
"Subject" refers to a description about the principal written in the
authorization policy rule such as "people who belongs to a manager role."
If so, I have no problem with that definition.

>I have proposed Target as the target of the policy. This goes to my notion
>that there are some set of fields that can be used in a very direct way,
>with minimal processing to establish which policies apply before
evaluating
>the policies (rules). I am confident that Target will include Resource, it
>might also include Action, Resource Attributes or other things. I think
the
>decision of which things will constitute the Target is an important one
that
>requires considerable thought and debate. It is even possible that the
>constituents of the Target could be specified by the meta-policy, although
I
>am not advocating that. For now, I propose to define Target in this was as
>an empty bucket and decide what goes into the bucket later.

You are saying that "there are some set of fields that can be used in a
very
direct way, with minimal processing to establish which policies apply
before
evaluating the policies (rules)." I cannot see the relation between the
Target
and your description above but the way you use the Target sounds different
from what I expect. It might confuse people who are familiar with usual
meaning
of the Target (that is the Resource). Isn't it your option to use a term
other
than the Target for your case?

>I have no problem with this, except I consider Clearance just one of many
>subject attributes  which are not separately defined. If we want to go
this
>route, I think we need to defined a generalized set of semantics around
>Clearances, Labels and Actions, including strength ordering, read-down,
>write-up, etc. I for one am not convinced the value of such a model is
worth
>the trouble, but I do not object if somebody else wants to do the work.

I was just wondering whether there was any discussion on those terms or
not.
Since we have the attribute, we will not need to use the clearance as a
different
term. But I think in XACML glossary, it could be nice to add a description
something like the clearance can be represented as one of the subject
attribute
in XACML.

regards,
Michiharu Kudo


From: Hal Lockhart <hal.lockhart@entegrity.com> on 2001/10/26 22:53

Please respond to Hal Lockhart <hal.lockhart@entegrity.com>

To:   Michiharu Kudoh/Japan/IBM@IBMJP, "Tim Moses <tim.moses"
cc:   xacml@lists.oasis-open.org
Subject:  RE: [xacml] [glossary] Second Comments




> The following is my second comments on XACML Glossary.
>
> I think XACML terms should be defined as common as possible.
> One way to do that is to follow established standard as much
> as possible.
> In my understanding, the international standard called 10181-3
> Access Control Framework [1] seems to be the closest and the most
> rigid standard for our access control domain.
> I also think that it is ok to create a new term or borrow one
> from other
> recommendations, but it should be limited to the case where the notion
> we need to use means differently from the already defined one.

I think 10181-3 (aka X.812) is a good starting point and in fact I have
been
working on a paper that tyakes it as the point of departure. However, it
was
last touched in 1996, which is a long time in this industry, so I think we
should feel free to use its good ideas and reject other terms. For example,
10181-3 uses ADF and AEF which have since been replaced (in the IETF and
OASIS) by PDP and PEP respectively. It also uses the rather cumbersome
terms
ACI and ADI in place of what we are calling evidence.

>
> Considering from the above perspective, there are several terms
> we should discuss further.
>
> Principal:
> The principal is defined in 10181-2: Authentication framework but not
> in 10181-3: Access control framework. I think that the XACML
> definition
> of Principal is not correct usage of Principal defined in
> 10181-2 meaning
> authenticated requesting entity. But the definition of XACML refers to
> the user portion of authorization policy. In this case, I
> think "Subject"
> would be more appropriate term.
> - I suggest to use "Subject" instead of "Principal."
> (XACML definition keeps the current definition.)
>

My observation is that principal and subject are used rather loosely and
interchangibly in the field to refer to both the abstaction and
represention
of the identity of a system entity. What I proposed in the previous concall
was that we consider using Principal to refer to the abstract entity that
is
authenticated and Subject to represent the information used to identify or
describe the principal. If this suggestion is not accepted, I suggest we
drop one term and use the other exclusively.

> Requester or Initiator:
> I think that we need a term for an entity that attempts to access the
> target resource. Principal written in XACML glossary does not
> mean that.
> In [1], Initiator: an entity (e.g. human user or
> computer-based entity)
> that
> attempts to access other entities, is used. In SAML,
> Requester is used.
> - I suggest to use "Initiator" or "Requester" to mean an
> entity (e.g. human
> user or computer-based entity) that attempts to access other entities.

Agreed, I fact I thought we had already agreed to this. As I have said
repeatedly, I think we need to be able to label Principals as being
Requestor, Intermediary, Recipient, etc. (My real problem is that I can't
think of a name for this label, except role. ;-)

>
> Resource:
> In [1], "Target" is used: an entity to which access may be attempted.
> But SAML uses "Resource" in their schema. I have no preference but
> just resource could mean rather general in access control context.
> - How about "Target Resource"?

I think resource is one field with narrow semantics  -- the object to be
accessed, e.g. URL, database record, file name. There should also be an
Action field and perhaps others, such as Recource Attributes.

I have proposed Target as the target of the policy. This goes to my notion
that there are some set of fields that can be used in a very direct way,
with minimal processing to establish which policies apply before evaluating
the policies (rules). I am confident that Target will include Resource, it
might also include Action, Resource Attributes or other things. I think the
decision of which things will constitute the Target is an important one
that
requires considerable thought and debate. It is even possible that the
constituents of the Target could be specified by the meta-policy, although
I
am not advocating that. For now, I propose to define Target in this was as
an empty bucket and decide what goes into the bucket later.


>
> Authorization policy:
> Authorization policy component:
> Authorization Decision:
> Why do we prefer authorization to access control?  Shorter?
> In [1], Access Control Policy and Access Control Policy Rules
> are used. The folloing is their definitions:
>
> Access Control Policy in [1]: the set of rules that define
> the conditions
> under
> which an access may take place.
> Access Control Policy Rules in [1]: security policy rules
> concerning the
> provision of the access control service
>
>
>
> The following is defined in [1] but not in XACML.
>
> Clearance:
> Initiator-bound access control information that can be compared with
> security labels of targets.

I have no problem with this, except I consider Clearance just one of many
subject attributes  which are not seperately defined. If we want to go this
route, I think we need to defined a generalized set of semantics around
Clearances, Labels and Actions, including strength ordering, read-down,
write-up, etc. I for one am not convinced the value of such a model is
worth
the trouble, but I do not object if somebody else wants to do the work.

>
> SDA:
> Security Domain Authority:
>

Since we already have several more specific types of authorities
(Attribute,
Authentication, Session, PDP) I think this term is no longer useful. If you
wish to talk in the abstract about the producer and consumer of an
assertion, SAML uses the term Asserting Party and Relying Party.

>
> [1]: ISO/IEC 10181-3:1996, Information technology- Open Systems
> Interconnection - Security Frameworks for open systems: Access control
> framework
>
> Michiharu Kudo


Hal

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>