Re: User centric access control model

So Ulf and others, Would it be possible in order to make progress to keep the description of the access control a bit general and not impose detailed description of RBAC roles ? Maybe then have one example like the one Magnus Feuer suggested - remotely accessing the door/trunk lock - on how we would recommend an implementation ?  So, keeping the access control description at one level and then just have an example of this in the spec. Perhaps also actually have an implementation and test of that example to refer to.

I know that it’s a balance between keeping the spec to open to interpretation and risking fragmentation. I just don’t see us making much progress right now.

Br
Peter Winzell

From: Ulf Bjorkengren <ulfbjorkengren@geotab.com>
Date: Monday, April 20, 2020 at 12:21 AM
To: public-automotive <public-automotive@w3.org>
Subject: User centric access control model
Resent-From: <public-automotive@w3.org>
Resent-Date: Monday, April 20, 2020 at 12:20 AM

In our last meeting in the access control discussion we focussed on the authentication step, and the different entities that could be involved in this step -  users, apps, devices, and maybe more.
I think Magnus G called this a potential rabbit hole, and I agree.
What about if we say that there must always be a user "at the backend" of all these use cases, other entities can act as proxies for this user under the condition that they can prove that?
So at the AGT server, when an entity makes a request for an Access Grant token, it either is a user, or another entity bringing proof of being a proxy for a user, e. g. a signed token containing user identity. This token has then been acquired earlier, by a here non-specified process.
In a model like this there are only "user-specific" RBAC roles as apps, devices, etc are all proxies for a user. Which has the benefit that it should simplify the definition of roles.
The proxy identity should also be in the credential they use to prove their trustworthiness, but they are not otherwise "challenged" to prove it. A verifier should be able to link back to the user through data in the token if there is a need for stronger verification.
I believe something like this could save us from the rabbit hole, and provide a security level that is on par with other parts of our access control model.

BR
Ulf

--
Ulf Bjorkengren
Geotab
Senior Connectivity Strategist | Ph. D.
Mobile
+45 53562142
Visit
www.geotab.com<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.geotab.com%2F&data=02%7C01%7Cpeter.winzell%40volvocars.com%7Cde70aea2659b4c08562608d7e4fb6376%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C637229640674314915&sdata=951%2FyT%2BtpOu56Kc%2BMsfoNzEtL%2FtR3NsEM%2F%2BDyWXdGMk%3D&reserved=0>