Home

By Jan Camenisch, Ioannis Krontiris, Anja Lehmann, Gregory Neven, Christian Paquin, Kai Rannenberg

Download: PDF, XML Schema for H2.1,

Review Status: Not foreseen for external review

Abstract

The goal of ABC4Trust is to address the federation and interchangeability of technologies that support trustworthy yet privacy-preserving Attribute-based Credentials (Privacy-ABCs). 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 deliverable D2.1 of the project. 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. The ABC4Trust architecture is an ongoing work and it continuously evolves, so this Heartbeat H2.1 document comes to present a first update of D2.1. This document targets to keep early adopters up-to-date, so it presents only those changes that are relevant to the development of applications and removes the details of the internal components.

Executive Summary

ABC4Trust 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). Deliverable D2.1 “Architecture for Attribute-based Credential Technologies – Version 1” [CKL+11] describes the details of this layer. More specifically, it provides simple interfaces towards the application layer, thereby abstracting the internal design and structure. So the architecture defines and standardizes all the technology-agnostic components of theABCE layer, as well as the APIs they provide. For the latter, the architecture defines first the interfaces that 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.

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.)

However, the initial version presented in D2.1 has already started changing and this heartbeat comes as an intermediary update of some parts that particularly concern application developers. In particular, this heartbeat removes the details of how the ABCE layer looks internally and gives a simpler and more modular explanation of its functionality. Correspondingly, it presents an updated “external” API that the ABCE layer offers to the application layer, as well as an updated version of the dataformats. It also presents some updates in the definition of concepts and features of ABCs. Overall, the update reflects the current ABCE reference implementation that has been completed and being used by the pilots. What presented here is independent of the internal ABCE architecture, which is constantly evolving, but since these changes do not concern application developers, this document has removed the corresponding sections.