Access.md added.

Some thoughts around identity and access management.  
Ideas still rough, but trying to share early.  Comments welcomed.

Some of this maybe should go into docs/security.md
Suggest that there are three concepts at play:

1. a unique user identifier and a scope for that resource (name and namespace) for users - this is typically an Identity or an UserMapping
2. a unique uuid that corresponds to an instantiation of a user that is unique across space and time and is the value that is associated when discussing resources that are created or deleted - might call this a User
3. a party identified by a name or uuid that is associated with the limits or resource controls, usage, and billing for a set of resources - this is usually thought of as an Account.

In many simple systems, an Identity maps to a User which is also an Account.  In systems which have federated authentication, or over time, multiple Identities may resolve to the same User.  In many enterprise systems, Users do not own Accounts - instead, Users are given access to Accounts that have been pre-allocated with resources.

The following scenarios must be handled correctly in enterprise environments

* Integrators must be able to map an authentication account (an Identity) to a unique, unchanging identifier representing an User.  
 * Because Identity values can change over time, it is usually dangerous to assume that the unique user identifier (on the Identity) can be used as the user unique identifier on the User.  
 * It is better to explicitly separate those, and instead assume each User has at least one Identity.
 * Using email as a unique user identifier (without separating Identity) will end in tears :)
* Identity providers (sources of authentication) evolve over the course of the lifetime of deployments, and a significant fraction of deployments will see N > 1 user to unique identifier mappings.