refining definition of scope for posters

[Vlad Skvortsov]

Hi,

I'd like to propose a clarification to the way 'scope' is defined in
section 12.1 of the current spec[1].

At the very beginning the 'scope' parameter could only contain a list of
buses which limited access of the particular client for both reading and
writing (e.g. the client could only listen and post to this set of
buses). We later decided to expand the semantics of the scope to also
allow automatic filtering by certain message properties. However it is
not currenly clear in the spec how the access to buses is granted,
especially for posters.

Section 13.5 of the spec says that "The server MUST retrieve the
Access Scopes associated with the presented access token and determine
that it has Privileged Access Level for each of the Buses referenced in
the request body.". So it defers back to 12.1 to define how the access
is granted.

I think we need to clarify section 12.1 (Access Scopes) with something
along the lines of:

"Backplane server maintains configuration that defines which buses are
available to clients presenting certain client id. When fulfilling access
token request the server grants the client access to the set of buses
mentioned in the 'scope' parameter provided it is equal to or narrower than
what is defined in the server's configuration. In case of successful request
the client is allowed to both post and listen to the specified set of
buses. If no buses were mentioned in the scope paramter, the client is
granted access to all buses as per the server configuration for the
presented client id."

Thoughts?

[1]: http://backplanex.com/documentation/backplane-2-0-implementers-draft-10/#token.scopes
--
Vlad Skvortsov
VP of Engineering, Echo
p: (650) 427-9184 | v...@aboutecho.com | Twitter: @wadcom