+
+<a name="Handling.sessions.within.applications"></a>
+<h2>Handling sessions within applications</h2>
+
+<p>Applications must be aware of the the features session and token
+when they interact with the binder afb-daemon.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<a name="Handling.sessions"></a>
+<h3>Handling sessions</h3>
+
+<p>Plugins and features of the binder need to keep track of the client
+instances. In principle, a binder afb-daemon is launched by application
+instance. But for services, a binder</p>
+
+<a name="Exchanging.tokens"></a>
+<h3>Exchanging tokens</h3>
+
+<p>At start, the framework communicate a common secret to both the binder
+and its client: the application. This initial secret is the
+initial token.</p>
+
+<p>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.</p>