OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC