-
Notifications
You must be signed in to change notification settings - Fork 0
Three Client Server use cases with several ASs built along "Privacy by Design" (PbD)
Three use cases are considered:
- a Client-Server use case with several ASs and a single RS (1), and
- a Client-Server use case with several ASs and with operation forwarding between RSs, with variants (2a) and (2b).
Vocabulary:
User: physical person
Client: piece of software that allows a user to interact with RS(s) and AS(s) Note: a piece of software is supported by some hardware.
1. Client-Server use case with several ASs and a single RS
This use case is about one operation performed by a Client on a RS when one or more access tokens are requested by that RS. The user already has accounts on more than one AS.
RFC 6973 "Privacy Considerations for Internet Protocols" identifies a few privacy principles and in particular two of them called "Data Minimization" and "User Participation".
6.1. Data Minimization
Data minimization refers to collecting, using, disclosing, and storing the minimal data necessary to perform a task.
(...)
Limiting the data collected by protocol elements to only what is necessary (collection limitation) is the most straightforward way to help reduce privacy risks associated with the use of the protocol.
(...)
However, the most direct application of data minimization to protocol design is limiting identifiability. Reducing the identifiability of data by using pseudonyms or no identifiers at all helps to weaken the link between an individual and his or her communications. (...)
6.2. User Participation
(...) privacy regimes tend to include provisions to require informing individuals about data collection and use and involving them in decisions about the treatment of their data. (...)
Different protocol and architectural designs can make supporting user participation (for example, the ability to support a dialog box for user interaction) easier or harder.
A key objective of these use cases is to be able to take into consideration these two privacy principles. However, RFC 6973 does not consider the ability for Authorization Servers [alias Identity Providers, an entity, usually an organization, that is responsible for establishing, maintaining, securing, and vouching for the identities associated with individuals] to act as Big Brother, i.e. to be aware of which Resources Servers (RSs) will be accessed by their users or of which operations will be performed by their users on which Resources Servers (RSs).
+--------+ +------------+
| User | | Resource |
| |\ | Owner (RO) |
+--------+ \ +------------+
| \ |
| \ |
| \ |
| \ |
+-----------+ (2a) +---------------+ +------------+
| |----->| Authorization | | |
| | (2b) | Server (AS) | | |
| |<-----| | | |
| Client | +---------------+ | |
| | (1a) | |
| |--------------------------->| Resource |
| User | (1b) | Server |
| Consent |<---------------------------| (RS) |
| element | (3a) | |
| |--------------------------->| |
| | (3b) | |
| |<---------------------------| |
+-----------+ +------------+
Taking into consideration both the "data minimization" principle and the "user participation" principle when a user first authenticates to a RS leads to the following:
When accessing a RS for the first time, the user should be informed of the authentication means proposed by the RS. The user should be able to use a dialog box where some choices are presented by the RS. The user should be able to locally make his own choices and to indicate his consent to its Client.
The dialog box is handled by a "User Consent element" managed by the Client. It is intended to standardize the semantics of the information delivered by the RS to the "User Consent element" managed by the Client so that the same kind of information will be displayed to the user. The look and feel of that dialog box will however be dependent upon the man-machine interface (MMI) from the Client.
Several alternatives should be available for a user:
-
Create a temporary account on the RS using a key pair and a temporary pseudonym which will only remain usable during a few hours (e.g. 12 hours) and then authenticate to the RS under that temporary pseudonym and the corresponding private key,
-
Create a permanent account on the RS using a key pair and a pseudonym specific to the RS and then authenticate to the RS under that pseudonym and the corresponding private key (in this case, FIDO may be used),
-
Present specific types of personal attributes using access tokens granted by one or more ASs.
Once the user has been proposed by the RS to perform one or more specific operations that may require one or more access tokens with specific types of personal attributes, the user should select one operation.
Taking into consideration both the "data minimization" and the "user participation" principles when a user chooses to perform an operation on a RS leads to the following:
When a user chooses to perform one operation on a RS, the RS should limit the data to be collected from the user to only what is strictly necessary to perform that operation. That data consists of specific types of attributes that need to be guaranteed by one or more ASs. The user should be able to use a dialog box where some ASs choices are proposed by the RS. The user should be able to locally make his own choices and to indicate his consent to its Client.
It is important to notice that the choices that will be proposed to a user may depend upon previous personal information voluntarily released by that user. This means that the choices proposed by the RS may be tailored for the user. Furthermore, the proposed choices may only be disclosed to already authenticated users.
Once the user has made its choices, the Client shall contact one or more ASs and for each of them request specific types of attributes.
For security reasons, each access token shall be targeted to one or more RSs. However, this does not mean that the true name of each RS shall necessarily be disclosed to the AS. Hiding the true name of RSs to ASs prevents ASs to act as Big Brother.
The choice of hiding or not hiding the true name of the RS is a choice made by the Client. Such a choice may be handled through a local configuration of the Client. If "privacy by default" is applied, hiding the true name of the RS should be the default choice.
The role of the AS is to deliver the requested types of attributes into an access token without necessarily knowing to which RS(s) the access token is intended.
Once the Client has obtained the requested access tokens, they are not immediately presented to the RS: the Client should be able to verify that the content of each access token is in accordance with each access token request. To perform such a verification, the returned access tokens are transmitted back to the "User Consent element" managed by the Client which should memorize the choices made by the user. In particular, the Client should check that the access tokens do not contain more than the requested attributes. This means that the content of the access tokens is not considered to be opaque (and in particular to the "User Consent element" managed by each Client).
Once this verification is successfully done, the access tokens are presented to the RS.
Some observations
There is no need for any dialogue between an AS and a RS prior to the time a Client is making an access. However, this is not precluded in particular to ensure some backwards compatibility with OAuth 2.0 ASs (to allow the use of a scope parameter in a token request).
There is no need for any dialogue between an AS and a RS or between a RS and an AS at the time a Client is making an access (token introspection is unnecessary, since the access tokens are not considered to be opaque).
There is no need for any RO (Resource Owner) to contact any AS. If an interaction with a RO is necessary at the time a Client is making an access, it may be done using a dialogue between a RO and a RS.
Illustration of that use case
An illustration of that use case is the registration of a student to a new university.
When the Client contacts the RS of the new university for the first time, the student chooses to create a permanent account on that RS using a key pair and a pseudonym specific to that RS and then to authenticate to that RS under that pseudonym and the corresponding private key.
Once the student has filled-in some forms, the RS is able to know :
-
the purported current university of the student. If that current university is known and trusted by the RS, the RS indicates the URL of the AS from that university and asks the Client to provide an access token testifying that the student indeed got a graduation from that university. If the user agrees, then the Client is able to ask to this university an access token testifying his latest graduation.
-
the purported gender, first name(s), family name, date of birth, location of the birth and home address of the student. Using the country name of the home address, the RS indicates which ASs it trusts to deliver an access token proving that that information indeed belongs to the applicant. If the student has a user account with one of these ASs, then the user is able to select it and the Client is able to ask an access token testifying that the purported information indeed belongs to the applicant.
Once the student has provided these two access tokens to the RS, he will be registered by the university. He can then log-off from the RS of the university.
2. Client-Server use case with several ASs and with operation forwarding between RSs
This use case is about one operation performed by a Client on a RS when one or more access tokens are requested by that RS and when that RS is unable to fulfil the requested operation by its own and needs to contact another RS. The user has already accounts on more than one AS. Let us now suppose that the RS (now called RS1) is unable to fulfil the requested operation by its own and needs to contact another RS called RS2 in order to delegate partly or in full the processing of the operation to RS2.
The following figure is used to illustrate two operation forwarding use cases: whether RS1 and RS2 do not belong to the same service (Case 2 a) or whether they both belong to the same service (Case 2 b).
+--------+ +------------+
| User | | Resource |
| |\ | Owner (RO) |
+--------+ \ +------------+
| \ |
| \ |
| \ |
| \ |
| \ |
+-----------+ (2a) +---------------+ +----------+
| |----->| Authorization | | |
| | (2b) | Server (AS) | | |
| Client |<-----| | | |
| | (1a) +---------------+ | |
| |------------------------>| Resource |
| User | (1b) | Server 1 |
| Consent |<------------------------| (RS1) |
| element | (3a) | | (4a) +----------+
| |------------------------>| |------>| |
| | | | (4b) | |
| User | (3b) | |<------| |
| Consent |<------------------------| | | Resource |
| element | +----------+ | Server 2 |
| | (5a) | (RS2) |
| |------------------------------------------->| |
| | (5b) | |
| |<-------------------------------------------| |
+-----------+ +----------+
Case 2 a: RS1 and RS2 do not belong to the same service
Let us suppose that RS1 is unable to fulfill the requested operation by its own and that it needs to contact another RS, i.e. RS2. RS1 contacts RS2 (4a) and indicates the operation that it is willing to perform on RS2 (that operation may not be the same as the original operation requested by the Client).
In return (4b), RS2 :
-
provides information to RS1 that will allow the Client to present a dialog box to the user with the choices proposed by RS2, and
-
provides a temporary API address so that the Client can make a call directly to an API from RS2.
RS1 then forwards that information to the Client.
The dialog box is handled by the "User Consent element" from the Client.
The user can see the new requested operation by RS1 on RS 2 and which kind of attributes are requested by RS2, as well as from which ASs. If the user consents to release these attributes to RS2, for the (possibly new) operation, then the Client contacts one or more appropriate Authorization Servers.
Once the Client has obtained the appropriate access tokens targeted to RS2, they are verified by the "User Consent element" managed by the Client.
Once this verification is successfully done, the access tokens are presented to RS2 (5a) in a single request. Then RS2 is able to provide a response to the Client (5b).
Some observations
The user consent is captured locally by the "User Consent element" from the Client. There are two user consent phases: one for RS1 and another one for RS2. There are also two verifications phases performed by the "User Consent element" managed by the Client.
RS1 will know which kind of attributes types are requested by RS2, but will be unable to know which attribute values from which AS(s) will be presented by the Client to RS2. This is an important privacy feature of this flow of information.
RS1 does see the flow (5b) since this flow (5b) is going directly from RS2 to the Client.
Case 2 b: RS1 and RS2 both belong to the same service
Let us now suppose that RS1 is unable to fulfill the requested operation by its own but that it knows that the requested operation can be fulfilled with the cooperation of another RS from the same service.
In such a case, when preparing the information to be presented into the dialog box, RS1 will disclose both its own name and the name of a service. This allows to target the access token to a service name (without necessarily disclosing the name of that service to the AS).
Hiding the true name of RSs and service names to ASs prevents ASs to act as Big Brother.
This allows to save the exchanges (5a) and (5b): in such a case, all the exchanges with the Client will be carried out through RS1.