The following notes are by Dean Tribble and resulted mainly from a conversation between Dean and myself as we tried to think of pattern like things which are significant in capability design. Here is an exploration of style to present such ideas.
Below are the items we identified. I'm just posting this to record it. This list is the start of some work on security patterns that I've been wanting to do, so I'd appreciate if the list wasn't simply widely broadcast immediately :-) It's also very raw. Keepers: trusted frontend for synergy, w/ keeper call transparent to client (meter) separation of mechanism from error handling concerns (paging) parameterization of error handling extends visitors (echeck error handler) membrane using facets for POLA creation of facets strong facet returns weak facet meta facet returns both strong and weak facets synergy patterns - opener - sealers - sibling the "verifier trick" creator sets policy (A creates B pointing at C) separation of partial correctness (figure out what not to protect against; e.g., don't check args) distributed data structures - asset pool - lamport cell streams into segments segments into streams combine designation and use determine authoritative source and forward to it non-blocking event-loop with events posted (no deadlock) promises strong random numbers as secure references strong random numbers as independently generated references with no coordination separate authority by instance, not by class Caches: lookup by object identity and no iteration of keys attenuation - reducing authority (SQL views) enhanced Visitor (creating sub-visitors) closely held capabilities object that has more authority than it reveals multiplexing factories parameterize with authority and then expose check/bottom params across trust boundaries make deputy instances revocation - revokers laundering a capability- get unique access (Space Bank) fungible vs. unique capabilities monotonicity Idempotence Immutable objects Sensory objects Read-only/write/admin separation creator gets authority and hands out only a little bit of it first process divides authority of the world (bootstrap) conservation properties to track ownership keykos space reuse trick hash of contents for identity reference initializing cycles (A->B and B->A) no uninitialized objects bounded non-determinism "expected" requirements for unachievable requirement goals no escape for references (statically prove something is closely held) don't forbid that which you cannot prevent trusted objects does the compare (e.g., for equality) pass immutable objects across security boundaries use a new instance for properties that are recursive (rather than changing and then restoring state) AnitPatterns: mapping names to authorities subtype has more authority pointing to parents (violates POLA)