[cap-talk] Architectural Choices for Security: terminology

Karp, Alan H alan.karp at hp.com
Fri Nov 16 18:21:59 EST 2007

David Hopwood wrote:
> I'm not so sure. In an ABAC system, what determines whether a subject
> is authorized to perform a particular request?

Whether or not the proper authorization accompanies the request.  I know
that's a tautology, but anything more specific depends on how you
represent the authorization.  The key is that the decision about
granting access is done before the request is made, not when it is
> By saying 'ABAC', we normally mean to imply a specific answer: that
> references (object designators) carry authorization, and that they are
> unforgeable and transferrable between subjects. But none of this is
> clear from the term 'ABAC' itself.

Not all capabilities are object capabilities.  Not all authorizations
are capabilities.
> Also, by IBAC we don't mean just any use of identity; we mean that for
> each request the system performs an access check based on the 
> requesting
> subject's identity. Most (all?) of the criticisms we have of 
> IBAC systems
> arise from consequences of checking requestor identities. 
> Other uses of
> identity (such as in petname systems, for instance) don't 
> have the same
> consequences.

Identities are useful for determining what authorities to grant and who
to hold accountable for their use.  They are not what you want to use
when deciding whether or not to honor a request.  Petnames make that
distinction clear.
> In Java (as designed by Sun, not Joe-E), the security of the system
> relies both on some references carrying authorization, and on 
> requestor
> identities being checked via stack introspection. In Plash, there are
> both capability-based access controls, and requestor-based controls
> inherited from Unix. If we understand these systems as being based on
> multiple security mechanisms, there's no problem. But since 
> other terms
> ending in 'AC' have most often been used as mutually exclusive
> categorizations of *systems*, rather than mechanisms, it is too easy
> to assume that 'ABAC' and 'IBAC' are meant in the same way.

I mean them in the same way that most people use the term -AC.  I
consider the mix of capability and identity based mechanisms to be a
> >> But unless you are talking to the smaller circle of people 
> who speak
> >> of AuthN and AuthZ, the N and the Z need such a long 
> explanation that
> >> it gets in the way of the discussion. NBAC and ZBAC is a total 
> >> failure for an "elevator pitch", for example, unlike IBAC and ABAC.
> >
> > I agree with everything you say, but I still think we need a more
> > general term.  As I'm talking about IBAC, I can just see 
> them thinking
> > "What's wrong with this guy?  Hasn't he ever heard of RBAC?"
> RBAC is a special case of IBAC: for each request an RBAC 
> system performs
> an access check based on the requesting subject's identity (mapped to
> a role).

Yes, but that fact appears to be something people only recognize after
you tell them.
> If we defined IBAC to require that only direct subject identities can
> be used in policy specifications, then almost nothing would be IBAC --
> e.g. ACL systems that support groups would not be, since a group isn't
> a direct subject identity.
Actually, I believe my request is accompanied by proof of my identity.
If the access check on my identity fails, the system looks up what
groups that identity is a member of and does the access check until one
succeeds or they've all been tried.
> In any case, if we are going to change 'ABAC' and 'IBAC', 
> let's make sure
> that we are changing them to something that is clearly an improvement,
> and on which we have a concensus on this list. I don't think 
> there is a
> concensus for any of the terms suggested so far (including 
> the '-centric'
> terms).

> At risk of repeating myself, I view the critical distinction as being
> between access control mechanisms in which references carry authority,
> vs. those based on checking of requestor identities. I don't have a
> concrete terminology suggestion at the moment, but I would be 
> happy with
> any terms that made this distinction clear.
I would like to broaden the distinction.  For example, while we've shown
that SAML certificates can be used to combine designation with
authorization, they can also be used as authorizations distinct from the
designation.  I introduced the term ABAC as a way to express both.

Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029

More information about the cap-talk mailing list