tree d286885281627d7d9debf4c52f9538df47b486a9
parent 9c4841b410e0ea6576a21bfe742e64b7b151d1c7
author Asim Shankar <ashankar@google.com> 1455249572 -0800
committer Asim Shankar <ashankar@google.com> 1455249572 -0800

chat: 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: 4/5

Change-Id: I2f35b22eb00b517765622143f5c861ea475f7850