Name: CRYPTAS it-Security
Address: Franzosengraben 8, 1030 Vienna


In typical identity federation models there exists a strong binding between identity providers and service providers. This leads to limited scalability and often violates privacy by design principles. Other models have an another layer (e.g. hub) with additional functionalities for separating the entities but with the ability for data aggregation.

For achieving the trust paradigm shift, the architectural and functional requirements, which are defined in the generic trust architecture, must be fulfilled. Some of these requirements are:

  • Mitigate the observability threat. No federation entity shall be able to aggregate data about the usage of multiple services by users (principals), therefore being unable to deduct personal interests or behaviour.
  • Prevent the unauthorised aggregation of attributes. No federation entity shall be able to collect attributes beyond the specified purpose of a service and deduct personal information and behaviour. (Authorised aggregation of attributes within the limits of the purpose is allowed).
  • Prevention of unauthorised attribute polling. A mechanism to prevent unauthorised discovery of attributes shall be provided.
  • Prevention of replay and reuse attacks. An identity provider (IdP) must limit each assertion to used only once at a specific service provider (SP).
  • No supreme instance. Actors managing trust roots must not have access to either attributes or transaction data
  • Maximise compatibility with existing single sign-on profiles to the extent that other requirements are not compromised:
  • Feasible implementation effort. The model shall make use of existing profiles and implementations as far as reasonable.
  • Feasible deployment effort. It shall be possible to use existing SAML service provider implementations within current configuration limits. For identity providers, that is desirable as well
  • Minimise the release of attributes. The IdP, in its role as data controller of a principal’s identity information, must be assured that only those attributes deemed necessary for the purpose of the service are released to the relying party

To achieve these requirements a demonstrator was created implementing the privacy-enhanced architecture (PE-FIM).

It is based on a three-tier architecture that is an extended hub and spoke model with privacy by design principles applied to it. The hub is called the service broker (SB) in this model.

Within the architecture the IdP has a direct trust relationship with the SB and the SB with SPs. All entities trust a certificate authority which can, for example, be operated by a federation operator. The SB is acting as a separator and proxy for the entities with additional functionalities like consent handling and enabling secure messaging for enabling additional business prospects

  • Functionality:

The IdProxy is the base component of the Service Broker used to separate the entities, enabling the trust architecture.

Cryptas IdProxy

  • Category: Data Privacy
  • Type: A proxy that can be setup in different environments
  • Availability:

Downloadable from Github


Technical requirements:
The IdProxy can also be operated as stand alone component, but makes, of course, only sense to use in a federation environment with IdPs and SPs based on SAML.

  • Terms & Conditions of use:

Free to use