Databases Reference
In-Depth Information
XML:
<
GROUP NAME = “
Hospitals
”
>
<
RULE
>
<
INCLUSION ID = “
reco
”
TYPE
=“
Recommendation
”
FROM = “
self
>< \
INCLUSION
>
< \
RULE
>
< \
GROUP
>
Prolog:
group
(
X,
Hospitals
)
:
−
cert
(
Y, X,
“
Recommendation
”
,
RecFields
)
,
group
(
Y,
self
)
.
Fig. 4.
An example TPL rule shown in its concrete XML syntax and its internal
Prolog representation.
with the server. To avoid undecidable computations on the client side, the
client proxy does not use the full logic; instead, it uses a limited, application-
specific logic, in which authorization decisions are tractable.
3.7 TPL
TPL (Trust Policy Language) [27], designed at IBM Haifa Research Lab, was
proposed specifically for trust establishment between strangers. TPL is based
on RBAC [23, 1] and extends it by being able to map strangers automatically
to roles. Unlike other trust management systems [46, 67], TPL's efforts are
put only into mapping users to roles, and not into mapping roles to privileges,
which simplifies the design. The latter is the responsibility of the application.
The concrete syntax of TPL uses XML to represent security rules. These
are then translated by TPL into a standard logic programming language,
viz.
,
Prolog. Figure 4 shows an example TPL rule in the portable XML notation
and its internal Prolog translation [27].
Using different
transcoders
, TPL is certificate format independent: rules
written in XML can be translated and reorganized by the transcoders into any
certificate formats, such as X.509 or PGP. In each certificate, the
certificate
type
field points to its certificate profile, which selects the proper transcoder
to interpret that certificate into its XML rules.
The mandatory components of each certificate are the issuer's public key,
the subject's public key, the certificate type, the version of the certificate, the
profile URL, the issuer certificate repository, and the subject certificate repos-
itory. The last two components were innovative considerations with respect to
credential retrieval. First, to enable the TPL system to automatically retrieve
relevant certificates from remote repositories, the certificate that is currently
being processed should specify the locations of the repositories where the rel-
evant certificates are housed. Second, certificates can be referenced negatively
in TPL, which means that TPL is non-monotonic in the sense that adding cer-
tificates can diminish authorizations. Thus TPL cannot rely on requesters to
