Databases Reference
In-Depth Information
(1) FAB
.
university
←−
StateU
(2) RegistrarB
.
student
←−
Alice
(3) EPub
.
discount
EOrg
.
preferred
(4) EOrg
.
university
←−
FA B
.
accredited
(5) StateU
.
student
←−
RegistrarB
.
student
(6) EOrg
.
preferred
←−
←−
EOrg
.
university
.
student
Table 1.
should hold credential (2) and StateU should be able to provide (1). Otherwise,
in order to prove that Alice belongs to EOrg.university.student, one would
have to obtain from FAB a complete list of universities, and contact each of
these universities to ask whether Alice is one of their students.
This illustrates that storing credentials only with their issuers can be im-
practical. However, when credentials can be stored with either their issuers
or their subjects, serious issues arise with ensuring credentials can be found
as needed during evaluation. Suppose credentials (2) and (5) are both stored
exclusively with RegistrarB. In this case, the process of elaborating the graph
would have no basis on which to identify RegistrarB as being the principal
with which these necessary credentials are stored, and the proof of Alice's
authorization could not be constructed. Although the credentials exist in the
system, they cannot be found in order to make a correct positive authorization
decision.
A solution to this problem proposed by [49] balances the advantages of
having flexibility in where credentials are stored and the necessity of finding
all needed credentials. The solution is based on a type system for credentials
that assigns types to role names. The type of a role name indicates, among
other things, where to store credentials that define roles with that role name.
Well-typing rules are introduced that impose constraints on how role names of
various types can be combined within the same credential. These constraints
are local to the credentials, yet they have the global effect of ensuring that
for every credential chain in the system, each credential in the chain can be
discovered and retrieved by a search process that starts from one end of the
chain or the other. Since these ends are known based on the authorization
query, this means that all queries can be answered correctly. The techniques
discussed above were first developed for
RT
0
, but have subsequently been
extended to full
RT
[50].
The more recent PeerAccess [66] system addresses the same problem
through a system of referrals by brokers, issuers, and subjects who are knowl-
edgeable about certain types of credentials. For example, one can imagine a
broker rather like a Google for credential search. Parties can have their own
favorite brokers that they consult when they do not know where to find a
needed credential, or they can take advantage of hints given to them by other
