+Handling sessions within applications
+-------------------------------------
+
+Applications must be aware of the the features session and token
+when they interact with the binder afb-daemon.
+
+Applications are communicating with their binder afb-daemon using
+a network connection or a kind of network connection (unix domain
+socket isn't currently implemented but could be used in near future).
+Also, HTTP protocol is not a connected protocol. It means that
+the socket connection can not be used to authenticate a client.
+
+For this reason, the binder should authenticate the application
+by using a commonly shared secret named token and the identification
+of the client named session.
+
+### Handling sessions
+
+Plugins and features of the binder need to keep track of the client
+instances. This of importance for plugins running as service
+because they may have to separate the data of each client.
+
+For common HTML5 browser running an HTML5 application.
+
+### Exchanging tokens
+
+At start, the framework communicates a common secret to both the binder
+and its client: the application. This initial secret is the
+initial token.
+
+For each of its client application, the binder manages a current active
+token. The initial token is the default active token. It is the expected
+token for new clients.
+
+