First there is the idea of legacy domains which allow key savvy code written in another machine language to fully and transparently participate in a system with normal interpretive overhead. There would at least be legacy domain creators (LDCs) providing the legacy domains and the holders of LDCs would certainly know their nature as it is necessary to supply them with the correct kind of machine code to obey.

There are many proposed bank enhancements. I recall thinking that there were too many to put into one bank implementation, if the bank is to retain its position near the root of most TCBs. One general solution to this might be called the bank keeper. This is implicit in the unimplemented “prompt bank” idea that pervades many Keykos conventions, such as passing two banks upon object creation. The idea is that I could trust an unprompt bank to keep my secrets even when I could not trust it to return promptly. I could not conceal just when it was that I bought the space to hold my secrets, but I could be sure that the space I bought was accessible only to me.

Speaking of TCBs, it is possible in the current design for a well endowed user to acquire disk storage without going thru a “real space bank”. Instead they might be granted a range key to their very own physical portion of the disk. Such a plan need not impact security of other users of the machine. Such a user would require their own domain creators which would acquire space thru some different mechanism it they were to build domains from their special space. Alternatively they could buy domains built of ordinary space. Data base systems on Unix once (still?) acquired raw disk space that was not mediated by the “normal Unix file system”.

There is a collection of ideas called the [smart] producer which supports transfer of ownership. With such a scheme I can build an object and transfer it to you thereby manifestly rescinding my ability to delete it.

There is the related issue of durable objects with manifest lifetimes, just as factories produce objects of manifest discretion.

There are more mundane issues of quality of storage. Quality parameters include: bandwidth, access time, price, reliability, and many non scalar qualities such as, who has subpoena power over the storage. Most of these do not depend on bank behavior but may merely stem from the underlying keys such as range keys.

It would be good to go thru a mock design of remote ciphered storage and its relationship with the rest of the system.

I wish I had time to explore what the rules might be between a bank and its keeper. Perhaps a bank is trusted to report what decisions it delegates to its keeper(s). I don’t know how many of these bank extensibility problems could be solved with the one simple bank keeper concept.