Answers to chat comments

I saw after my presentation yesterday that a number of comments were put in
the chat window. I will try to answer them in the following.

>> A tag is the same as a new piece of metadata?

Yes.

It is a YAML line: “validate”: “X”, where X can be either “write-only” or
“read-write”. This is added to the YAML source files in the “deployment
phase” using e. g. the layering tool under discussion. It is an instruction
to the guard/server what to do with requests in terms of token validation.

>> In your GitHub msg, are the "requirements" number 1 to 6 at the
beginning the same thing as auth level (0-9)?

No.

Reqs 1-3 describes the different access restrictions that shall be
supported.

Reqs 4 describes how restrictions can be applied to node(s).

Req 5 describes that permissions can be assigned to a client for parts of
the tree, down to separate nodes.

Req 6 describes that clients can be assigned access to different parts of
the complete tree. This req is the one that is solved through use of auth
levels.

>> It is usually considered safer to whitelist... If no tag defined should
the default be to not allow the request?

Whitelist is typically a more scalable design than blacklists, so if either
is needed I agree that is to prefer.

Having as default (no tagging) not allowing requests (without token) may
reduce the risk of mistakes leading to undesired client access. However, I
think this leads into a more philosophical discussion about “closed” vs
“open” design goals. Where I am more for the open (but controlled)
approach. An active decision is needed to restrict, rather than to open up.
I believe that philosophical view is more aligned with the general W3C view
in this field. With the proposed model it only requires one line of YAML
code to restrict the complete tree, so such a decision is easily
implemented.

>> What is the meaning of "w/o tag"? w/o I thought means "without"?

Here it means “write-only”, an instruction to the guard/server to require
token validation only for write requests.

>> we have 4 then , read, read/write, write, and without

When we in VSS replaced the node type “signal” with the node types
“sensor/actuator/stream/” we had a discussion about whether an actuator,
which obviously is writeable, also by default should be readable. The
conclusion was the latter. I think this can be extended to access the
access restriction use case, that writability always comes with
readability. What would be a use case where only write access should be
permitted? The reqs list currently contains unrestricted access, read-only
token permission, and read-write token permission. If we decide to add a
req for write-only token permission then the proposed design needs rework.

>> how is an access token tied to a subset of signals this token gives
access to?

The proposal shown in the 2nd comment on the issue 322 contains two fields
in the token - a scope field that, using a VSS path, points to a subtree,
and an access field specifying the permission for the scope.

>> how flow would look like for 4 diff clients, with tag read, write only,
read/write and "no tag", and they would access to exactly same branch
vehicle.cabin.door. Story with tokens I understand and all good, but with
tags I did not see any additional benefit.

Excluding the write-only case, the following I believe shows the benefits
it can provide.

The vehicle.cabin.door branch node has three different tagging options:

T1: No tag

T2: Validate: write-only

T3: Validate: read-write

The three clients have respectively: client 1:no token,client 2:  read-only
token, client 3: read-write token (tokens have a scope containing this
subtree, and are non-expired).

A: For the T1 scenario all clients are able to both read and write the leaf
nodes of the subtree.

B: For the T2 scenario clients 1 and 2 can read leaf nodes, client 3 can
both read and write leaf nodes.

C: For the T3 scenario client 1 can neither read nor write any leaf nodes,
client 2 can read leaf nodes, and client 3 can both read and write leaf
nodes.

Write is obviously only possible on actuator leaf nodes.

The proposal also contains the authorization level mechanism, which could
then be applied here. The clients could for example be assigned levels 1,
2, and 3.

In the A scenario it could then be possible that client 1 cannot read nor
write any leaf nodes of the subtree, client 2 can read and write a few leaf
nodes, and client 3 all leaf nodes of the subtree, assuming that the
subtree leaf nodes are “auth-level tagged” correspondingly.

A similar split up of the B scenario for what client1 and 2 can read could
also be realized.
BR
Ulf

-- 
Ulf Bjorkengren
*Geotab*
Senior Connectivity Strategist | Ph. D.
Mobile +45 53562142
Visit www.geotab.com