l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Use Cases for Encapsulation and Identification


From: Jonathan S. Shapiro
Subject: Use Cases for Encapsulation and Identification
Date: Mon, 01 May 2006 14:52:32 -0400

Since Marcus has agreed that we should focus on Encapsulation,
Identification, and combinations of these, I will disregard the original
wording of the challenge. The question investigated here is "Use Cases
for Encapsulation and Identification"


1. Electronic Money.

At some point, any non-trivial computing system will be used in
commerce, and it will then require electronic money. Socially, the
concept that Mark Miller describes as "smart contracts" is also the type
of thing that should be of interest to the Hurd and to the Free Software
community.

The best mechanism (indeed, the *only* mechanism that really works) for
electronic money that I know about is described here:

  http://www.erights.org/elib/capability/ode/index.html

Note that the "purse" concept is *impossible* if the purse cannot rely
on encapsulation (to protect the tokens) and identification (to perform
the mint-exchange protocol). Note further that this example cannot be
successfully reduced to a purely hierarchical transmission pattern,
because this exposes the content of the purse to all parties in the
hierarchy.

Challenge: Explain why there are no applications of money that are
           of interest to the Hurd.

           Alternatively, propose an alternative implementation that
           avoids reliance on one (or both) of Identification and
           Encapsulation.

Hint:      The first part of the challenge is probably easier.


2. Health Privacy, or Equivalently, Privacy of Personal Information

We wish to build a computer support system for a hospital. In this
application, it is necessary that different types of users are given
different levels of access according to their role and their
professional relationships to different patients.

Under the US HIPAA law (and similar laws that are being adopted in other
countries), it is required that the hospital take steps to *prevent*
improper disclosure through technical means. It is not sufficient to
discover and punish errors after the fact.

Somewhere at the bottom of this application, there is a read-write
database with all of the data. If I am a nurse, some of this data is
stuff I can see and some of it must not be disclosed to me at all. The
legal requirements of HIPAA demand that the hospital be able to
demonstrate that some application exists which mechanically enforces
this restriction, and further requires demonstration that this is the
ONLY application that I could use to gain access to the database.
Finally, the hospital is required to show that the application will not
leak information even by accident.

Encapsulation is required to ensure that the nurse cannot bypass the
software (by inspecting its memory) that implements the disclosure
guard. Identification is required for the database to authenticate the
accessing application. The identification part can probably be dropped
if a non-confined solution is adopted, but this violates requirement
three.

Challenge: Demonstrate how to implement this without *either*
           encapsulation or identification, or explain why this
           application should not be of interest to the Hurd.



More to come, but why don't we begin with these two.


shap





reply via email to

[Prev in Thread] Current Thread [Next in Thread]