14Privacy_Open_RESTful_API_Specification
Please check the FI-WARE Open Specifications Legal Notice to understand the rights to use FI-WARE Open Specifications.
14.1.1Privacy-preserving Authentication API Core
This API for Privacy-preserving Authentication describes the endpoints of issuers, users, and verifiers to develop a fully anonymous yet accountable authentication system that preserves the privacy of its users.
The API is a RESTful, resource-oriented API accessed via HTTP that uses XML-based representations for information interchange.
14.1.2Intended Audience
This specification is intended for both software developers and reimplementers of this API.
In order to use this specifications, the reader must have a general understanding of the Privacy Generic Enabler. The reader should also be familiar with:
-
ReSTful web services
-
HTTP/1.1
-
XML data serialization formats.
14.1.3API Change History
This version of the Privacy API replaces and obsoletes all previous versions. The most recent changes are described in the table below:
Revision Date
|
Changes Summary
|
June 30, 2013
| | 14.1.4How to Read This Document
All FI-WARE RESTful API specifications will follow the same list of conventions and will support certain common aspects. Please check Common aspects in FI-WARE Open Restful API Specifications.
For a description of some terms used along this document, see Privacy Generic Enabler.
14.1.5Additional Resources
You can download the most recent version of this document from the FIWARE API specification website at Privacy Open RESTful API Specification. For more details about the Privacy GE's architecture that this API is based upon, please refer to Architecture Description.
The information provided here is an extension of the ABC4Trust Heartbeat H2.2 (Jan Camenisch, Maria Dubovitskaya, Robert R. Enderlein, Ioannis Krontiris, Anja Lehmann, Gregory Neven, Janus Dam Nielsen, Christian Paquin, Franz-Stefan Preiss, Kai Rannenberg, Michael Stausholm, and Harald Zwingelberg. H2.2 - ABC4Trust Architecture for Developers, October 2013). This Heartbeat document was adapted such that the API is compliant with FI-WARE's web-service based philosophy. Additionally, new dataformats were introduced to support the adapted API methods, and the previously Java-based API description was extended with descriptions of how the APIs can be used in a RESTful manner with web-services.
14.2.1Resources Summary
The following is a graphical diagram in which one can see the different URIs that can be used in the API.
14.2.2Representation Format
The Privacy API uses the XML serialization format both for a method's input parameter (if applicable) as well as the method's response.
14.2.3Resource Identification
Resource Identification is made using the mechanisms described by HTTP protocol specification as defined by IETF RFC-2616.
14.2.4Limits
The Privacy API does not support limits to manage the capacity of the system.
14.2.5Versions
Versioning information is not specified by this API guide.
14.2.6Extensions
The Privacy API does not support extensions.
14.2.7Faults
The Privacy API uses the default Hypertext Transfer Protocol (HTTP) error codes of classes 4xx and 5xx as specified in IETF RFC-2616 and summarized in List of HTTP status codes.
14.3Protocol Specification
Given the multitude of distributed entities involved in a full-fledged Privacy-ABC system, the communication formats that are use by the various system entities must be fixed. Rather than profiling an existing standard format for identity management protocols such as SAML, WS-Trust, or OpenID, we felt that the many unique features of Privacy-ABCs were more suitably addressed by defining a dedicated format. In particular, existing standards do not support typical Privacy-ABC features such as pseudonyms, inspection, privacy-enhanced revocation, or advanced issuance protocols. In Chapter 8, we discuss how our Privacy-ABC infrastructure could be integrated with a number of existing frameworks.
This chapter provides the specification for data artifacts exchanged during the issuance, presentation, revocation, and inspection of privacy-enhancing attribute-based credentials. Our specification separates the mechanism-independent information conveyed by the artifacts from the opaque mechanism-specific cryptographic data. This specification only defines the format for the mechanism-independent information. It provides anchor points for where instantiating technologies, in particular, U-Prove and Identity Mixer, can insert mechanism-specific data, but does not fix standard formats for this data.
For the specification we use XML notation in the spirit of XML Schema, but refrain from providing a full-fledged XML Schema specification within this document for the sake of readability; we do, however, make available a separate XML schema file for the artifacts defined here athttps://abc4trust.eu/download/xml/ABC4Trust_schema_H2.1.xsd. Although the artifacts are defined in XML, one could create a profile using a different encoding (ASN.1, JSON, etc.) See the corresponding schema file for more details.
We start in Section Terminology and Notation with introducing the terminology and notation used throughout this chapter. Section Setup then provides the artifacts for the setup of the different Privacy-ABC entities, which includes e.g., the description of the credential type and the public parameters of an Issuer and Inspector. In Section Revocation the specifications for all artifacts related to revocation are given. For the presentation of a token, the corresponding specifications of a presentation policy and a presentation token are introduced in SectionPresentation. Section Issuance is then dedicated to the Issuance of a credential and provides artifacts for the issuance policy and issuance token. Finally, Section Identity Selection and Credential Management introduces the data formats that are sent to and expected from (graphical) user interfaces.
Share with your friends: |