University information services need unobtrusive but effective means of providing different members different levels of service, partly to offer similar controls traditionally available and partly for graceful administration of limitations that digital publishers will demand in licensing content. The ease with which computers are connected by the Internet and their ability to keep track of immense numbers of details suggests whatever administration might be wanted should be an automatic mechanism. Furthermore, we know it is feasible to provide what Lynch [5] calls “cross-organizational access management exemplified by most licensing agreements for networked information,” because it was familiar long before digital services (for instance, a stranded motorist can telephone for help and be assisted, without payment for the service call, if he belongs to an automobile club.) The question is whether it can be done sufficiently inexpensively and conveniently to be attractive to large and rapidly changing user populations.
Safe Dealing (SD) is an authorization mechanism motivated by information delivery that has many other potential applications among popular services. Some prior approaches to protecting the valuable resources in such applications have had too much administrative overhead to be widely practical. Others, such as sniffing IP addresses, have such well-known weaknesses that their use is typically introduced with apologies. That information serving is similar to other transactions that deliver valuable benefits to individual users suggests that library controls would be economical if they used the same mechanisms as e-commerce.
Each of us executes many transactions for valuable goods or services with people we know only slightly or not at all. Some of these transactions are for cash, others are with a debit or credit card, and some occur only when a service agent believes we are entitled by virtue of being enrolled in a privileged group. Notwithstanding much investigation of digital payments and other business controls, and immense interest in e-commerce and control of sensitive resources, the widely deployed mechanisms are either limited to small populations within single enterprises or are merely semiautomated replacements for what might be done with telephone inquiries.
SD’s extreme target is the circumstance in which some user requests a valuable Internet service of a server he or she has never communicated with before and might never use again. This server should grant the request only if the requester is appropriately authorized. The consideration for service might be money, but might not; a widely used alternative is authorization originating in a service agreement between the agent of a consumers’ cooperative and a producers’ agent.
Furthermore, the requester will want to avoid sharing personal information beyond what is reasonable for the transaction at hand. In fact, SD can deny digital servers any information about any user except the IP address to which they should deliver results and can still reliably limit delivery as specified by service proprietors’ policies. However to support accountability (ability to detect fraud or other users’ improprieties), SD must enable somebody to trace any suspect transaction back to its human originator. SD limits this to transaction clearance centers made trustworthy by business controls and audits not practically or economically exercised in large numbers of individual servers.
Finally, all users will want economy. Whether the implementation is manual or automatic, for many services the largest transaction cost component is likely to be (proportional to) the elapsed transaction time. The minimum increment over what unconstrained service delivery would need is that each service request must include information to be used in a clearance center decision whether or not to grant the request. Thus, the minimum incremental transaction cost is the cost of messages to and from a clearance center, just as in a credit card purchase. (For certain constrained circumstances, SD can do even better than this.) The penetration and reliability of the Internet will make this cheap enough for use in smaller transactions than are economical with credit cards.
The biggest economy possible is avoiding authorization mechanism-induced human interaction for each service transaction. SD accomplishes this without weakening any business control.
Design Sketch
Consider a relationship common to many a pair of would-be end users (EU) and resource servers (RS). Each belongs to an organization; specifically, the relationship of each EU to its requesting organization (RO) is that RO provides EU with one or more certificates of enrollment, where an enrollment is a statement that the specified EU belongs to a privilege set, such as “Princeton history faculty member.” Each RS is related to a service organization (SO) by shared definitions of tickets; each ticket identifies a set of resources, such as “Princeton Library history borrowing” or “Chicago bus ticket.” The organizations RO and SO create a third relationship by executing a service agreement, as suggested by Figure 1. Specifically, a service agreement is a map from enrollments to tickets, such as “‘history faculty member’
‘history library borrowing'”. Finally, each RS has access control lists extended from what has been conventional [3] by including ticket-to-resource mappings, such as “‘history library borrowing’
‘check out of Carl Sandburg’s Abraham Lincoln'”.
Such information, suitably safeguarded, suitably constrained by modifiers such as time limits, and suitably stored prior to EU requests from SO, is patently sufficient for a “yes” or “no” decision for any EU to SO request. Specifically, EU stores enrollments granted by RO, and requests refreshments when any such expire. A clearance center (CC, not shown) stores service agreements, and each RS is loaded with the address of its clearance center. Like enrollments, both service agreement entries and access control list entries are accompanied by expiration timestamps, thereby avoiding the well-known problem of ticket revocation. All this administrative information can be refreshed by network transactions from time to time, with these transactions occurring when the network is otherwise idle; that is, maintaining this administrative information need not degrade service request performance.
Safe Dealing (SD) is an authorization mechanism motivated by information delivery that has many other potential applications among popular services.
As part of each RS request for some resource X, EU includes its enrollments, which are encoded to be intelligible to CC and not to RS. RS forwards these enrollments to CC, which uses the service agreement to return to RS all the tickets to which EU is entitled. RS checks these tickets against the access control list entries for X, and executes the request only if it finds a match. Public key and secret key cryptography are used in well-known ways to provide security and confidentiality in both administrative and run-time communications.
Discussion and Conclusions
This SD sketch has not described critical administrative security measures or message protocols because they could not be included within the allocated space; such technical details can be seen in an online description [4]. Furthermore, this sketch mentions only a single instance of each individual or organizational role, even though in practice each role will occur many times and each EU will have relationships with many partners. For instance, most Americans are enrolled in several organizations—mine include IBM Research, the AAA, a political party, a community library, the Library of Congress, the British Library, and so on—and each of these partitions its members into several classes. Likewise, servers similar to retail merchants will number in the hundreds of thousands, each associated with one or more of thousands of service agents, and resource servers such as individually owned embedded computers might number in the hundreds of millions. The implied naming and scaling considerations will be addressed in a new report accessible at home.pacbell.net/hgladney/SafeDealing.pdf.
We built one prototype in 1999, and have been shaving it with Occam’s razor to create what we believe to be a greatly improved successor. This implementation is a set of Java classes for the Web, and exploits a generic tool for sniffing and filtering Web requests. Just how we will make it publicly available is not yet decided.
SD might be compared to two threads of prior thinking. Figure 1 suggests the relationship to identity certificate use in a public-key infrastructure (PKI). Instead of identity certificates SD uses enrollments, which are signed assertions that the user associated with a particular public key is enrolled in particular consumer cooperatives with particular privileges. Partly because such enrollments are individually useful to gain access only to limited resource sets and partly because they can be communicated directly from their issuers to their recipients, they avoid grievous problems afflicting PKI [1].
Figure 2 shows how SD adds two levels of indirection over conventional access control, [3] and one level over role-based access control [2]. Role-based control is designed for the case in which the users and the resources are all administered by a single organization; the extra level of indirection is essential to avoiding administrative headaches if access control is to span independent organizations.
Figures
Figure 1. Comparison of Safe Dealing administration using certificates derived from a global certificate authority. Left: both the general and the simplest case for SD. Right: certificate sharing in conventional public-key infrastructures.
Figure 2. Indirection in access control in RACF, RBAC, and SD.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment