<scribe> scribenick: ted
<scribe> Scribe: Ted
Peter: I think Ulf has some updates to his proposal based on Isaac's model
Ulf: yes, my first proposal was
complete homebrew and not based on an established model
... Isaac proposed the RBAC model and looked into what he said
and read into it further
... it looks like a good idea and worked on it further
today
... not sure if Isaac has had time to look it over
Isaac: your update is pretty much
aligned with what I proposed
... what you have really makes sense
Ulf: the hierarchical model fits into the needs well
Ted suggests overview of RBAC
Isaac: the main advantage is you
assign an access restriction to a particular role
... there is another part where you assign roles to users. you
can assign one or more roles to a particular user and it
follows a hierarchy model
... a role can be higher in the hierarchy
... Ulf proposed simple numbers and comparison is easy
... another thing to take into account on RBAC model is
extensions to include more specificity and possibly
complexity
... you can have multiple roles active at the same time. it is
possible to avoid some complexity, follow the model to a
point
... you can assign permissions or access rights to particular
roles
Ulf: thank you
Gunnar: perhaps somewhere there
is middle ground, following android model with named
permissions
... RBAC is more theoretical with flexible addition and removal
of permissions
... android manifests have different permissions
... permission can be access to a group of signals
... this is typically listed in a manifest per application and
immutable
... up to discussion here whether it should be fixed or
dynamic
... signature is proof you have access as claimed
... permissions are compared to a given token
... it matches what has been discussed here but simplified
somewhat
Isaac: you are describing access
rights for an application. you can have hierarchy or finer
grained permission
... you have already encoded that explicitly in the data model
with Ulf's proposal
Adnan: where would the tagging happen?
Isaac: on the root node
... finer grained in the tree, possibly more restrictive
... deeper in tree may require a higher role
Ulf: read and write access is governed by role hierarchy
Gunnar: I do not immediately
agree on tree hierarchy in vspec should be used for access
control
... you could have a wildcard, eg everything below a node
without listing all the children can be accessed
... it might not be so sensitive to know make and model but in
that same branch is vin which is personal identifying
information
Ted: Ulf's proposal allows for granular under a branch
Adnan: we do not want to modify the data model for access control
Gunnar: not sure how I feel about numeric privileges as it is different than anything I am use to
Ted: proposal is to add access control metadata as VSS is being returned using layering which Gunnar will cover in next agendum
Adnan: not sure how much complexity we want in the implementation, you will not find something like this but more Oauth
Isaac: all file systems are
geared towards permissions on directories and files
... depends on which model you want to mimic
Adnan: we are talking about an
interface that can used by multiple clients
... Oauth has policies separate
MagnusF: I think you have to have the policies separate as it can vary by vehicle
Gunnar: somewhere the relationship is being added
Adnan: right, and not sure it belongs in the data being returned
Ulf: come up with a proposal for comparison
Adnan: I will do
Ted: I see value in communicating varying access control for a given app across different vehicles and for different users and conditions in same vehicle so app can change its behavior dynamically for the different situations
Gunnar: the general concept is to
use the same vspec model for adding additional metadata
... using Ulf's proosal as an example his tags can be added and
returned to the client
... this follows how some implementations may be behaving
already
MagnusF: that is correct
Gunnar: to Adnan's concern, yes
you are adding access control definition in the data
... for all of these you can use wildcards and not have to
treat every child node, repeating metadata
... VSS could allow definition of new ideas and concepts
... it would could use YAML to define different permission
groups
MagnusF: agree we do not want to
burden VSS too much
... you can specify your own data, sign it and provide the list
of credentials separate from VSS
Gunnar: that could be part of the
control
... it could vary from W3C spec, Android etc
Daniel: we are discussing
authorization as one use case, we have had others and
capability of private branches...
... we are using it internally to identify source within system
for the leaf
... grouping is inherent and can keep structure of VSS tree and
we can include in a deployment file
... you can map a certain number of signals onto tree
... concept extension as a private branch and additional
metadata per node
... you can have multiple feeds and corresponding vspec. we
have 1 metadata extension file for deployment
MagnusF: I would agree to
that
... development and deployment are very different
Gunnar: that is the basis of it,
to be able to add later as layers
... they could be privacy sensitivity or other metadata
... there is a need to add data after the fact
... question is whether to leverage this in defining the access
roles
https://github.com/GENIVI/vehicle_signal_specification/pull/137
MagnusF: we want to do branch
level authorization with more granular access per node and
there are a number of ways to do that
... when we add our own private branches there are reasons we
may need to have in multiple locations. I think the number
based system is a bit blunt
Ulf: elaborate please?
MagnusF: we may have proprietary
drivetrain information we want to expose via VSS
... I want to be able to hand out credential/certificate file
that gives access to two trees at same time, how can that be
handled with a number scheme?
Ulf: in the Gen2 spec where we
build on ViWi authorization, one auth server in the vehicle
another in the cloud
... you make request to cloud server for read/write access to
branch/specific nodes and if granted the token will contain
scope of permission
... it is signed and can be verified within the vehicle
... vehicle server will give the access token to Gen2
server
... that would be difficult to handle two trees
MagnusF: signed credential file as Gunnar described is similar
Gunnar: when access request goes to the first server, how does it figure out whether to grant it and how to encode it
Ulf: the number scheme is just a
role and model is hierarchical
... a third party app may get role 0 basic info only and role 9
full access
Gunnar: names can make more sense than numbers
Ulf: I think it is less flexible using numbers
Gunnar: I would disagree as there
is no limit to named roles
... MagnusF suggested two different branches, imagine clients
a, b, c and be able to spell out a numbered role that says
which a can get to in two branches
Ulf: mutual exclusivity for clients is an issue but don't see a use case
MagnusF: a vehicle owner can
access their own PII compared to a service shop that can access
full signal data but not PII
... that needs to be mapped to different access groups
Ulf: if that is the case we should not use hierarchical, fine with names or numbers
MagnusF: agree we need grouping
and open is whether we need hierachical
... what I am looking for is a more flexible way to handle
allows and denies
... there can be corresponding id numbers for role names
Gunnar: it is a model I see recurring in other systems and would be more familiar (to the developer)
Ulf: we can remove hierarchical
Daniel: back to layering, we switched back to authorization...
MagnusF: I like what Gunnar did
and agreeing with him which is worrying...
... some of that functionality is already built into to the
python tooling
Gunnar: I took a more formal approach to defining it, if it is already possible that is great
Daniel: private branches overwrites though
MagnusF: no, it merges and is in
effect a layer
... under a private branch you can also introduce additional
metadata
Daniel: how would you define those files and refer to them?
MagnusF: we have separate spec
files and part of our build system
... we need to look at Gunnar's powerpoint and at the very
least the formalization could be best practices
Daniel: we separate the metadata
from the actual specification
... we really just extend metadata and found it very handy to
do so
Ulf: I think it is important that there will be instantiation in the model
Ted: clearly layering is useful as it is being utilized already by JLR and BMW. Peter can you find out whether Volvo is doing similar?
Peter: we're not
... how does layering relate to Gen2?
Gunnar: we need to figure out the complete chain, how do you define what is needed for access control