tree 2cb9234394a24d8a89903391e7151d8de8733cfa
parent e9e0db4fd8b4dfe36797f74ebffd8891e31ac3bd
author Asim Shankar <ashankar@google.com> 1455249589 -0800
committer Asim Shankar <ashankar@google.com> 1455249589 -0800

physical-lock: security: Add API for notification of changes to the default blessings.

BlessingStore.Default is a somewhat weird function - it says "default"
but practically it is meant for use by servers to reveal blessings to
clients when they don't have any other information about the client.

There seems to be a desire to allow servers to change the blessings they
identify themselves with dynamically (for example, syncbase servers
might want to identify themselves as delegates of all the applications
whose data they are hosting - which changes as new apps connect to it).

Two possible ways of achieving this:
(1) Servers continue to use BlessingStore.Default with an added API
to allow them to be notified of changes to this.
This is what is implemented in this commit
OR
(2) Drop BlessingStore.Default as an API completely and have an
explicit v.io/v23/rpc.Server.SetBlessings method that sets the
blessings used by the server.

I'm a bit torn as to which of these two alternatives is more
appropriate, but it seems that there is a leaning towards this one
since it keeps the BlessingStore as the one place to persist blessings.

One subtlety related to this approach - I haven't figured out
how to return a useful channel in the un-cached agent case
(see changes to v.io/x/ref/services/agent/agentlib/client.go).
But that may not be a practical concern?

Another TODO: Figure out the notification API in Java

MultiPart: 5/5

Change-Id: Ia48772f48908e693694bcf9ba09d40364329bc25