[cap-talk] Second ABAC Google talk is now up

[Julien Couvreur]

Hi,

I really like this lecture series; please keep us posted when new ones
become available. I wish we could have it at Microsoft too.
Also, I look forward to the talk on capabilities applied to the web.

Back to the last talk: the fact that it's so hard to explain
capability-based security keeps bugging me. (It takes an hour+ and
people might still not be clear.)
In comparison, it's rather easy to explain the problem with
principal-based security (solitaire example, confused deputy), but I
haven't seen a good 5 minute overview of capabilities.

My suggestion to address this would be to make a parallel with
object-oriented programming.

OO provides a set of primitives (objects, member/global variables,
private/public modifiers, APIs, design patterns) which helps the
programmer divide and manage responsibilities.
"Authority-driven design" is the same kind of change, but for
authority. It's actually a variant of OOP, with greater emphasis on
encapsulation, avoiding global state, improved APIs (designed with
authority in mind) and its own set of design patterns (also geared
towards managing authority).
Also, the names, "authority-driven design" or "authority-oriented
design", help people get an idea of the kind of paradigm shift that we
want them to understand, because they can make the parallel with the
OO shift.

After framing the scope and the nature of the paradigm with a high
level intro, then you can dive into the technical details of the
primitives and patterns. Achieving revocation and the star property
should fit in the design patterns bucket.

My 2 cents too ;-)

Cheers,
Julien

On 7/16/06, Sandro Magi <smagi at naasking.homeip.net> wrote:
> I think the discussion of the academic history in the literature
> detracted a bit from the distinction you were trying to draw between
> permission and authority. I think the point is better made by focusing
> on the concrete examples you provided in the talk, ie. setting up a web
> server to circumvent permission limitations, and then abstracting it to
> the reference graph.
>
> The web server example might be a bit of a stretch for some people, but
> there are workable alternatives, such as the unix 'write' command, if
> there are objections.
>
> I think that the academic history should be a side note, more like a "so
> why hasn't anybody done this before? They have!" Of course, this depends
> on the audience, as academics may be more interested in hearing how this
> information relates to prior research. However, covering prior research
> too early carries the danger of running into bias or objections over
> your interpretation before your point is made.
>
> Just my 2 cents. :-)
>
> Sandro
>
> Mark S. Miller wrote:
> > Kenton Varda wrote:
> >> I thought it was sort of hard to follow what overall points you were
> >> trying to make in the talk.  The information seemed to be there, but it
> >> wasn't always clear where you were going with it (or, it wouldn't be
> >> clear if I hadn't been familiar with the topic already).  Perhaps you
> >> could try stating your thesis more clearly before getting into the
> >> details, and repeat it now and then as you go.  Emphasize it so that
> >> people can more easily understand what statements are key points and
> >> what statements are just background information.
> >
> > Good suggestions. Thanks.
> >
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>