W3C home > Mailing lists > Public > public-automotive@w3.org > January 2020

Gen2 access restrictions

From: Ulf Björkengren <ulf.bjorkengren@gmail.com>
Date: Thu, 16 Jan 2020 10:55:15 +0100
Message-ID: <CAJFd4zQDiCOqnPNV8PszoUcLGZYT8xT1bMWWxBcKipp+PgO72Q@mail.gmail.com>
To: public-automotive <public-automotive@w3.org>
Below is an attempt to formulate a requirement list for the Gen2 access
restrictions.

1. No restriction, read/write is allowed without any token validation.
2. Write-only restriction, write requests require valid token, read
requests without token validation.
3. Read-write restriction, both read and write requests require valid token.
4. Restriction can be applied to separate nodes, or to groups of nodes
(subtree).
5. Client authorization is provided for a group of nodes (subtree).
6. The general access to the tree for a client, with or without access
restrictions, can be limited to a subtree. This general access can be set
per client.

These requirements can be enforced by the following design.

Two new properties are added to the VSS2.0 model:
- "validate": "xxx" // where xxx can be either "write-only" or "read-write"
- "authLevel": X // where X is 0..9

Three fields are added to the Access token:
- "scp": "path" // where path is a valid VSS path
- "acs": "access" // where access is either "read-only" or "read-write"
- "authLev": Y // where Y is 0..9

The "validate" property can be set in branch nodes, or leaf nodes. In
branch nodes it leads to that it is inherited in all underlying nodes (may
be overridden by a "validate" in any of these nodes). A  node without
access restriction set, either through inheritance or explicitly, has no
access restriction.
The "authLevel" property follows the same inheritance rules as "validate",
with the difference that overriding is only possible with a higher value
than the inherited, and that a node without authorization level set through
inheritance or explicitly, is assigned the value 0.

With the described information a Gen2 server will then be able to enforce
the access restriction requirements 1 through 6 mentioned above.
Requirement 6 has the limitation that clients with higher authorization
levels can only be allowed to access a superset of what a client with a
lower level has access to, i.e. it will always have access to the parts
that clients with lower levels have.

Please comment if you think that the requirements 1-6 are incorrect, or
more reqs needs to be added, or if you see any flaws in the design.

BR
Ulf
Received on Thursday, 16 January 2020 09:55:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:06:15 UTC