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.

	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)
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)

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

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
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)


mapping names to authorities
subtype has more authority
pointing to parents (violates POLA)