Re: User centric access control model

Hi All

I have tried to wrap my head around this proposal.

On Mon, 2020-04-20 at 09:20 +0200, Ulf Bjorkengren wrote:
> 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. 

This is in reference to the list of "identities" provided here:
https://www.w3.org/auto/wg/wiki/Access_use_cases
 
> I think Magnus G called this a potential rabbit hole, and I agree.

If you both agree then you must mean the same thing.  I would be helped
by a more clear statement here.  A rabbit hole usually
suggests something we should not go down because it will be an endless
discussion that does not lead anywhere, and would also not give any (or
enough) benefit?  

What is the endless discussion?  Is it to define *all* potential
identities?  First, I'm not saying we have to do that, or that we have
to get it 100% correct.  If no one comes up with anything more than
already listed, I think we can consider the list complete for our
purposes.

I believed the list was useful for  the discussion of access control to
talk about *what* should influence the access control.  And that would
include the identity (or "role" if you prefer), or apps that together
belong to a group identity, and so on.  But such a list could be
reduced by choosing only some (or only a single one as I think you did
below) and providing an example of how the access control procedure
executes using that example.  

>  
> What about if we say that there must always be a user "at the
> backend" of all these use cases, 

I don't understand what it means.  Does every use case have a user and
is it different for every use case?   What is the relationship between
a use case and an actual application?  Do multiple applications belong
to a "group" that maps to a use case?  Or is the relationship
different?

> other entities can act as proxies for this user under the condition
> that they can prove that? 

I wonder, is there a difference in the amount of access provided
between being a user and acting as a proxy for a user?

> So at the AGT server, when an entity makes a request for an Access
> Grant token, 

> it either is a user

a.k.a. "bringing a proof of BEING a user", do you agree?

> , or another entity bringing proof of being a proxy for a user,

repeating: "bringing proof of being a PROXY for a user"

Is there a difference between those proofs?

What I'm getting at is that this seems like a single thing only that is
controlling the access.  I only see one thing "user", or I don't
understand the difference.

I'm a little surprised by the idea of a single one because the previous
roles you described had aspects of app-type ("OEM app") as well as
active user ("Driver"), so there were at least two aspects involved in
that original proposal, would you agree?

> e. g. a signed token containing user identity. 

Agreed.  This seems the same though.

> This token has then been acquired earlier, by a here non-specified
> process. 

I'd like at least an example of that process to be outlined.  It might
not be part of the formal specification, but in order to understand
that what is being described will actually work in a real system.

> In a model like this there are only "user-specific" RBAC roles as
> apps, devices, etc are all proxies for a user. 

This is really a set of roles then?  Rather than an actual user
identity, or?   Would it not be equivalent to saying 
"bringing proof of having been assigned a role"?

> Which has the benefit that it should simplify the definition of
> roles. 

Would be great to understand the examples.

> The proxy identity should also be in the credential they use to prove
> their trustworthiness

I would rephrase, if you agree.  The "trustworthiness", or a bit more
specifically, what permissions it is allowed to have, or if we only
have roles, what roles it is allowed to have.  That is all known by the
AGT.   You prove your identity to the AGT rather than proving your
trustworthiness, or?

> , but they are not otherwise "challenged" to prove it. 

I'm not sure but maybe it is a reference to the challenge-response
proposal made by someone (Isaac?) in the last call?

So you are saying to make the proof by providing a signed
statement/document/file and not by an active challenge-response that
happens when the AGT is contacted?

> 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 don't follow this, sorry.  What is a verifier?  Stronger verification
how?  Isn't it the credentials that are given the only verification.  I
think more details needed here.

> 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. 

I don't mean to be annoying here.  But I don't really know what the
other parts of our access control model you refer to.  Aren't we
designing the access control model here and now?  More or less from
scratch, or am I wrong?

Best Regards,
- Gunnar

> 
> BR
> Ulf
>

Received on Tuesday, 21 April 2020 18:08:31 UTC