Distinct authorizations for instances of the same client running on different devices about authorization-panel HOT 11 OPEN

We should make sure to distinguish between two aspects:

1. how to express such constraints
2. how to enforce them

Whereas languages such as OWL (or SHACL for that matter) offer expressive power, we should ensure that the complexity of determining compliance is thus not too hard.

from authorization-panel.

What do you think are practical use cases for this functionality? At the moment I can't think of any, but I would love to hear.

from authorization-panel.

I think we need to keep track of different instances of the client running on different devices anyways (especially for native apps). Person may install same native app on two different devices and want the same set of authorizations to apply to both (all) of those instances. I think most UIs would provide it as default option. At the same time already having distinction between instances of the same client running on different devices, UIs could provide 'advanced' options to only apply authorizations to the instance of the client on the device currently used. I could imagine that some cases where I might want to give broader access to app running on desktop machine always located at home or in the office, and narrower access to app running on mobile device I carry around in my pocket (I have not experience with newer wearable devices).

Again, I think we need to have distinct per device instance of the the client anyways, in that case we just need to record in authorization if it applies to specific instance of the client, selection of instances with redirect_ur or all instances of the client with given redirect_url. First two would probably only differ in UI, so we would only have:

• user delegates specific access to the specific instance of the client
• user delegates specific access to all instances of the client with specific redirect_uri

We should dive further in Device Code and Client Credential Grants, where we don't have convenience of redirect_url. Possibly we may need more general 'client group' which could get defined by some redirect_uri or manually managed as simple list of client instances.

EDIT: I think owl:Restriction approach suggested during one of past meetings could also allow to define group as 'all members which have specific redirect_url'.
https://github.com/solid/authorization-and-access-control-panel/blob/master/meetings/2019-10-09.md#tags-vs-token-embedding

<#FooClients> a owl:Class;
  owl:equivalentClass [
    a owl:Restriction ;
    owl:onProperty oauth:redirect_uri ;
    owl:hasValue <https://foo.example/auth> .
  ] .

from authorization-panel.

related issue: https://github.com/solid/specification/issues/92

from authorization-panel.

Okay, I could see separate settings for each device as being useful. Though we want to be careful to make sure that it's not confusing for users.

from authorization-panel.

I think this granularity would not be available for solid clients implemented as confidential client style web applications. In that case all devices, and actually all users delegate access to the same shared instance of solid client.

from authorization-panel.

EDIT: I think owl:Restriction approach suggested during one of past meetings could also allow to define group as 'all members which have specific redirect_url'.
https://github.com/solid/authorization-and-access-control-panel/blob/master/meetings/2019-10-09.md#tags-vs-token-embedding

<#FooClients> a owl:Class;
  owl:equivalentClass [
    a owl:Restriction ;
    owl:onProperty oauth:redirect_uri ;
    owl:hasValue <https://foo.example/auth> .
  ] .

fwiw, one possible representation in SHACL ->

oauth:FooClientsShape a sh:NodeShape ;
  sh:targetClass oauth:FooClients ;
  sh:property [
    sh:path oauth:redirect_uri ;
    sh:hasValue <https://foo.example/auth> 	
  ] .

oauth:Bob a oauth:FooClients . # will fail

oauth:Alice a oauth:FooClients ; # will pass
  oauth:redirect_uri <https://foo.example/auth> .

from authorization-panel.

Not authorization specific, but in Google Maps we can find example of keeping track of different instances on different devices (Send to your phone feature)

Since we plan to require DPoP, we could reliably use public key used by the client instance to indirectly identify the client. To define groups of clients in many cases we should be able to rely on redirect_uri but we should specify group definition flexible enough to support clients which for example use device code flow.

from authorization-panel.

Okay, I can see the need for this functionality. The main question now is how we represent that in the token and what affect it has for a Pod.

I would say that it shouldn't have any practical affect on a Pod. Perhaps there could be an obscure acl rule that uses it, but for the most part, it should completely depend on the application's unique identity rather than the application instance's unique identity

In terms of representing it, we could distinguish by DPoP public key, but that doesn't tell a developer that this is a Samsung Galaxy X in firefox mobile. So, we'll need to put more thought into how to embed that into the token.

from authorization-panel.

i'm still not sure i understand the concern motivating this requirement. is the concern that

1. a portable/mobile device could be lost or stolen, and an adversary could gain access to it and to all of your data via the installed & logged-in apps on it;
2. one could be using a compromised device/computer/terminal (public or private), so an adversary could use my current session(s) on the device to access my data; or
3. other?

i think that any "advanced/expert" permission mode to manage per-device app permissions will be beyond all ordinary users, and probably most advanced users, and is unlikely to be used (or used effectively).

for case (1), if your device was lost or stolen, your OP should support "log out a particular other session" or at least "log out all sessions". that combined with relatively short token lifetimes should limit the exposure for this case. also, since it's 2020, any losable or take-able device should be strongly encrypted and locked.

for case (2), doing anything sensitive on a public (or otherwise non-trustworthy) terminal is already always a bad idea. assuming you would be managing permissions for this device on this device, if it was already pwned then the adversary could control your permission granting session and grant itself all the permissions anyway. for the related case of "adversary has after-the-fact access to a public terminal you used", good hygiene says you should take care to log out when you're done using any foreign terminal. and if you forget, log out remotely as in (1) asap.

perhaps an easier solution for device-security anxiety could be a checkbox (or some other UI element) when authenticating with your OP that influences token expiration (aka "refresh needed") and maybe even how long to go before reauthentication is needed. the default could be "short token and reauth lifetimes", and if you're at a trustworthy terminal that you control (like your home computer), you could select "longer token and reauth lifetimes".

from authorization-panel.

In terms of representing it, we could distinguish by DPoP public key, but that doesn't tell a developer that this is a Samsung Galaxy X in firefox mobile.

OP could use User-Agent header to get something human readable to display.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent#OS

I don't think token used by client needs any of that information. Since RS doesn't care about any of it.

Okay, I can see the need for this functionality. The main question now is how we represent that in the token and what affect it has for a Pod.
[...]
Perhaps there could be an obscure acl rule that uses it, but for the most part, it should completely depend on the application's unique identity rather than the application instance's unique identity.

solid/authentication-panel#37 proposes Sender Constrained tokens using DPoP. In that case Resource Server only verifies if sender can use that token, it doesn't verify any other information about the client. In other words RS has no other way of identifying the client than public key used for DPoP proof. If OP identifies client indirectly by redirect_uri or some other means when device flow was used, it doesn't seem matter in any way to RS receiving the token.

Given all above, I don't think any of that affects RS. RS only checks if sender can use the token and from there on just applies whatever capabilities were presented (by reference or value) in the token. It just needs to assume that those capabilities apply to client presenting it.
All the responsibility lies on OP to attach proper capabilities to client in token it issues to it. Here OP would take into consideration if user opted-in for device specific permissions or permissions applicable across all the devices.

i'm still not sure i understand the concern motivating this requirement.

I think besides use cases you described, where user may want to distinguish instances of app using for example same redirect_url but running on different devices, we may need to consider reverse use case. Same application using device code flow running on different devices, where user want's to apply same permissions to all those instances. In that case we very likely need a way for user to apply permissions to group of clients (sometimes redirect_url could define that group) not only one client. Given need for a way to apply permissions to group of clients as well as a client, we can simply use the same mechanism to address use case of distinct permissions of the same app running on multiple devices. Again this only seems to affect OP and they have full freedom how they design the UX.

from authorization-panel.