Access Control should be the responsibility of BOTH the Resource Server and the Identity Provider, depending on the situation

[jaxoncreed]

This is documenting an issue we discussed during today's panel meeting that I think should be highlighted.

Currently, access control is handled by the resource server by the acls. The trusted apps system currently uses the WebID to store apps access control. This is a poor implementation, but philosophically it could work.

The major insight is that "trusted apps" essentially is associating access control with the identity rather than the resource. For this use case, it makes sense to associate access control with an identity because it is essentially the user saying that an app that has been given permission to represent the identity is limited (it has nothing to do with the resource)

Access control could either exist within a token generated by the identity provider or could be in a special RDF document created by the identity provider.

I would also suggest that the identity provider should issue access control rules that look very similar to acls because we do not want to have multiple access control languages.

[elf-pavlik]

Access control could either exist within a token generated by the identity provider or could be in a special RDF document created by the identity provider.

We also discussed that some access control rules may stay specific to resources on specific RS. @zenomt mentioned privacy concern of exposing rules specific to one RS to another RS and I mentioned possibility of client asking User associated Resource Server (possibly same as IdP) for access token per specific RS which would only include (by reference or value) access rules relevant to any RS and that specific RS but no other specific RS.

[bblfish]

The key idea I got from the discussion is that the there are two roles in access control

1. The resource server: gives access to an App if it fits the requirements given by its wACLs
2. The Authentication App that can restrict what each app can do depending on user requirements. For example a user may want to use an app only to browser information but not to write anything, or perhaps where it can write to when authenticated.

[RubenVerborgh]

is associating access control with the identity rather than the resource.

(it has nothing to do with the resource)

I think it could be both actually, and that's what I also see from the above comments.

Based on an example from @timbl: "I trust my brother to see my photos, but not with that darn XXYYZZ app he was tricked into installing on his phone" (I don't care if that app reads todo lists though).

[elf-pavlik]

I trust my brother to see my photos, but not with that darn XXYYZZ app he was tricked into installing on his phone

I think we can make it technically possible that ACL would defer to each User's Authorization Server or some specific Authorization Server. I think it would be useful to document use cases for the second one. If User can choose their apps, they easily know which apps they can use. In case where they only can use some specific apps, we also need some way to communicate to them which apps they can use and which they can't.

[dmitrizagidulin]

"I trust my brother to see my photos, but not with that darn XXYYZZ app he was tricked into installing on his phone"

As mentioned in item 3 of the Attenuated App Authz discussion, it is not only socially (as well as UX-wise) awkward to restrict other people's app choices, but (much more importantly), in most cases it is impossible to authenticate other people's apps. Your own apps, yes. Authenticate other users, yes. But authenticate other users' apps? No.

[RubenVerborgh]

Awkwardness is a separate issue; we need to start by making it technically possible. The above was an important requirement and main reason why the trusted app issue was initiated.

GitHub/Twitter/Facebook can authenticate apps. We must be able to do that too.

[dmitrizagidulin]

@RubenVerborgh

The above was an important requirement and main reason why the trusted app issue was initiated.

I was under the impression that the trusted app issue was initiated to limit, for a given user, the access that user's own apps had in their data space. And emphatically not to limit other users' apps.

[dmitrizagidulin]

GitHub/Twitter/Facebook can authenticate apps. We must be able to do that too.

GitHub/Twitter/Facebook and the like are only dealing with a situation where there is a single IdP. (This essentially falls under the "authenticating your own apps" case.) Whenever there are multiple IdPs (the "authenticating other people's apps" case), it is not technically possible under any authentication method I have ever encountered.

[jaxoncreed]

Awkwardness is a separate issue; we need to start by making it technically possible.

I agree. I think that some kind of system like acl:origin (probably a modified version of acl:origin so that we can expand its use case beyond just web apps) should stay around to let the resource server dictate what apps can access a resource. Though, using it as the main method to control access for apps should be discouraged for the following reasons:

• There is no way to 100% authenticate that a request came from a certain app. It is always possible to spoof the token if the client and the auth server are in collusion or the device environment (web browser or mobile OS) is malicious.
• As Dmitri mentioned, it's awkward.
  Instead, acl:origin should only be used with things like extremely secure medical data. Everything else should use the Auth-server based access control system I outlined above.

I was under the impression that the trusted app issue was initiated to limit, for a given user, the access that user's own apps had in their data space. And emphatically not to limit other users' apps.

Unfortunately, that's not what was implemented. When NSS encounters acl:origin it looks at the WebID of those who have control access to see if it has a trusted app. I should have looked at the webID of the token owner.

[bblfish]

There is no way to 100% authenticate that a request came from a certain app. It is always possible to spoof the token if the client and the auth server are in collusion or the device environment (web browser or mobile OS) is malicious.

If the authenticated user fakes the Origin of the App - and there may be good reasons to do that - the user is then responsible for potential damage done by the App used.

[elf-pavlik]

I agree. I think that some kind of system like acl:origin (probably a modified version of acl:origin so that we can expand its use case beyond just web apps) should stay around to let the resource server dictate what apps can access a resource.

For me it sounds like putting to much responsibilities on the Resource Server, it may give cleaner separation of responsibilities if ACL for requested resource can stipulate either of:

• Each user can use Authorization Server associated with them (which has responsibility for delegating subset of their access to specific clients/apps)
• All users have to useAuthorization Server associated with this Resource Server, there they can delegate subset of their access to specific/apps clients with additional constrains enforced by this Authorization Server.

This way delegating access to clients/apps in both cases stays responsibility of Authorization Server and Resource Server only needs to make sure that it gets access token from Authorization Server according to ACL policy for that resource.