Re: [xacml] FW: Draft Special Publication 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations

To: NIST authors of Guide to ABAC: Defn & Considerations

<Note>
  While I am a member of both the XACML TC and Oracle Corporation
  organizations, the following comments should be viewed as my
  own professional comments as a member of those organizations,
  but NOT viewed as comments representing any kind of consensus
  or "position" coming from those organizations. i.e. I am
  "speaking as a member of", but NOT "speaking for" those
  organizations.
</Note>

In general I found the NIST document (which I will refer to as the
"NIST ABAC Guide" or the "NIST document") to be extremely useful
in describing (defining) ABAC and listing the considerations that
organizations would be well-advised to heed when planning to
implement ABAC for their organization(s).

I also generally agree w the architecture presented and the set
of relevant entities/objects that are used to describe the
problem space.

The one area I would like to comment on is the "terminology",
and the comments I have are similar to the comments I have made
to the XACML TC about the XACML 3.0 core specification, which,
as the NIST authors describe is intimately connected w the
NIST document:

	"This document complements the OASIS XACML specification
	 by providing a basic definition, concepts, and components
	 that make up an ABAC model."

The point is that while the NIST ABAC Guide, imo, improves on
the use of terminology that is used in the XACML spec, it does
not fully address what I consider to be the core issues w the
terminology in the XACML spec.

For ref, the xacml 3.0 spec is here:
  http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.pdf

To be specific, I will initially address my comments to the
list of defns in the NIST document on p8, lines 490-513.

To avoid getting mired in details prematurely, let me first
say what I think the terminology "should be", then address
the specific changes that I would suggest making to the
NIST document.

The main suggestion is that there be one term used to
represent a collection of attributes. The most common
term I have found is "entity". Therefore, I suggest that
all the major concepts that refer to something that can
be represented as a collection of attributes, be referred
to as an "entity".

  Note: imo, the fundamental necessity is to have a grammatical
	term to use to refer to a collection of these
	attributes. If people do not like the term "entity",
	than some other term that can effectively be used
	in the same manner would be an alternate suggestion,
	although, imo, "entity" seems to be the best choice.

For reference, in XACML 3.0, there is a one to one correspondence
between my suggestion for the term "entity" w the xacml term
"Attributes" (plural). The problem w the xacml term is it
is ungrammatical and unintuitive to refer to the thing
that can be represented as a collection of attributes,
as an "Attributes".

The above should identify the general problem I am trying
to address both in the NIST doc and the XACML spec. Now
let me try to address the specifics on page 8 of the NIST doc:

  - line 498: "a subject is an active entity":

	I would suggest referring to "subject entity" or
	"subject entities" when statements are made about
	the collection of attributes representing a "subject".

	In this sense, "subject" starts take on the form
	of a descriptor of the collection of attributes,
	which fits well w the XACML 3.0 notion of "Category",
	and, in fact, xacml 3.0 in appendix B.2.

  - line 504: "an object is a
	 passive information system-related entity":
	
	I would suggest using the term, "resource entity",
	or (less preferable, because of possible technical
	confusion w "object-oriented" concepts) "object entity".

	Again, similar to "subject", one can easily envision
	different "types" of "resource entities", which, in
	general can be realized by extending the XACML 3.0
	Appendix B.2 term for "resource category". (this can
	be done directly w new category names, or indirectly
	w an attribute identifying the resource type.

	Basically, anything that a user can attempt to access
	could be abstractly referred to as a resource.

  - line 510: "an operation is the execution of a function"

	First, I don't even understand what that means, but
	leaving that aside, here is the suggestion:

	I suggest using the term "operation entity" or
	"action entity" to refer to the "what" the subject
	is requesting to do w the resource.

	One attribute could be the name of the operation.
	However, one can easily imagine there might be
	a set of parameters that could be included as
	attributes in the operation entity, much like
	the parameter list of a function call.

  - line 493: "Attributes are characteristics that define
	specific aspects of the
	  subject,
	  object,
	  environment conditions,
	  and/or requested actions
	that are predefined and preassigned by an authority."

	3 of the 4 items above are discussed in the 3 bullets
	above. For the 4th item, "environment conditions",
	I suggest using the term "environment entity".

	In general, similar to resource, there could be
	multiple environment entities of different types,
	or a single environment might also be sufficient.
	In any event, similar to resource, the environment
	could be extended w multiple "category" defns,
	identifying the "type" of environment that the
	collected attributes are referring to.

One further note is that the NIST document also refers to
"Non Person Entities" (NPEs) in several places. I think it
is sufficient to note that the text in lines 301-303:

	"For the purposes of this document, the term subject
	 is used to denote any entity (human or non-human)
	 requesting access to an object"

appears sufficient to remove any ambiguities w this use
of the term "entity" in the NIST document.

  Thanks,
  Rich Levinson