[cap-talk] Abstractions that subsume capabilities

[Rob Meijer]

On Fri, March 7, 2008 14:12, David-Sarah Hopwood wrote:
> Jed Donnelley wrote:
>> At 02:10 PM 3/6/2008, Karp, Alan H wrote:
>>> Jed wrote:
>>>> Hmmm.  I spent a bit of time looking around on the Web and
>>>> didn't find anything that I would consider a 'taxonomy' for
>>>> access control schemes.
>>> I'm working on a study group for the Navy chartered with creating a
>>> position paper on SOA IA Security.  (Services Orientented
>>> Architecture Information Assurance, for you non-military types.  I
>>> usually apologize for the lack of acronyms in my notes to that
>>> group.)  They use DAC/MAC to describe who determines access and IBAC
>>> (identification), RBAC (role), ABAC (attributes) to define the
>>> authentication used to make an authorization decision.  Because of
>>> the acronym collision, we use NBAC (autheNtication) for the those
>>> three and ZBAC (authoriZation) for what I'm pushing.  That's sort of
>>> a 2-dimensional taxonomy.
>>
>> Am I wrong in considering RBAC and ABAC really just forms of IBAC?
>
> No, that's correct. So it is a hierarchical classification, not
> 2-dimensional:
>
> <pre>
>           access control
>          /              \
>       NBAC              ZBAC
>     /  |  \            /    \
>    /   |   \        caps   split-caps
> IBAC RBAC ABAC     /  \
>                    /  object-caps
>            non-object-caps
> </pre>

Only when looking at your diagram I realized that the ABAC acronym jumped
to the other side. This to me is rather confusing, wouldn't it be better
to keep using ABAC as authorization based access control rather than ZBAC?

With respect to RBAC there is an other problem I noted in my previous post
that would keep your diagram from being fully valid.
You would thus end up with the folowing:

      NBAC
      /  \
     /    \
   IBAC   RBAC(statefull)
    /
   /
 RBAC(static)


Rob