[E-Lang] MintMaker with ACLs

Marc Stiegler marcs@skyhunter.com
Tue, 30 Jan 2001 12:46:17 -0700

This new version may or may not answer an issue that I have that is not
quite Tyler's issue, though it is related to the difference between a mint
that makes money and a bank that tracks people's accounts.

Physical metaphor: My car breaks down in the Appalachians, a barefoot
14-year-old kid comes down from a ramshackle shanty and helps me get it
started. I give him a 20-dollar bill as thanks for helping out.

The kid does not need an account with a bank, he merely needs a hand with
which to grasp the money. No bank is in a position to know that it was the
kid who got the money, so if someone at the bank has a grudge against that
kid, too bad for the grudge holder: they cannot diddle the account to take
the money from him. Though the mint owner (the government in the case of
dollars) can defile the currency, they cannot target the boy for
confiscation. And the bank cannot say, "this boy is untrustworthy and we
will not grant him an account, at least not until he has done the following
things to prove to us that he is properly subservient."

The MintMaker supports the electronic equivalent of this interaction. I can
give money to people (and computing objects) who don't have and don't want
accounts--why should I have to get an account just to accept payment? Save
me from this hassle!

Another way of looking at this is, a mint has less authority, and needs less
authority, than a bank. A mint must be trusted to do good accounting, but it
does not have to be trusted with the knowledge of who owns how much, since
it only knows about purses, and purses map many-to-many on owners of purses.
This makes it very different from a bank.

With the E programming language, using a MintMaker pattern I can used
capabilities to implement a mint, but I can also use E's normal programming
powers to implement banks (since the code in Hal's first example is also
straightforwardly implemented in E). I can make programs in E that support
both, by having the banks process purses rather than digits.  I therefore
claim that a capability-secure language like E is strictly superior to
non-capability languages, since it can do both.


----- Original Message -----
From: <hal@finney.org>
To: <daw@cs.berkeley.edu>; <hal@finney.org>; <markm@caplet.com>;
Cc: <e-lang@eros-os.org>
Sent: Tuesday, January 30, 2001 10:36 AM
Subject: RE: [E-Lang] MintMaker with ACLs

> Tyler writes:
> > The way you are using the password isn't exactly like an ACL system.
> > In an ACL system, the password is intrinsic to the invoker. The
> > invokee is able to magically determine the invoker and check the
> > authority. In your design, you are explicitly passing the password on
> > each invocation. This makes it more like a capability. If you combined
> > the srcAccount and password parameters into a single parameter, it
> > would be a capability.
> Let me try again, then, to make it more ACL-like.  Instead of passwords
> I'll use UIDs.  See what you think of this one:
>     // account balances, indexed by account number
>     int balance[];
>     // User IDs of account owners, indexed by account number
>     UID ownerUID[];
>     // Message requesting transfer
>     int transfer (int sourceAccount, int destAccount, int amount)
>     {
>         // See that this user is owner of account
>         if( getuid() != ownerUID[sourceAccount] )
>             return ERROR_INVALIDACCESS;
>         if( balance[sourceAccount] < amount )
>             return ERROR_INSUFFICIENTFUNDS;
>         // Proceed with transfer
>         balance[sourceAccount] -= amount;
>         balance[destAccount]   += amount;
>         return NOERROR;
>     }
> Here I have introduced an operating system call, getuid(), which returns
> the current user ID of the operating process.  This is used rather than a
> password to access the account.  The mechanism for securely determining
> the UID in a distributed computing environment is outside the scope of
> this example (but might involve passwords, smartcards, biometrics etc.).
> To allow some of the other features Tyler suggests, let us extend this
> example with a list of UIDs which are allowed to read the balance:
>     // User IDs of those allowed to read balance
>     UIDlist accessUIDs[];
>     // Request balance
>     int getBalance (int account)
>     {
>         // See if this user is allowed public access
>         if( ! accessUIDs[account].contains( getuid() ) )
>             return ERROR_INVALIDACCESS;
>         return balance[account];
>     }
> For other features Tyler mentioned like giving my accountant the ability
> to read my account history, a similar mechanism would be used: introduce
> a new UIDlist for the required permission and check that the user ID of
> the requestor is in that list.
> For the confused deputy example, let there be an agent which will reveal
> my public balance under certain conditions.  This agent needs to be
> running with its own UID and that UID is put on the accessUIDs list above.
> This way I don't have to give the agent more power than he needs and the
> POLA is satisfied.
> Now let me give an example of a change that's easy to make with this
> system.  Suppose there were some master account belonging to the bank
> or the IRS which needs to be able to read all balances.  I can achieve
> this by changing one line in the getBalance call above, from
>         if( ! accessUIDs[account].contains( getuid() ) )
> to
>         if( ! accessUIDs[account].contains( getuid() ) && getuid() !=
> Can the MintMaker at
> be modified as easily to accomodate this change?  Maybe it can, I
> don't know.  Intuitively it seems like the ACL system would be more
> suitable to feature like this which seems tied to identity, but perhaps
> the capability system can handle this as well.
> Hal
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang