Subject: [GNAP] GNAP revisited

From: Denis <[email-masked]>
Date: Tue, 9 Feb 2021 20:38:44 +0100

*GNAP revisited*

The current GNAP draft does not take into consideration *RS Discovery* 
and *User Consent*, nor privacy requirements. This email explains why 
they should be taken into consideration. Before of speaking about 
implementation details, it is necessary to define a model and to 
identify the end-user requirements on that model. Such requirements are 
both /security /related and /privacy /related.

*The basic eID model*

The basic model is a Client-Server model which has two components:

-An *end-user* which interacts with the network using a *Client* which a 
software and an hardware component running on a local device
(e.g. on the end-user’s computer or the end-user's mobile phone).

-A *Resource Server* (RS) that protects a resource within a server.

*First security requirement*

Most of the cases, an end-user is willing to open an account on a 
Resource Server and wants to be the single individual to have access to 
that account.
For doing this, he does not need to present an access token from some 
Authorization Server (AS) but only needs to strongly authenticate to the RS.

*First privacy requirement*

>From an end-user perspective, it is necessary to prevent the linkability 
of transactions of an end-user among distinct resource servers
(or even within a single resource server). This property is called 
unlinkability.

*Taking into consideration these two requirements*

A well known mechanism has been promoted by the FIDO Alliance. It 
provides strong authentication by using asymmetric keys
instead of passwords and also considers an end-user privacy requirement: 
in order to prevent the linkability of transactions of an end-user
among different resource servers, a different pseudonym is being used 
for every resource server.

As a result, an end-user can open a user account on a resource server 
using a pseudonym and a key pair. This account may be permanent
or temporary. In both cases, it is thus possible prevent the linkability 
of transactions of an end-user among distinct servers or even for the 
same server.

A FIDO client can be implemented either using software-only or using a 
combination of software and hardware (e.g using both a secure element 
and a web browser).

*The basic eID model enhanced with access tokens*

Most of the time, an end-user is opening a user account on a RS to 
deposit some data, to get some data or to perform transactions.

There are cases where, in order to get a specific operation fulfilled, 
it is needed to present some privileges or access rights granted by one 
or more ASs.
It is not always necessary to present such granted privileges or access 
rights for every operation or access. The RS may request to present such 
access tokens
that contains these attributes once a day, a week, a month, a quarter or 
a year, depending upon his access control policy for the resource being 
operated.

Neither the client nor the end-user can anticipate when such access 
tokens are necessary. This will depend upon the operation the end-user 
wants to perform.
In order to be able to know whether access tokens are needed and, if 
needed, which access tokens are needed, the client needs to first 
advertise the operation
that it is willing to perform and then get the choice to continue or to 
discontinue the operation.

This is why a *RS Discovery* mechanism is needed.

Following this RS discovery phase, from a privacy point of view, it is 
fundamental get the *User Consent*.

The end-user may consent to request access tokens from some of the 
advertised AS (which are the ASs trusted by the RS for the specific 
requested operation).

If some access tokens which are still valid have been cached by the 
Client, this may avoid to request fresh access tokens.

The enhanced model which has now three components needs to take into 
consideration both "Privacy by Design" (PbD) principles and "privacy by 
default".

      Additional privacy requirements

>From an end-user perspective, it is important :

(a)to minimize the amount of attributes being disclosed by an end-user 
to the minimum necessary to achieve a stated purpose (Data minimization),

(b) to control that the obtained access token only contains the 
requested attributes (Transparency),

(c)to prevent an Authorization Server to know to which Resource Server 
an access token will be presented by the Client (Untraceability).

(d)  to prevent an Authorization Server to know /which /operation(s) 
will be performed by the Client on a RS,

(e) to prevent an Authorization Server to know /when /operation(s) are 
being performed by a Client on a RS.

These five additional privacy requirements need to be considered when 
constructing an eID mechanism.

      Taking into consideration the six privacy requirements

*User Consent*: In order to enable users to agree to consent for the 
communication of their attributes through an affirmative process,
the end-user should be able to select the attributes he would like to be 
placed into an access token.

*Data minimization *: In order to minimize the amount of attributes 
being disclosed by a user to the minimum necessary to achieve a stated 
purpose,
an access token should only contain the set of attributes that is needed.

*Transparency*: The client should be able to verify which attributes 
have effectively been placed in an access token by an Authorization Server
before forwarding it to a Resource Server. As an example,if the access 
token is considered to be opaque to the client, this requirement cannot 
be fulfilled.

*Untraceability*: In order to prevent an Authorization Server to know to 
which Resource Server an access token will be presented by the Client:

1there shall be no direct interaction between an Authorization Server 
and a Resource Server, and

2the access token shall not contain data that would allow the 
Authorization Server to identify the Resource Server.

This last condition is rather important otherwise Authorization Servers 
would have the possibility to act as "Big Brother".
As an example, when capabilities are supported by an Authorization 
Server it isnot possible meet this requirement.

The Authorization Server should not be able to know /which /operation(s) 
may be performed by the Client on a RS.
As an example, when capabilities are supported by an Authorization 
Server it isnot possible meet this requirement.

The Authorization Server should not be able to know /when /operation(s) 
are being performed by the Client on a RS.
As an example, the existence of "Token Introspection" mechanism (as 
defined in OAuth) is unable to fulfil this requirement.

      Taking into consideration FIDO

FIDO can be implemented without or with secure elements. There are both 
advantages and disadvantages to use secure elements.

When secure elements are being used, they do not need to be provided by 
a governmental agency. they can be provided by any manufacturer
and distributed by anyone, e.g. sold in a supermarket. Such secure 
elements do not originally contain any personal data.

If secure elements are being used, Authorizations Servers would be able 
to verify that they interact with a client using a secure element.
This opens a Pandora box for additional opportunities, in particular the 
direct verification by the Authorizations Servers of APDUs
(Application Protocol Data Units) generated by the secure elements.

      Conclusion

This approach highlights the fact that operations can be performed on a 
resource server (RS) *with or without using access tokens *
and that two major operations need to be supported: *RS Discovery* and 
*User Consent*. This approachis able to support six privacy requirements.

This approach is also able to take advantage of a technology supported 
by some major vendors: *FIDO*.

Denis