Databases Reference
In-Depth Information
creating accounts and remembering passwords, this traditional approach will
severely limit Alice's options for shopping around for the best price. The trust
negotiation approach overcomes all of these shortcomings: Alice and Bob meet,
disclose their policies, and exchange credentials to establish a trust relation-
ship instantly. Further, all the negotiating steps listed above can be carried
out automatically by small software agents acting on their owners' behalf, so
that trust establishment is transparent to the human participants.
The pharmacy example shows only one possible way of establishing trust,
based on explicit disclosure of credentials and policies. Researchers have in-
vestigated many alternative approaches, each with its own advantages and
disadvantages, and we will describe them later in this chapter.
3 History
In this section, we survey the principal contributions to date. We will introduce
each system by explaining what features it has, what main contributions it
makes and the applications its designers had in mind.
3.1 PolicyMaker and KeyNote
PolicyMaker, developed and defined by Blaze
et al.
[11], was the first trust
management system. It was designed as a proof of concept for the design
principles of trust management with a minimalist prototype implementation.
For example, the PolicyMaker system does not take responsibility for cryp-
tographic verification of credentials. Instead, these verifications must be done
by the application that call the trust management system.
In PolicyMaker, assertions (security policies and credentials) have the form
“
<
Source
>
ASSERTS
<
AuthorityStruct
>
WHERE
<
Filter
>
.” ASSERTS
and WHERE are keywords in PolicyMaker, while the syntax of the fields
<
Source
>
,
<
AuthorityStruct
>
and
<
Filter
>
are application-dependent. The
<
Source
>
field identifies the authority that makes this assertion, the
<
Author
ityStruct
>
field contains the subjects to whom this assertion applies, and
the
<
Filter
>
field has an application-specified string “
<
action string
>
” that
must be satisfied for the assertion to hold. The whole assertion states that the
<
Source
>
trusts the subjects to be associated with
<
action string
>
.
KeyNote [9, 10] is a direct descendant of PolicyMaker, and follows most
of its design principles. However, unlike PolicyMaker whose assertions are
fully programmable and application-dependent, KeyNote's [9] assertions are
written in a specific, concise and human readable assertion language. The
assertion language is defined to be simple and to be supported by a small
interpreter. In addition, the expressiveness of the assertions is carefully limited
so as to ensure that resource usage is proportional to policy size.
Figure 2 shows a sample KeyNote assertion that states that the authorizer
delegates to either of the licensees for read access on file “/etc/passwd.” The
