...
This takes the view that the TAAs "add" and "delete" TAs. A very
different view, one that makes things a lot simpler, is that TAAs
propose additions and deletions, and the software for the recipient
of those proposals chooses whether or not to act on those proposals.
As I said at the mic in Chicago, I'm not suggesting that end users
need to think about each TAA action; they can just make policy
decisions and let the software act accordingly.
You raise an important issue of perspective. If a TAA is an
"authority" then it can try to do anything (e.g., issue any command
in a protocol), but the effects of what it does are constrained by
the authority granted to it. That authority may be defined by the
user, or by some other TAA.
However, we do need to be very careful about the complexity of
polices that can be expressed here. We have lots of experience in
the security environment that suggest users, even sys admins, are not
very good at managing policies once the level of complexity grows
beyond a certain point. Our requirements development process needs
to be mindful of this issue, and not assume that users will suddenly
become much better at this crucial task.
Steve
