-
Notifications
You must be signed in to change notification settings - Fork 0
Categories of interaction
Here we describe the various cases we may encounter, as it's often not explicit enough. The requirements for each case are quite different.
We classify the cases on 2 axes:
- Are User and RO the same? (singleparty / multiparty consent)
- Does the consent happen synchronously or asynchronously? (interact mode)
Currently we use the OAuth2 terms ("User" and "Resource Owner"). But for GNAP we may end-up using more precise terms.
User => we may use "end-user", so that it's clear we're talking about a human RO => we may use "Resource Controller (RC)", since it may or may not be a human (depending on the situation).
By definition, we are in a singleparty use case. A typical example of that situation is when the user is trying to access to a personal resource (ex: his photo album). Then the problem OAuth2/GNAP addresses is: how do we make sure the user gives his consent to the application to do whatever it needs to do (e.g. print the album)?
This use case is well understood.
Here we are in a multiparty use case (up to N+1 for N resources). We can make the reasoning with 2 parties for simplicity. Example: a patient has a medical appointment with a new doctor. The doctor needs to access the medical record of the patient. Here the doctor is the User and the patient is the RO. Since they're already interacting face to face (physically or through video), the patient takes his decision (yes/no for each requested item) as soon as the doctor asks him to provide some information.
This use case is much more challenging:
- how do we communicate between the User and the RO?
- how do we make sure of the identity of the RO? (e.g. verified credential that the doctor is legit)
This use case is frequent in situations such as healthcare, government, etc. There's been some work with UMA2 on similar topics, but mostly for federated resources. Self sovereign identity (SSI) could help (ex: DIDComm, VC, etc.) manage this use case in a more consistent way.
Here we are also in a multiparty use case, but don't want to wait. We don't expect a direct answer from a human. We don't require that the RO be online.
The decision is handled by an automated policy engine: the RO decides on the rules which are used when a user wants to access a resource.
This use case is frequent when there is a hierarchy, e.g. in a corporate environment (employee/manager). It's fairly straightforward to handle using RBAC for instance.