Background

The personal data transmission of an individual from an attribute provider to another entity involves the “Consent”. The typical consent is the one given by the data subject himself. However, there is another type of consent called “Social Consent” also known as “Statute”.

While the model that implements Subject’s consent is well known and understood as seen in OpenID and SAML related specifications, the “Social Consent” model has largely been dealt with in “ad hoc” manner, often as just a “configuration” of the “Access Control System” resulting in not-so-scalable nor open and transparent systems.

There is one implementation which standardized such “Social Contract”. The new AwswisApp system deployed in November 2010 in Germany uses so called “Terminal Certificate” to implement it. Terminal Certificate are X.509 Certificate with an extension element that holds the bit string indicating what attribute that “Terminal (client)” is allowed to obtain from the data source. As it is an X.509 certificate, it is signed, and signatory is the regulatory body.

While this is good for the current use cases in which all the attributes are actually stored on a Smart Card, it is limiting and is hard to apply to a distributed data model. Therefore, in this PoC, an extensible model that uses “JSON and URL” instead of “ASN.1 and bits string” is being explored.

PoC Overview

This PoC involves four entities: Privacy Commissioner, Data Source, Authorization Server, and the Client. In a hypothetical use-case, the Client is given permission by the Privacy Commissioner to obtain certain attributes from Data Sources. This permission is given in the form of Signed Request File (a file that captures all request parameters by the Client.) The Signature (p_sig) is that of the Privacy Commissioner. Fig.  1 Non-Subject Authorization Scheme Overview depicts the general relationships.

Fig. 1 Non-Subject Authorization Scheme Overview

In this example, the Data (Attribute) acquisition occurs in the following seven steps.

(1)  The Privacy Commissioner issues a signed Request File that includes all the allowed attributes request. The file is signed by the Privacy Commissioner so it cannot be modified. The file has the expiry date and unique identifier. This file is called “Attribute Request Permit” or “Permit”.

(2)  The Client presents the signed request to the Authorization Server to obtain the access_token and the Data Endpoint. Note that at this point, the Client does not know the Endpoint location of the Data.

(3)  The Authorization Server queries the Privacy Commissioner’s system to make sure that the Permit has not been revoked.

(4)  The Authorization Server Checks the Privacy Commissioner’s signature to make sure that the Permit has not been tampered, and check the Client signature to Authenticate the request. If both are fine, it creates the Signed Assertion that includes the access tokens and associated endpoint URIs that are subsequently used to obtain the data.

(5)  The Authorization Server returns the Assertion in the Response Body to the Client.

(6)  The Client learns the Data API location from the assertion and sends the request to it with the associated access_token.

(7)  Data source verifies the access token and encrypts the data with the Client’s public key that is present in the access_token and returns it.

Note that although in this figure we have only one Data Source, in general there could be many distributed Data Sources.

There is a separate Log API endpoint for each Data Source. This Endpoint is being queried with an appropriate access_token to obtain the access log to the Subject’s attributes so that the Subject can monitor the data usage. This happens in the following two steps.

(a)  Authorization Server (could be other servers) sends request to the Log API with the access_token.

(b)  Log API returns the encrypted log.