Follow CBS client model as specified in part 2.2

[minghuaw]

2.2 Client Model

This document does not define either an authentication or authorization protocol nor does it impose any restrictions on protocol choices other than requiring a minimal set of inputs and outputs.
The assumption made for the CBS mechanism is that the client programming model encapsulates the token acquisition with a “token provider” abstraction.

The input to the token provider is

1. an AMQP URL that identifies the container and the resource inside the container for which access is requested
2. a maximum duration for the validity of the acquired token

The output from the token provider is

1. opaque access token string
2. a UTC timestamp indicating the expiration of the token

Since the CBS mechanism allows to replace tokens for links that have already been established, the client SHOULD track the expiration times of tokens it has placed into the token cache and SHOULD acquire a new token before the prior token expires and place the replacement into the cache.

The token provider model as an abstraction allows for client implementations to perform that acquisition silently for as long as the authentication proof or authorization refresh token is valid.

[minghuaw]

#126 (fe2o3-amqp-cbs version "0.0.3") provides a limited experimental implementation (missing input of max duration for the validity)