Databases Reference
In-Depth Information
Prior to deploying access control systems based on TN, their systems and
architectural properties must be fully explored. Most existing trust negotiation
implementations exist largely as proofs of concept designed to illustrate the
feasibility of the underlying theory and have performed admirably in this
capacity. We need experience with small-scale real-world deployments to really
understand what research issues must be addressed before TN can hit the
mainstream.
As part of this effort, trust negotiation systems must be hardened against
attack and made scalable under heavy load. While initial steps have been
made in this direction [55, 40], much more remains to be done.
6.3 Distributed Proof Construction
The process of constructing a proof of authorization is one instance of the
general problem of distributed proof construction, which has received a bit of
attention in the logic programming community. However, authorization proofs
face several construction challenges that have not been fully addressed.
Autonomy in proof methods.
Each party is autonomous and may have its
own way of constructing proofs, delegating work to others, and choosing what
queries to answer and which to ignore. Further, these parameters may change
over time; for example, a party may need to ignore low-priority queries during
periods of high load, or provide intensional answers instead of its usual ex-
tensional answers. In such an environment, how can we orchestrate everyone's
individual efforts toward the larger goal of building a single authorization
proof?
Sensitive information.
As an additional complication, pieces of a proof may
be sensitive and not freely disclosable to others. Thus successful proof con-
struction may depend on finding the right party to act as a helper in collecting
information. Further, it may be necessary to cloak sensitive information as it
passes through the hands of third parties during proof construction [51]. Ide-
ally, we should also have a means of ensuring that others have respected our
rules about what they can do with the sensitive information we disclose to
them. These are lofty goals, and a great deal of work is needed before they
will be met.
Non-monotonicity.
As discussed in the previous section, TN systems need
to be monotonic in the sense that the arrival of additional evidence will not
decrease the level of trust. As explained earlier, this does not mean a policy
cannot call for the absence of a particular piece of evidence (e.g., that a
credential not be revoked); rather, one has to be very careful about which
party checks those negative conditions. The best way to integrate the checking
of negative conditions into distributed proof construction is an open problem.
When TN is used in pervasive computing, the current environment may be
one factor in authorization decisions. For example, perhaps a student can use
a conference room only between 8 AM and 5 PM. The environment can change
over time, violating monotonicity. To date, researchers have developed several
