Databases Reference
In-Depth Information
To be able to assist in ensuring that a proof of compliance can be found
when the appropriate credentials do exist, Blaze et al. [10] suggested nega-
tive authorization decisions be accompanied by additional information about
how a proof might be possible, given additional credentials. Gunter and Jim
argued [25] that a better approach is to enlist the assistance of the trust man-
agement engine in determining which credentials, should they exist, could
prove compliance. Specifically, they observed that doing so can avoid dupli-
cation of effort that would be incurred by using a compliance checker that
provides hints how a proof might be constructed when sucient credentials
are not presently available. The first kind of duplication is between the call-
ing application and the compliance checker. Whenever the compliance checker
returns a negative answer to an authorization query, the application itself un-
dertakes to locate the missing credentials. Then the application again invokes
the compliance checker. This process attempts to construct the proof three
times, twice by the compliance checker and once by the application when it
attempts to collect sucient credentials to construct a proof. The second form
of duplication occurs between different applications that use the TM engine.
Each application needs to have its own checking module in order to find and
collect missing credentials.
Gunter and Jim observed that these two forms of duplication of effort can
be avoided if during the evaluation the trust management engine can take
responsibility for discovering which credentials are needed to complete the
proof and retrieving them, if they exist.
Thus, trust management systems came to include a credential retrieval
mechanism and to interleave credential retrieval operations, be they local or
remote, with evaluation steps; corresponding credential repository services are
also included. QCM [25] was the first TM system to incorporate credential
retrieval; the SD3 [32],
RT
[49, 53], Minami and Kotz [51], Bauer et al. [3],
and PeerAccess [66] systems do so as well. TM engines that support credential
retrieval cooperate with each other directly, independently of the calling appli-
cations. They discover and retrieve missing credentials as needed to complete
the proof.
There are two different approaches to remote credential retrieval taken in
the literature. In the first, the request for remote credentials is itself a query
in the TM language. It requests the remote TM system to evaluate that query
and to return either the answer or credentials required to derive the answer.
The remote engine may itself send subqueries to other engines that have cre-
dentials required to complete a proof. The first approach is taken by QCM,
SD3, Bauer et al., and PeerAccess. In the second approach, the remote TM
system is requested only to provide certain credentials that the local engine
has determined are needed. The remote system simply returns credentials
matching the description given by in the request. It does not participate in
collecting further credentials from other sites. The second approach is taken
by
RT
. In the next two subsections, we discuss issues involved in these two
approaches.
