Databases Reference
In-Depth Information
•
As hinted in earlier sections, the language and runtime system should
be monotonic in the sense that once a particular level of trust has been
reached (e.g., access has been granted), the disclosure of additional cre-
dentials should not lower the level of trust. This limits the use of negation
in policies in a pragmatic manner. For example, suppose that convicted
felons cannot buy guns. This policy can be used as is in trust negotiation,
as long as the store owner checks the negated construct (not a convicted
felon) by conducting the appropriate credential discovery process himself.
In other words, the store owner cannot decide that it is okay to sell Al-
ice a gun, just because she has not supplied a convicted felon credential.
The store owner must go out to the national registry of criminals and see
whether Alice is listed there. If the runtime system does not support cre-
dential discovery and the store owner has not cached the list of criminals
before negotiation starts, then the policy cannot be used as written.
•
At a minimum, the policy language should also support conjunction, dis-
junction, transitive closure, constraints on attribute values, and constraints
that restrict combinations of multiple credentials (theta-joins, in database
terminology).
In the remainder of this section, we discuss ways to support autonomy
during negotiation, ways to minimize information leakage during trust nego-
tiation, and implementations of trust negotiation.
5.1 Supporting Autonomy during Trust Negotiation
Most modern trust negotiation (TN) approaches assume that each negotiating
party has a significant degree of autonomy in its choice of actions during each
step of a negotiation. This assumption mirrors the real world—after all, Alice
does not
have
to fill her prescription at Bob's pharmacy—and also helps to
make TN algorithms more resilient against attack. When negotiations depend
on slavish adherence to the details of a complex algorithm, then a malicious
participant can easily attack by deviating from the prescribed behavior, and
even a non-malicious participant may have little incentive to cooperate. Any
practical TN algorithm must recognize that one cannot just hand a subgoal
to an arbitrary party and expect them to produce a proof of it—what is the
incentive for them to spend their time in that manner? Similarly, from any dis-
cussion of current credential systems, it is clear that their authors intend them
to describe properties of entities. However, any database researcher knows that
entities, attributes,
and
relationships are all needed to describe the state of
the real world. Once credentials are used to describe relationships, simplifying
assumptions such as “each credential has one subject” quickly break down.
Who is the subject of a marriage certificate? A birth certificate? These certifi-
cates describe relationships between several subjects, rather than an attribute
of a single subject. While such simplifying assumptions are helpful for getting
early TN systems off the ground, at some point they must be abandoned if
TN is to scale to arbitrary web services and clients.
