Contributing Partners 

AIT, ATOS, FOKUS, GUF, TUG, KGH, LISPA

Executive Summary
On a high level, the central goal of the CREDENTIAL project is to develop a privacy-preserving data sharing platform, where even data mediating services - in particular identity providers (IdP) for managing users’ identifying and demographic data - are unable to learn about any of the user’s personal information.
During the project, Proxy Re-Encryption (PRE) and Redactable Signature Schemes (RSS) have been identified as promising technologies for reaching this goal. Using PRE identity data can be stored with an IdP in an encrypted manner while being re-encrypted for an authorized consumer upon demand. In addition, RSS allows for redacting selected parts of an identity scheme while preserving the integrity and authenticity of the affected identity data set. Both technologies can even be combined (PRE+RSS) for redacting selected identity attributes even from encrypted identity data.
A typical setup consists of four actors: (1) A user, whose private identity data is to be protected, (2) an identity provider, that manages this information in a secure manner, (3) a service provider, that needs to consume part of the identity information and (4) a key generator service, that provides keys for re-encrypting the identity data for use by the service provider. In this deliverable, we assess on solutions for the two major challenges related to security and interoperability that are inherent to PRE and RSS:
• How can trust among these actors be established?
• How can the required sharing of information among these actors by implemented through standard identity and access management (IAM) protocols?
Regarding the first challenge, three different deployment options for the key generator (KG) are considered: KG as a Client, KG as a Server and KG as an App. For each of these options, solutions are given on how trust between the KG and the IdP (for exchanging re-encryption keys) and the IdP and the service provider (for exchanging re-encrypted identity data) can be established. By being able to technically solve all initially identified security gaps, all three deployment options are shown to be both implementable and useful with respect to given requirements and environments. Especially in rather interactive scenarios, the KG as an App solution is shown to provide the highest degree of usability as it allows the user for an integrated management of access permissions and data visibility constraints.
For the second challenge, we selected OpenID Connect and SAML - being the best established IAM protocols in use - as carriers for messages that need to be exchanged among IdP, KG and service provider. For each technology (PRE, RS, PRE+RS) we give examples on how standard messages and security objects can be enhanced for sharing public keys, re-encryption keys, identity token and encrypted and/or redacted identity data. For sharing identity data, we propose to first canonialize and encode an existing scheme as a flat set of ASN.1 path-value pairs. These path-value pairs can then be encoded as XML or JWE and be placed into SAML assertions or JSON Web Token, respectively.
While most of the identified gaps can be solved transparently on the protocol level, the binding of an encrypted identity data set to a CREDENTIAL account requires the account identifier to be placed into the data set in order to allow the consumer to validate the authenticity of the data. The concrete placement of this identifier may vary depending on the identity scheme and may therefore require domain specific profiling of the proposed solutions.