Re: User centric access control model

One thought. Would it not be good to just pick one use case from either Glenns list or Magnus F examples and apply proposal(s) to this. Once we have that we could work our way towards a more generic description which is suitable for the specification itself.

So, next week we could pick some use case from the list and work with that. (avoiding the rabbit hole )
Br
PW

From: "Winzell, Peter" <peter.winzell@volvocars.com>
Date: Tuesday, April 21, 2020 at 10:26 AM
To: Ulf Bjorkengren <ulfbjorkengren@geotab.com>, public-automotive <public-automotive@w3.org>
Subject: Re: User centric access control model
Resent-From: <public-automotive@w3.org>
Resent-Date: Tuesday, April 21, 2020 at 10:25 AM

Hi Ulf!

So do you mean that:

Devices, Apps,… -> “user proxy” < --- > authentication as USER to the AGT server. (i.e for the AGT server its always a “USER” which in the would reduce the number roles required ?)

“…by a here non-specified process…”
And do you mean that we should not define the user signature process for the “proxies” in this case ?

Br
Peter W


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%7Cc504f099c19547dd422d08d7e6191077%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C637230867636452219&sdata=h7L0Bm%2BMfWZ%2BL7lTEJZlja0DX7aUf6sZMwKsJha7wZk%3D&reserved=0>