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: [xacml] Minutes from Glossary Telecon September 28


Joe Pato
Carlisle Adams
Hal Lockhart

We referenced the SAML glossary, Lynn Wheeler's definitions and RFC2828.
None of us had access to a copy of Bob Blakely's Corba Security.

The discussion was about clarifying concepts rather than wordsmithing
definitions. Hal suggested that in some cases it would be useful to decide
NOT to use a particular term or to defer defining it until the moel had been
developed to a point where the most useful definition was clearer.

Here are the major points discussed.

Principal:  the semantic entity (perhaps the abstract entity or perhaps the
real/actual entity behind all the abstractions, but, in any case, the thing
we all mean when we're talking about who or what a requester is, or an
assertion refers to, etc.

Subject:  a particular syntax for describing a principal (e.g., what appears
in the subject field of an assertion).  A single principal may be connected
with several subject syntaxes.

[Not clear how important this distinction between principal and subject is,
but it may be helpful.  Note that this understanding can be pulled out of
the definitions for these two terms in the SAML glossary, but it's unlikely
that the distinction was clear in the minds of the glossary writers at the
time of writing.  If we think this distinction is useful, we may want to
suggest that the SAML glossary definitions be sharpened slightly.]

Initiator:  [use "requester" instead] 

Object:  [use "resource" instead] 

Resource:  what we have traditionally used in our SAML/XACML discussions 

Target:  more general than "resource"; all the information used to find
which policy (or policies) apply to this request (e.g., resource and action
at least, but perhaps other information as well).  The collection of inputs
to a PRP.  [There was some discussion as to whether or not this was an
intuitive term to use, but some term (without a lot of other semantic
baggage) would be helpful in order to capture this notion.]

Evidence:  all the inputs to a policy decision.  At least three categories
may be useful: 
   - all the types of information that may be required for all policy
decisions (in a given domain?) 
   - all the types of information required for a decision with respect to a
specific request 
   - all the actual values of the various information types (e.g.,
everything returned by the PIP) 

Subject (or "Principal"?) Attribute:  includes "privileges", "rights",
"capabilities", etc..  Some debate as to whether or not it includes
"permissions" (one thought was that the attribute can be "put into an
equivalence with the permission"; in any case, subjects map simply to
permissions and permissions map simply to resources, but there can be a
complex model in the middle that maps from subject permissions to resource
permissions).  At least three categories may be useful:

   - aggregator ("is-a"):  an example is role 
   - alias ("is"):  an example might be social security number, or employee
   - modifier, or property ("has-a"):  an example might be transaction limit

Security Domain:  happy with the SAML definition 

Delegation:  ran out of time for discussion, but noted that it must be
distinguished from "impersonation" (X.509 notion versus DCE notion)

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

Powered by eList eXpress LLC