Re: Gen2 access control model

Hi Isaac,

thanks for your input to the discussion.
I think it points to that we are in line with other examples, but with some
tweaks where needed.
Let us try to wrap it up soon, maybe in today's WG.

BR
Ulf

On Fri, Mar 6, 2020 at 6:16 PM Isaac Agudo Ruiz <isaac@lcc.uma.es> wrote:

> I have read both arguments and before going any deeper in the the
> discussion I agree we need to clarify the terminology. I am using as
> reference the paper "Role-Based Access Controls” by David F. Ferraiolo and
> D. Richard Kuhn from the National Institute of Standards and Technology of
> the United States (NIST)
>
>
> https://csrc.nist.gov/CSRC/media/Publications/conference-paper/1992/10/13/role-based-access-controls/documents/ferraiolo-kuhn-92.pdf
>
>
> In this document the also reference the definition of an access control
> model that resembles the first proposal by Ulf  based on level, i.e. *Mandatory
> Access Controls (MAC). * It is defined as a “… means of restricting
> access to objects based on the sensitivity (as represented by a label)
> of the information contained in the objects and the formal authorization
> (i.e. clearance) of subjects to access information of such sensitivity.”
>
> The purpose of RBAC is to "provide a means of naming and describing
> many-to-many relationships between individuals and rights”.
>
> "A role can be thought of as a set of transactions that a user or set of
> users can perform within the context of an organization.”. In the paper
> Transaction is defined as a "transformation procedure, plus a set of data
> items accessed by the transformation procedure”, in our case I understand
> that transformation procedure could either be READ or WRITE and the data
> items are the NODES in the tree.
>
> Main advantage of RBAC is that it simplifies management of access rights
> but only under the assumption that "Once the transactions of a Role are
> established within a system, these transactions tend to remain relatively
> constant or change slowly over time.”
>
> There are many other papers by the same authors or by Ravi Shadu (e.g.
> https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf)
> that elaborate on the same concepts and definitions.
>
> Regarding Gunnar concerns about who is the subject in our case and the
> focus of RBAC on persons and not app, I tend to think Roles can be assigned
> to anything, that doesn’t mean we are not using RBAC, even if the
> literature RBAC is mostly about people.
>
> Subject is defined as “An active entity, generally in the form of a
> person, process, or device, that causes information to flow among objects
> or changes the system state” (
> https://www.profsandhu.com/journals/computer/i94rbac(org).pdf)
>
> For example, kubernetes implementation of RBAC can bind roles to subjects
> or service accounts.
> https://kubernetes.io/docs/reference/access-authn-authz/rbac/
> According to their documentation "User accounts are for humans. Service
> accounts are for processes, which run in pods.” Anyway, in our case I think
> we should define an authorization model that works for both humans and
> machines.
>
> The relevant questions to answer would be then:
>
> 1) Are there clusters of transactions that tend to remain relatively
> constant or change slowly over time?
>
> 2) Can/Should we assign all required transactions to apps or individuals
> by using only this clusters instead of individual transactions?
>
> I would say yes to both, but you are the experts in the area and the
> creators of the specification.
>
> Whether we call them Roles, "Group of Transactions” or chose another term
> makes no difference, at least not to me.
>
> Regarding the example provide by Gunnar:
>
> APermissionName:
>  - Vehicle.Path.Example.Branchname.* : read_only
>  - Vehicle.Another.Path.Leafnode : write_only
>  - Vehicle.Path.Example.Branchname.Special : no_access
>
> From my perspective, this is the definition of a Role, as a group of
> transactions with the addition to incorporate negative authorization (
> https://www.profsandhu.com/confrnc/acsac/acsac04mohammad.pdf).
>
> I think negative authorization can be confusing and may not play well with
> hierarchies but that is just my opinion and I am not strongly opposing to
> support them. This is supported for example in Azure:
> https://docs.microsoft.com/en-us/azure/role-based-access-control/overview
>
> Agree with Gunnar in not reinventing the wheel, maybe we should look at
> how other projects implement RBAC, e.g. kubernetes, Azure, SeLinux, Auth0,
> etc.
>
> In particular, the example from Auth0 seems very illustrative:
> https://auth0.com/docs/authorization/concepts/sample-use-cases-rbac
>
>
> ***
> 1) Permission-based model
> -------------------------
>
> This in my view has 2 concepts which translates to 2 "levels" of
> flexibility
>
> 1. Each Subject is given one or many permissions.
> 2. Each Permission has a definition of which data/API/service it gives
> access to.
>
> The holder of a permission has the ability to make the corresponding
> actions successfully.
>
> ***
>
> According to my understanding, that is the essence of the RBAC model, just
> replace Permission by Role.
>
>
> ***
> 1) *ROLE*-based model
> -------------------------
>
> 1. Each Subject is given one or many *ROLES*.
> 2. Each *ROLE* has a definition of which data/API/service it gives
> access to.
>
> The holder of a *ROLE* has the ability to make the corresponding
> actions successfully.
>
> ***
>
> Roles can be hierarchically related, one role can inherit all transactions
> from other parent role. This adds complexity and we may not need it but I
> think it fits Gunnar concepts. An example of hierarchy:
>
> Consider the following Role definitions:
>
> CombustionEngineApp:
>  - Vehicle.Engine.Temperature.* : read_only
>  - Vehicle.Engine.OilLevel : write_only
>  - Vehicle.Engine.Turbo.* : read_write
>
> ElectricEngineApp:
>  - Vehicle.Batery.* : read_only
>  - Vehicle.Engine.Voltage : write_only
>
> EngineApp inherits from CombustionEngineApp
> EngineApp inherits from ElectricEngineApp
>
> We could represent that as following:
>
> EngineApp:
>  - CombustionEngineApp
>  - ElectricEngineApp
>
> Other example could be:
>
> RepairShopApp inherits from EngineApp
>
> Using Roles and relations between then can help implement different
> granularity levels.
>
> Regarding Tokens, from my understanding Access Grant Tokens (AGT) should
> include roles as they are the tokens granting permissions. When the
> app/user need to execute a transaction it ask for an AT for this
> transaction using its AGT. Access Token (AT) shouldn’t include roles, just
> the transaction they were issued for.
>
>
>
> El 5 mar 2020, a las 16:21, Ulf Bjorkengren <ulfbjorkengren@geotab.com>
> escribió:
>
> It seems to me that our main difference in view is whether it shall be
> possible to assign names to groups of node(s), or not.
> Your argument 1) of the three you provide I agree with, so if that is seen
> as sufficient for introducing this extra level, it is fine with me.
>
> The list of roles in the slide deck was just an attempt to get a first
> understanding, it was not meant to be The list.
> It definitely needs more work.
>
> BR
> Ulf
>
> On Thu, Mar 5, 2020 at 3:14 PM Gunnar Andersson <gandersson@genivi.org>
> wrote:
>
>> On Wed, 2020-03-04 at 15:12 +0100, Ulf Bjorkengren wrote:
>> > See my comments inline.
>> > BR
>> > Ulf
>> >
>> > On Tue, Mar 3, 2020 at 9:55 PM Gunnar Andersson <
>> > gandersson@genivi.org> wrote:
>> > > As discussed on the call, here are my thoughts around this.  I hope
>> > > I
>> > > covered most of it.
>> > >
>> > >
>> > > General discussion
>> > > ------------------
>> > >
>> > > In addition to the concrete proposals we really ought to consider
>> > > the
>> > > primary model here:
>> > >
>> > > A) Mandatory access control
>> > > i.e. unless permissions were assigned, there is no access.
>> > >
>> > > B) Something else
>> > >
>> > > A) is almost always the standard approach for anything security-
>> > > related!  (As others have noted there is still the opportunity in
>> > > such
>> > > a model to define some kind of "superuser" permission, and give
>> > > that out to those that should have it.  So it really does not
>> > > restrict anyone from making a very open and non-restricted access,
>> > > if that is so desired).
>> >
>> > Ulf: I would say that my concept with access control tagging is of
>> > type A). Every node that is tagged require a valid token for access
>> > to be granted.
>>
>> Yes, I think it is.
>>
>> > Instead of saying that every node in the VSS tree MUST be access
>> > controlled, it gives the freedom to decide on which nodes that shall
>> > be access controlled, and which not.
>> > If we believe that ALL nodes, also in future versions of VSS, MUST be
>> > access controlled, then access control tagging becomes unnecessary.
>>
>> I thought the question boiled down to if it is worth adding the extra
>> work of adding the "access control tagging" to the database, if most or
>> all of them will anyway.  But since I have now understood you can put
>> this node at the root, or some top level branch then it's not too bad.
>>
>> It might still be easiest to just assume access control to everything,
>> though.
>>
>> > > Definitions (common):
>> > > --------------------
>> > >
>> > > Permission = the allowance to access a particular data or API or
>> > > service.
>> > >
>> > > Note - in order to define mappings, and the defined access, each
>> > > Permission must also have a unique name.
>> > >
>> > > Role = It has a name.  ..and it means what?
>> > >
>> > > We must discuss the definition we want.
>> > > - In Ulf's proposal there is a list of app types (e.g. off-board
>> > > app)
>> > >   but also human type/roles (e.g. driver).
>> > >
>> > > - In Wikipedia RBAC it is described:
>> > >   "Job function or title which defines an authority level"
>> >
>> > Ulf: modify this to: "Function or title which defines an authority
>> > level", and I think it can be used to describe the scenario with both
>> > human and non-human roles.
>>
>> I think that works.  My purpose with this section is primarily to
>> provide information, so we all deal with the same understanding and
>> we can derive the right solution.
>> I am just noting that the group seems attached to the RBAC model now,
>> and in that case it should not be going too far from the standard
>> understanding, to avoid confusion.  Otherwise it's better not to claim
>> that it is RBAC.
>>
>> But I agree with your definition - it is not too big of a change.
>>
>> > > Subject = who or whatever is accessing.  Is the subject an app, or
>> > > a
>> > > person, or the computer identity that sends the request (like an
>> > > ECU)...  I think at least some details of the authentication
>> > > protocol *are* necessary to define, if the specified model is going
>> > > to provide value.
>> >
>> > Ulf: I think there can be some non-normative best practise
>> > description, but the details should be left to implementations.
>>
>> This might be true in the end but it won't be enough to just say
>> that.  We of course need to write this down so we have agreement on it.
>> With details I meant how does an actor/client identify itself.
>> What is its identity...  I think that's important to understand what
>> the Subject is, and to see that the total concept holds together...
>>
>> > > (Further down a more flexible idea to cover more than one aspect)
>>
>> ... yes detail follow further down
>>
>> > >
>> > >
>> > > 1) Permission-based model
>> > > -------------------------
>> > >
>> > > This in my view has 2 concepts which translates to 2 "levels" of
>> > > flexibility
>> > >
>> > > 1. Each Subject is given one or many permissions.
>> > > 2. Each Permission has a definition of which data/API/service it
>> > > gives
>> > > access to.
>> > >
>> > > The holder of a permission has the ability to make the
>> > > corresponding
>> > > actions successfully.
>> > >
>> > >
>> > > 2) Role-based model
>> > > ---------------------
>> > >
>> > > This has 3 concepts which translatest to 3 "levels" of flexibility
>> > >
>> > > 1. Each Subject can be given a Role.  (is it one or many?)
>> > > 2. Each Roles is given one or many permissions. (many, in my view)
>> > > 3. Permission is defined the same as in 1)
>> > >
>> > >
>> > > 3) First slide deck proposal
>> > >
>> > > This states that it is Role-based but has in my view only 2 levels
>> > > actually defined.
>> >
>> > Ulf: I do not agree.
>> > 1. This is handled by the client-AGT server negotiation. Regarding
>> > one-or-many, a client can do multiple request to the AGT server, with
>> > different roles, and obtain multiple AGTs for the different roles. As
>> > an example.
>>
>> I think you are here simply agreeing that each Subject can have
>> multiple Roles, right?  So on point 1, no actual disagreement, or?
>>
>> > 2. If we name every row in the "RoleXPermission" table a Permission,
>> > then 2. is fulfilled.
>>
>> I thought the entire "RoleXPermission" definition, with all its rows
>> was the Permission, because the name suggests this, but yes the
>> individual rows could be seen as the actual permissions.  As we can see
>> below my proposal is only slightly different, where rather a "group of
>> rows" would mean one instance of Permission
>> and it's a concept that is made visible.
>>
>> Again, it seems you are agreeing with the proposed concept and that's
>> the purpose of this statement?
>>
>> > 3. Seeing every row, or groups of rows, in the  "RoleXPermission"
>> > table as a Permission, 3. is also fulfilled.
>>
>> Indeed you can "see" it that way. In fact I also saw it that way. What
>> I'm reacting to is that the definition is directly tied to RoleX.
>>
>> Overall I think you are basically saying here, that it is *possible* to
>> assign any access control setup using the model you described.
>> I don't disagree with that.  I'm not here to only criticize the
>> proposal (and you should not come to the conversation to only defend
>> it, I hope).
>>
>> You can encode all permissions this way.  But you could also remove
>> most of it, remove the concept of roles altogether and just directly
>> connect every individual Application Identity to a list of signals it
>> can access, and say "is fulfilled".  So if that's the argument that it
>> is *possible* to get the same behavior, that's not the level of
>> discussion I am having.
>>
>> We are discussing a kind of Model for defining permissions here.  So I
>> think the model matters, and I'd like us to bring forward the different
>> approaches and compare them.
>>
>> What I'm saying might be a small thing but isn't it easier that you say
>> if you understand the difference or not?   There is a difference
>> between tying the role directly to one specific permission (or set of
>> permissions if you have a different definition), compared to making the
>> Role to Permission mapping in a separate table.  Maybe if you look at
>> it this way - a particular permission definition (i.e. the whole group
>> of signal path rows) could be reusable by another role, by *referring*
>> to it by name.  This is different from making a *copy* of the rows into
>> another RoleYPermission.  This is the only difference, and it comes
>> only by giving the permission lines a name.
>>
>> You have looked at the example at the end, I guess.  You must see that
>> there is an extra level.  Whether you agree it is needed, is another
>> separate matter.  In the example there is an extra mapping table, the
>> one that maps Role name to a list of permission names!
>>
>> > > As I can interpret it Role-based allows a third
>> > > level of hierarchy and flexibility.  One level is currently missing
>> > > because there appears a one-to-one mapping between Role and
>> > > Permission
>> > > in the slide deck.  It basically jumps from Role->list of
>> > > operations
>> > > instead of Role -> Permissions -> List of operations.
>> > >
>> > > To answer the questions, the Wikipedia article on RBAC at least
>> > > outlines this as FULLY flexible:
>> > >
>> > > "   A subject can have multiple roles.
>> > >     A role can have multiple subjects.
>> > >     A role can have many permissions.
>> > >     A permission can be assigned to many roles.
>> > >     An operation can be assigned to many permissions.
>> > >     A permission can be assigned to many operations.
>> > > "
>> >
>> > Ulf: I cannot see that the slide deck presentation cannot support all
>> > of the above.
>>
>> If I view the slide deck I don't think it clarified that each concept
>> can be tied to multiple other concepts.  It did not say it couldn't but
>> it did not say it could either.
>>
>> I want to say that my intention is not primarily to say that your
>> proposal can or cannot support things.  I'm rather seeking consensus,
>> and common understanding, so it would help if you also add a note at
>> the points where we have agreement, and not only on the disagreements.
>>
>> Then on the specific difference point again:  If you call a permission
>> "RoleXPermission" it seems to suggest this permission is only tied to
>> RoleX.  It cannot reasonably be used by RoleY without confusion.  Thus
>> I would see it as breaking the rule "a permission can be assigned to
>> many roles".  (Unless you consider a *copy* of the defining rows, which
>> I do not think is what is intended by the statement).
>>
>> > I might might misinterpret "operation" though.
>>
>> We should add it to the definition list maybe.  One proposal from me is
>> that Operation is what I in the definition called "to access a
>> particular data or API or service."  For VSS data access it would be
>> the operation of reading or writing a particular signal.
>>
>> > > I do feel "Role" does not fit as well to the technical actors
>> > > (subjects) we have, as it would to a human one.  But let's see
>> > > where we end up.
>> > >
>> > >
>> > > Furthermore in the case of VSS, I think each Permission should
>> > > translate, not to a single signal, but to a group of signals (that
>> > > can be defined using wildcards) _and_ it must also of course
>> > > specify read or write.
>> > > This is what "RoleXPermission" definition does in the slide deck,
>> > > except that as noted, the words "RoleX" might not be in the name -
>> > > there should not be a tight connection between Role and only a
>> > > single
>> > > permission.
>> >
>> > Ulf:  As the  "RoleXPermission" table may contain any number of rows,
>> > where each row, or groups of rows could be given Permission names, it
>> > is logically equivalent.
>>
>> Yes!  Now you have introduced the idea of giving each permission a
>> name.   That is the actual difference, because it enables the
>> possibility to refer to the definition by its name, instead of writing
>> the same definition again in a different place.
>>
>> But I feel you are going about all this in a little strange way, trying
>> to bend your own proposal just to say that it is more or less perfect
>> as it is written because it is more or less the same, rather than
>> simply seeking agreement on what the differences are, even if they are
>> small?   I have no problem at all agreeing that it is "kind of the
>> same".  But then it's about revising the details.
>>
>> > > The exact way to describe permission-to-signal access mapping can
>> > > be tweaked -- an example at the end.
>> > >
>> > >
>> > > First reflection on the slide deck "W3C Gen2 accesss control model"
>> > > ------------------------------------------------------------------
>> > >
>> > > The name "RoleXPermission" appears to be "equating" role and
>> > > permission.  I say they are "equal" there because it defines one
>> > > role
>> > > always has one permission and the permission name is even including
>> > > the
>> > > role name "RoleX".
>> >
>> > Ulf: It is a naming game here, see my previous comment.
>>
>> It's not a game really.  It's the direct reaction to your proposal.
>> If you think it can be tweaked to match the differences I highlight
>> then that's fine.   I've explained why the *name* was suggesting that
>> you had made a one-to-one mapping, a direct mapping from role to a set
>> of signal access capabilities.  If you did not mean to suggest that,
>> then let's propose a new example using fitting names.
>>
>> > What is the value in assigning Permission names to single, or groups
>> > of nodes?
>>
>> I'm only seeking to get consensus first, on that this is a different
>> model than the one you proposed.   We can then further discuss its
>> merits.  You seemed to first argue against it being different in the
>> first place, and now you seem to argue against it being useful.
>>
>> I'm more of a step by step guy I suppose.  Do we agree on it being
>> different?   Are we now ready to put these two approaches against each
>> other and evaluate which one fits best?
>>
>> Anyway, 3 answers I might give to "what is the value in naming the
>> permissions" are the following.  It's possible that they are not
>> convincing enough, of course.
>>
>> 1). It provides another level of modeling flexibility. Specifically the
>> "one more level" allows a named permission to be reused for multiple
>> Roles.
>>
>> Example:
>> Let's say both the role of Driver and the role of an "OEM" controlled
>> app should be able to READ but not write information about the car's
>> model, make and year, a group we might call "Vehicle Type Information".
>>    In such a case you can define *once* what signals should be included
>> in the idea of "Read Vehicle Type Information" (which is a Permission
>> object in the model), and when you then assign this to more than one
>> Role, you can reuse that definition by its name, instead of copying the
>> lines of signal paths.
>>
>> This might seem like a small thing, but I hope now finally we can at
>> least see that it's a different modeling capability!
>>
>> Now, I take a step back, and I think I understand why we are not fully
>> understanding each other. I am, as I noted further down, more in the
>> mindset that individual apps must be given access to a minimal set of
>> signals they need.  I understand that you don't see a major need for
>> this extra level if we are in the mindset where permissions are only
>> assigned to Roles and that we only have about 10-15 different roles
>> like proposed so far.  Then the roles are so few that a more capable
>> "meta-model" for modeling this might indeed seem to be not necessary.
>> Since we likely disagree on the fundamentals, it becomes harder to
>> understand the rationale.
>>
>> 2) The named permission, as you noted, would be a group of nodes.  It
>> is therefore part of a fine-grained permission model.  It allows
>> specifying access using those groups and I feel it's the right level of
>> detail to work with.  It is not as fine-grained as individual signals,
>> but it is also not a coarse model.  Being able to work with the
>> permission objects (which is done by referring to them by name) feels
>> like the right level.
>>
>> 3) I think grouping together "Operations" into a *named* Permission
>> mimics other access control methods for APIs and systems in general,
>> including for example the Android Apps permission model.  Those models
>> are however a bit different since they do not focus on "Roles" but more
>> on grouping Operations together into Permissions, and then assigning
>> each individual app ID a set of such permissions.  It is basically
>> what I called the "Permission-based model" early in the email.
>>
>>
>> > To name all possible permutations of sets of nodes becomes quite a
>> > task.
>>
>> It's not all possible permutations.
>>
>> And in my mindset again, there's a significant work to be done to model
>> an access control setup by deciding on the right groups of signals to
>> include in each group anyway.  I think that's the most difficult task,
>> as opposed to naming, but both things would be needed.
>>
>> As said above, I think we're envisioning the work differently.  I find
>> this grouping work necessary and expect it would be probably 50-100
>> permission groups in a future fully populated VSS, whereas you might
>> envision only defining the access for 10-20 different Roles.
>>
>> > > Thus both "concepts" are not really needed.
>> > >  - Each one role has only one permission.  RoleX is tied to
>> > >  RoleXPermission, and to no other permissions.  Therefore "Role"
>> > > and "Permission" become equal concepts.  It is a one-to-one
>> > > mapping, not a one-to-many or many-to-one mapping.
>> > >
>> > > It define directly the signal paths that role is allowed to
>> > > access.  In my view, this skips a step.
>> > >
>> > > The RBAC focus feels a little bit suspect to begin with since it
>> > > seems to be derived originally from humans as the subjects.  Humans
>> > > can be assigned a role, kind of like their job title.  This in turn
>> > > is then translated to a number of permissions required to do that
>> > > job.
>> >
>> > Ulf: The wiki RBAC description with only humans as subjects do not
>> > match our scenario. But I cannot see why it should not be possible to
>> > extend it to non-human subjects.
>>
>> Agreed, again.  If we don't go too far off...
>> Because if we go too far we should stop saying that it is RBAC and just
>> accept that it is something independently made up.
>>
>> > > But after our discussion I do understand the desire to define the
>> > > "roles", as they are defined as the role of a driver/owner/OEM and
>> > > other.  I think it might not be enough however.   But when
>> > > combining
>> > > the role and some other identity of the application (which is also
>> > > tied
>> > > to a set of permissions) then possibly it is both enough and
>> > > flexible.
>> > >
>> > > Role and app-identity might be orthogonal concepts.
>> > >
>> > > Consider SELinux for example, which has actor, subject, operation
>> > > and
>> > > "security context" - in other words many orthogonal concepts, and
>> > > it is
>> > > only the right combination of them all that gives access granted.
>> > > This is how a tight security model is set up.
>> > >
>> > > If we are fixed on the RBAC model, we can try that. In  my view, it
>> > > must first separate Role from Permission(s), and finally the
>> > > Service/Data/API that the permission gives access to.
>> > >
>> > > Example reusing Ulf's syntax for simplicity(*):
>> > > (*) Nitpick on that , it seems to use JSON-like definitions with
>> > > quotes.  I'd rather it be YAML for similarity with VSS...
>> > >
>> > >
>> > > Permission_VehicleTypeInfo:
>> > >   "path" : "Vehicle.Data.Path.Example.Branchname.*", "access" :
>> > > "read"
>> > >   "path" : "Vehicle.Another.Path.Example", "access" : "read/write"
>> > >
>> > > Then, notice this difference.  Roles should be tied to any named
>> > > permission and not directly to the signal access.  For example:
>> > >
>> > > Role_ThirdPartyExternalApp:    (  ... has several permissions ))
>> > >      - Permission_VehicleTypeInfo
>> > >      - Permission_VehicleMovementInfo
>> > >      - Permission_VehiclePositionInfo
>> > >
>> > >
>> > > Role_OEMApp:
>> > >      - Permission_X
>> > >      - Permission_Y
>> > >      - Permission_Z
>> > >
>> >
>> > Ulf: Again, by assigning Permission names to rows, group of rows, in
>> > the  "RoleXPermission" table, in my view it becomes logically
>> > equivalent.
>>
>> Mostly covered above.  Both that you are here introducing the exact
>> change I'm actually proposing, to name the permission rows, and the
>> agreement that it is equivalent in the meaning that it is possible to
>> encode the same behavior.  We're in this part of the thread primarily
>> discussing the syntax and semantics of different ways to make that
>> description.
>>
>> > Unless there is some other value in having named Permissions, not
>> > mentioned here?
>> > > In the slide deck the described roles are a mix of app/client
>> > > identity (third party) and user identity (driver, car owner, etc).
>> > > This seems to me they are almost similar to the idea of multiple
>> > > orthogonal concepts.
>> > > I have explained the consequences enough above I think, so I won't
>> > > repeat.
>> > > If we assume the slide deck allows multiple roles it leads to the
>> > > thought that an attempted access might be described as follows:
>> > >
>> > > - A third_party app access that is executed within the "car owner"
>> > > context, and requesting a particular signal.   Is that allowed?
>> > >
>> > > Ultimately however, I'm also in the camp of "third party app" not
>> > > being enough of an identity, but that it must be a specific app
>> > > identity. In other words, every single app should have specific,
>> > > limited permissions.  (The Least possible privilege principle)
>> >
>> > Ulf: I agree that  "third party app" might not be granular enough. It
>> > can very well be split up in several roles.
>>
>> I think the Roles could be useful, but still do not believe splitting
>> it into a few roles is enough.  The ultimate usage where access can be
>> given to third party application development requires, in my view, some
>> possibility to also assign individual permissions to each application.
>>
>> One thing is, there are so many different types of applications that
>> grouping them into different kinds of applications and then creating a
>> "Role" for each application kind would not be enough, I believe.
>>
>> The last part of the email below is not a complete proposal but was
>> opening up the idea to have more than one critera at the same time
>> to work around this.
>>
>> E.g.
>> - Role and App Identity decides what you can do
>>
>> or 3 critera like this:
>>
>> - App-type (OEM or third party etc),
>>   User (driver, owner, etc.), and
>>   App Identity (each app's individual ID)
>>   ...all together decides what you can do.
>>
>> > > But we can likely handle that. Since there is at least two-step
>> > > process this need not be too complicated. The combination of Access
>> > > Grant Token and Access Token may encode these things in a way that
>> > > all those aspects are covered.
>> > >
>> > > Think for example (and this might not be 100% correct) if the AGT
>> > > is granted based on proving your application identity, and
>> > > requesting a set of roles for it.
>> > >
>> > > Then, the AT might be granted based on proving you have the needed
>> > > role (proven by providing the AGT) and request a set of
>> > > permissions.
>> > >
>> > > Finally, signal access is accompanied by the AT, which proves that
>> > > you have the permission.
>>
>> As noted before, I'd like us to define the details of how this is
>> supposed to work at least on the level I wrote here above.  If you
>> think it should be different, we should look at an example.
>>
>> > > But I'd rather not stumble around in the dark too much here.  I
>> > > feel the best design for similar systems should really "exist"
>> > > already.
>> > > A key point for this work is to reuse best practices.
>> > >
>> > > - Gunnar
>> > >
>> > >
>> > > --------------------------------------------------------
>> > > "APPENDIX":
>> > >
>> > > Here is just a detailed permissions mapping possibility (Adnan
>> > > mentioned a flexible way which I think is something similar to
>> > > this).
>> > >
>> > > APermissionName:
>> > >   - Vehicle.Path.Example.Branchname.* : read_only
>> > >   - Vehicle.Another.Path.Leafnode : write_only
>> > >   - Vehicle.Path.Example.Branchname.Special : no_access
>> >
>> > Ulf: I cannot see the value in the no_access declaration. Removing it
>> > from  APermissionName gives the same effect?
>>
>> No, because the third row "overrides" the first one.  Look at the
>> paths where "Special" is a subnode of the branch and thus covered
>> both by the wildcard and the third line.
>>
>> > > Notice that this idea introduces the ability to say - "Read access
>> > > to ALL the nodes below Vehicle.Path.Example.Branchname, EXCEPT
>> > > Vehicle.Path.Example.Branchname.Special, which shall have no
>> > > access.
>>
>> ^^  It is explained here.
>>
>> > > In other words it is the ability to combine whitelisting and
>> > > blacklisting in the same definition, with wildcards.
>> > >
>> > > I would propose this ability is very useful.  Since the lines
>> > > overlap
>> > > the MOST RESTRICTIVE definition shall prevail.   Therefore if we go
>> > > this way it I think it also presumes a restrictive access control
>> > > model, where no access is given to anything that is not mentioned
>> > > in any of the held permissions.
>> >
>> > Ulf: Which is what the slide deck model also provides.
>>
>> If you were referring to only the last sentence, then agreed.
>>
>> > The access tagging concept is complementary, and independent, to the
>> > access control model.
>> > If used, then IF the ALL nodes in the tree shall be under access
>> > control, one line of metadata must be included in the root node.
>>
>> Understood, one line is not a big deal.  The other option is to just
>> make it mandatory and model up a kind of "super permission" that you
>> assign instead, agreed?
>>
>> > > Do you agree?
>> > >
>> > >
>> > > --
>> > > Gunnar Andersson <gandersson@genivi.org>
>> > > Development Lead
>> > > GENIVI Alliance
>> > >
>> > >
>> > >
>> > >
>> > > On Fri, 2020-02-28 at 17:31 +0100, Ulf Bjorkengren wrote:
>> > > > Attached is my proposal for Gen2 access control model.
>> > > > I hope we can discuss it on next WG.
>> > > >
>> > > > BR
>> > > > Ulf
>> > > >
>> > >
>> >
>> >
>>
>>
>>
>
> --
> Ulf Bjorkengren
> *Geotab*
> Senior Connectivity Strategist | Ph. D.
> Mobile +45 53562142
> Visit www.geotab.com
>
>
>
>
>

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