By Jan Camenisch, Ioannis Krontiris, Anja Lehmann, Gregory Neven, Christian Paquin, Kai Rannenberg, Harald Zwingelberg
The goal of ABC4Trust is to address the federation and interchangeability of technologies that support trustworthy yet privacy-preserving Attribute-based Credentials (Privacy-ABC).
Towards this goal, one of the main objectives of the project is to define a common, unified architecture for Privacy-ABC systems to allow comparing their respective features and combining them on common platforms. The first version of this architecture is described in the deliverable at hand. Its main contribution is the specification of the data artifacts exchanged between the implicated entities (i.e. issuer, user, verifier, revocation authority, etc.), in such a way that the underlying differences of concrete Privacy-ABC implementations are abstracted away through the definition of formats that can convey information independently from the mechanism-specific cryptographic data. It also defines all technology-agnostic components and corresponding APIs a system needs to implement in order to perform the corresponding operations, i.e. to process an obtained issuance/presentation policy, perform the selection of applicable credentials for a given policy or to trigger the mechanism-specific generation of the cryptographic evidence.
How Privacy-ABCs can be applied in existing identity protocols and frameworks such as WS-*, SAML, OpenID, OAuth and X.509 and how Privacy-ABCs can help to alleviate some of the security, privacy and scalability issues of these protocols is also discussed.
This deliverable presents the first version of the ABC4Trust architecture. It produces an architectural framework for Privacy-ABC technologies that allows different realizations of these technologies to coexist, be interchanged, and federated. This enables users to obtain credentials following different Privacy-ABC technologies and use them indifferently on the same hardware and software platforms, as well as service providers to adopt whatever Privacy-ABC technology best suits their needs.
In particular, the architecture has been designed to decompose future (reference) implementations of Privacy-ABC technologies into sets of modules and specify the abstract functionality of these components in such a way that they are independent from algorithms or cryptographic components used underneath. The functional decomposition foresees possible architectural extensions to additional functional modules that may be desirable and feasible using future Privacy-ABC technologies or extensions of existing ones.
The architecture of ABC4Trust is defined by following a layered approach, where all Privacy-ABC related functionalities are grouped together in a layer called ABCE (ABC Engine). It provides simple interfaces towards the application layer, thereby abstracting the internal design and structure. So the deliverable defines and standardizes all the technology-agnostic components of the ABCE layer, as well as the APIs they provide. For the latter, the deliverable defines first the interfaces the ABCE components offer to the upper layers (e.g. Application), as well as the APIs that the different components within the ABCE layer expose to each other.
Equally important in the architecture is the specification of the data artifacts exchanged between the implicated actors, in such a way that the underlying differences of concrete Privacy-ABCs are abstracted away through the definition of formats that can convey information independently from the mechanism-specific cryptographic data. So the document emphasizes on the XML based specification of the corresponding messages exchanged during the issuance, presentation, revocation, and inspection of privacy-enhancing attribute-based credentials.
Consideration is also given on how the proposed architecture integrates with existing identity management systems. The deliverable provides an analysis regarding the applicability of the ABC4Trust architecture to the popular existing identity protocols and frameworks such as WS-*, SAML, OpenID, OAuth and X.509. It shows how Privacy-ABCs can be applied in these protocols and how the former can help to alleviate some of their security, privacy and scalability issues of the latter.
Finally, an overview on legal considerations of deploying Privacy-ABCs is also provided. It describes how the benefits of Privacy-ABCs relate to privacy requirements from the legal point of view and lays the foundation for evaluating the legal obligations and rights between the implicated parties. This analysis will later be used to perform a legal evaluation on the specific pilot scenarios applying the architecture.
Within the ABC4Trust project, WP4 will use the input of this document to provide a reference implementation of the architecture, which will be later used for realizing the pilot scenarios of WP6 and WP7. Also WP3 will use the architecture design presented here to perform a comparison of features at common levels (cryptographic properties, security tokens, etc.).
The deployment of the reference implementation of this architecture in the pilot scenarios during the next months will give valuable feedback to the architecture design and the experiences gained will enable its finalization in the second version (M39). The second version will also concentrate on more detailed definitions needed for advanced features (e.g. algebraic operation in predicates or in carry- over issuing, efficient updates of attributes, limited spending, inspection of proofs, etc.)