We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Security.Privacy Generic Enabler - FIWARE Forge Wiki

FIWARE.OpenSpecification.Security.Privacy Generic Enabler

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Security.Privacy
Chapter Security,
Catalogue-Link to Implementation [TBD ]
Owner IBM Research - Zurich / ZHAW, Franz-Stefan Preiss, Anja Lehmann / Stephan Neuhaus



Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


Copyright © 2012-2014 by IBM
Copyright © 2014-2015 by ZHAW

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.


The Privacy Enabler provides trustworthy, yet privacy-friendly authentication, using privacy-enhanced attribute-based credentials (Privacy-ABCs).

In a nutshell, the user first obtains credentials, which are certified attribute-value pairs, from an issuer who vouches for the correctness of the certified attributes. The user can subsequently authenticate towards a verifier by sending a presentation token, which is derived from her credentials. A single presentation token can selectively reveal attribute values from one or more credentials. It can also prove that a given predicate, which may involve one or more attributes, holds, without revealing the full attribute values. For example, it would be possible to prove that the value of the "date of birth" attribute is before January 1st, 1994, or that the name on the user's credit card (the "user name" attribute of the credit card credential) is the same as that on her driver’s license (the "name" attribute on the driver's license credential).

For an easy integration of Privacy-ABCs in various applications and systems, we provide a mechanism-independent attribute-based credential engine (ABC Engine) layer on top of the core Cryptographic Engines. This ABC Engine layer contains all the mechanism-agnostic components of a Privacy-ABC system. The figures provided in the following sections depict the high-level architecture around the Privacy GE and the typical communication flows for credential issuance and token presentation.

Basic Concepts

In the following, we introduce the basic concepts and features of privacy-enhancing attribute based credentials (Privacy-ABC), using the generic terms and descriptions that were developed in the ABC4Trust project. Those aim to identify the common properties of different cryptographic instantiations (as briefly presented in the subsequent sections) and address them in a unified and technology-agnostic manner.

For more details regarding the different features we refer to ABC4Trust H2.2.

Figure 1 gives an overview of the entities involved in Privacy-ABC systems and the interactions between them.

Figure 1: Main entities in a Privacy-ABC system
Figure 1: Main entities in a Privacy-ABC system.

The main entities are users, issuers and verifiers.

  • The user is at the center of the scheme, collecting credentials from various issuers and controlling which information from which credentials is presented to which verifiers.
  • The issuer issues credentials to users, thereby vouching for the correctness of the information contained in the credential with respect to the user to whom the credential is issued. Each issuer generates a secret issuance key and publishes the issuer parameters that include the corresponding public verification key.
  • The verifier protects access to a resource or service that it offers by imposing restrictions on the credentials that users must own and on the information from these credentials that users must present to access the service.

Optional entities are inspectors and revocation authorities (which are not planned in this FIWARE release)

  • The revocation authority (optional) is responsible for revoking issued credentials, so that these credentials can no longer be used to generate a presentation token. Each revocation authority generates and publishes its revocation parameters.
  • The inspector (optional) is a trusted authority who can de-anonymize presentation tokens under specific circumstances. At setup, each inspector generates a private decryption key and a corresponding public encryption key. It is important to note that a user will know, at the time that a credential is issued, whether it will be possible to remove the anonymisation protection offered by Privacy-ABCs. It is not possible to issue a credential to a user and de-anonymise that user later, without the user being aware that this could be the case.

These entities exchange messages containing various data items:

  • All participants have access to the system parameters, a set of values that must be the same for all participants in the privacy ABC system. These parameters contain cryptographic key lengths, among other things. It is important that they are the same for all cooperating participants. Usually, issuers generate system parameters and verifiers and users get them from issuers. In the FIWARE implementation, all issuers generate the same system parameters, so they are compatible. These default parameters have an RSA equivalent key strength of more than 3000 bits and a symmetric key equivalent strength of 128 bits. (Current recommendation for RSA key pairs is 2048 bits.)
  • An issuer publishes its issuer parameters that contain the issuer's public key and other assorted cryptographic information. (One part of this information is which privacy-preserving technology to use; FIWARE only supports IBM's idemix technology, so that information will always be fixed in the context of FIWARE.)
  • Issuers create and maintain credential specifications, which contain the names and types of the attributes that will be contained in a credential. For example, a "passport" credential specification could maintain that a credential of type "passport" contains the name of the person (as a string) and his or her birth date (as a date). Credential specifications have a name that makes them unique, and that name must be assigned when creating new credential specifications. Users request credentials according to their credential specification.
  • When a user asks a verifier for access to a resource, the verifier issues a presentation policy. This policy says what attributes the verifier wants to see, issued by what issuer, in order for the user to be granted access. For example, the presentation policy could be "if you want a ticket to the concert, you must show to me the serial attribute in a credential from payment provider xyz with the credential specification Eric Clapton Concert 2014". Or the presentation policy could be "if you want access to that movie, you must prove to me that your date of birth, according to your passport credential issued by Passport Issuance Authority of Louisiana is earlier than 1996-12-01".

In a nutshell, an attribute-based credential contains attribute-value pairs that are certified by a trusted issuer. Using her credentials, a user can generate a presentation token that contains a subset of the certified attributes. Upon receipt of a presentation token from a user, a verifier checks whether the presentation token is valid w.r.t. the relevant issuers' public keys. If the verification succeeds, the verifier can rest assured that the corresponding issuers vouch for the attributes that are contained in the presentation token.

Informally, a secure realization of a Privacy-ABC system must guarantee that

  1. users can only generate a valid presentation token if they were indeed issued the corresponding credentials, and
  2. the presentation tokens do not reveal any further information about the users other than the attributes contained in them.

The last point comprises unlinkability and untraceability of tokens. Unlinkability roughly means that different tokens derived from the same credential should not be linked together. Untraceability also covers the issuance process and requires that an issuer should not be able to link a given token to a particular issuance session with a user. Both properties of course only hold with respect to the identifiability due to the disclosed attributes in a token.

Next, we provide a brief explanation of the main features supported by Privacy-ABCs, with a focus on those that have not yet been modeled in existing identity frameworks.


In traditional public-key cryptography, users generate a private/public key pair that can be used to authenticate the users. Unlike traditional public-key authentication schemes, however, in a Privacy-ABC system, users may generate as many public keys as they wish from a previously generated secret key. These public keys are called pseudonyms in a Privacy-ABC system. Pseudonyms are cryptographically unlinkable, meaning that given two different pseudonyms, one cannot tell whether they were generated from the same or from different secret keys. By generating a different pseudonym for every verifier, users can thus be known under different unlinkable pseudonyms to different sites, yet use the same secret key to authenticate to all of them.

Although it is sufficient for users to generate a single secret key, they can also have multiple secret keys. A secret key can be generated by a piece of trusted hardware (e.g., a smart card) that stores the key and uses it in computations (e.g., to generate pseudonyms), but never reveals the key. The key is thereby bound to the hardware, in the sense that it can only be used in combination with the hardware.

There are situations, however, where the possibility to generate an unlimited number of unlinkable pseudonyms is undesirable. For example, in an online opinion poll, users should not be able to bias the result by entering multiple votes under different pseudonyms. In such situations, the verifier can request a special pseudonym called a scope-exclusive pseudonym, that is unique for the user’s secret key and a given scope string. Scope-exclusive pseudonyms for different scope strings remain unlinkable. By using the URL of the opinion poll as the scope string, for example, the verifier can ensure that each user can only register a single pseudonym to vote.

Credentials and Key Binding

A credential is a certified container of attributes issued by an issuer to a user. Formally, an attribute is described by the attribute type that determines the semantics of the attribute (e.g., first name) and the attribute value that determines its contents (e.g., “John”). By issuing a credential, the issuer vouches for the correctness of the contained attributes with respect to the user.

Optionally, a credential can be bound to a user’s secret key, i.e., it cannot be used without knowing the secret key. We call this option key binding. It is somewhat analogous to traditional public-key certificates, where the certificate contains the CA’s signature on the user’s public key, but unlike traditional public-key certificates, a Privacy-ABC is not bound to a unique public key: it is only bound to a unique secret key. A user can derive as many pseudonyms as she wishes from this secret key and (optionally) show that they were derived from the same secret key that underlies the credential. As an extra protection layer, the credentials can also be bound to a trusted physical device, such as a smart card, by keeping the secret key in a protected area of the device.


To authenticate to a verifier, the user first obtains the presentation policy that describes which credentials the user must present and which information from these credentials must be revealed. If the user possesses the necessary credentials, she can derive from these credentials a presentation token that satisfies the presentation policy. The presentation token can be verified using the issuer parameters of all credentials underlying the presentation token.

Presentation tokens derived from Privacy-ABCs only reveal the attributes that were explicitly requested by the presentation policy – all the other attributes contained in the credentials remain hidden. Moreover, presentation tokens are cryptographically unlinkable (meaning no collusion of issuers and verifiers can tell whether two presentation tokens were generated by the same or by different users) and untraceable (meaning that no such collusion can correlate a presentation token to the issuance of the underlying credentials). Of course, presentation tokens are only as unlinkable as the information they intentionally reveal.

Rather than requesting and revealing full attribute values, presentation policies and tokens can also request and reveal predicates over one or more issued attributes. For example, a token could reveal that the name on the user’s credit card matches that on her driver’s license, without revealing the name. As another example, a token could reveal that the user's date of birth is before January 1st, 1994, without revealing her exact date of birth.

When the presentation policy requires possession of a key-bound credential, the derived presentation token from such a credential always contains an implicit proof of knowledge of the underlying secret key. Thus, the verifier can be sure that the rightful owner of the credential was involved in the creation of the presentation token. When the secret key of the user is a device key, i.e., a key that is kept on a trusted device and cannot be extracted from the device, then the proof of knowledge of the key is performed on the device and included in the generation of the presentation token. Accordingly, for credentials that are key-bound to a physical device it is impossible to create a presentation token without the device.


In the simplest setting, an issuer knows all attribute values to be issued and simply embeds them into a credential. Privacy-ABCs also support advanced issuance features in which attributes are blindly “carried over” from existing credentials, without the issuer becoming privy to their values. Similarly, the issuer can blindly issue self-claimed attribute values (i.e., not certified by an existing credential), carry over the secret key to which a credential is bound, or assign a uniformly random value to an attribute such that the issuer cannot see it and the user cannot bias it.

Advanced issuance is an interactive protocol between the user and the issuer. In the first move, the issuer provides the user with an issuance policy that consists of a presentation policy specifying which pseudonyms and/or existing credentials the user must present and of a credential template specifying which attributes or secret keys of the newly issued credential will be generated at random or carried over from credentials or pseudonyms in the presentation policy. In response, the user sends an issuance token containing a presentation token that satisfies the issuance policy. Then the (possibly multi-round) cryptographic issuance protocol ensues, at the end of which the user obtains the new credential.

Main Interactions

We describe below the interfaces that are exposed by the Privacy GE (through the ABC Engine) for the two main scenarios: issuance of a credential and authentication via a presentation token. The full specification of the Privacy GE can be found in the Open Specifications. The APIs are described in an object-oriented fashion as a list of methods that take input parameters of certain types and that produce an output of a certain return type. The data types of the input and return types either refer to XML artifacts as defined in the Open Specifications, or to simple XML Schema datatypes such as boolean or string.

Credential Issuance

Credential issuance is a multi-round interactive protocol between the issuer and the user, at the end of which the user obtains a new credential. In the simplest setting, an issuer knows all attribute values and issues credentials “from scratch”, i.e., without relation to any existing Privacy-ABCs already owned by the users. Prior to the issuance, the issuer may have obtained and verified all attribute values through an out-of-band process. In a more advanced setting, Privacy-ABCs can be issued so that certain features of the new credential are “carried over” from credentials that the user already owns, without the issuer being able to learn the carried-over information in the process. To do so, the issuer provides the user with an issuance policy, which consists of a presentation policy and a credential template. The sequence of a credential issuance interaction is illustrated in Figure 2.

Figure 2: Credential Issuance
Figure 2: Credential Issuance.

User side
issuanceProtocolStep(m:IssuanceMessage) → IssuanceMessage or CredentialDescription
This method performs one step in an interactive issuance protocol. On input of an issuance message m that is obtained from the issuer, it then either returns the outgoing issuance message that is to be sent back to the issuer, or returns a description of the newly issued credential at successful completion of the protocol. In the former case, the Context attribute of the outgoing message has the same value as that of the incoming message, allowing the issuer to link the different messages of this issuance protocol.
Issuer side
initIssuanceProtocol(ip:IssuancePolicy, atts:Attribute[]) → (IssuanceMessage, boolean)
This method is invoked by the issuer to initiate an issuance protocol based on the given issuance policy ip and the list of attribute type-value pairs atts to be embedded in the new credential. It returns an IssuanceMessage that is to be sent to the user. The IssuanceMessage contains a Context attribute that will be the same for all message exchanges in this issuance protocol, to facilitate linking the different flows of the protocol.
In case of an issuance “from scratch”, i.e., for which the user does not have to prove ownership of existing credentials or established pseudonyms, the given issuance policy ip merely specifies the credential specification and the issuer parameters for the credential to be issued. In this case, the returned issuance message is the first message in the actual cryptographic issuance protocol.
In case of an “advanced” issuance, i.e., where the user has to prove ownership of existing credentials or pseudonyms to carry over attributes or a user secret, the returned IssuanceMessage is simply a wrapper around the issuance policy ip with a fresh Context attribute. The returned boolean value indicates whether this is the last flow of the issuance protocol. If the IssuanceMessage is not the final one, the issuer will subsequently invoke its issuanceProtocolStep method on the next incoming IssuanceMessage from the user.
issuanceProtocolStep(m:IssuanceMessage) → (IssuanceMessage, boolean)
This method performs one step in an interactive issuance protocol. On input of an issuance message m received from the user, it then returns the outgoing issuance message that is to be sent back to the User, plus a boolean value indicating whether this is the last message in the protocol. The Context attribute of the outgoing message has the same value as the one from the incoming message, allowing the issuer to link the different messages of this issuance protocol.

Token Presentation

In a typical token presentation interaction, the user first requests access to a protected resource, upon which the verifier sends a presentation policy that describes which attributes from which credentials the user must choose to generate the proof required for access. The ABC Engine then checks whether it has the necessary credentials to satisfy the verifier's presentation policy, and if so, generates a presentation token containing the appropriate cryptographic evidence. Upon receiving the presentation token, the verifier checks that the cryptographic evidence is valid for the presented token and checks that this token satisfies the presentation policy. If both tests succeed, it grants access to the resource. The sequence of a token presentation interaction is illustrated in Figure 3.

Figure 3: Token Presentation
Figure 3: Token Presentation.

User side:
createPresentationToken(p:PresentationPolicyAlternatives) → PresentationToken
This method, on input of a presentation policy p, returns a presentation token that satisfies the policy p, or throws an exception if no such token could be created. This method will investigate whether the user has the necessary credentials and/or established pseudonyms to create a token that satisfies the policy. If there are multiple ways in which the policy can be satisfied (e.g., by satisfying different alternatives in the policy, or by using different sets of credentials to satisfy one alternative), this method will invoke an identity selection – possibly presented as a user interface (the executable code of which is installed on the user's machine as part of the ABCE framework) – to let the user choose her preferred way of generating the presentation token. This method will further invoke a user interface to ensure User consent to the information that will be revealed in the created token. If the policy cannot be satisfied, an exception is thrown.
Verifier side:
verifyTokenAgainstPolicy(p:PresentationPolicyAlternatives, t:PresentationToken, store:boolean) → PresentationTokenDescription
This method, on input of a presentation policy p and a presentation token t, checks whether the token t satisfies the policy p, and checks the validity of the cryptographic evidence included in token t. If both checks succeed and store is set to true, this method stores the token in a dedicated store and returns a description of the token that includes a unique identifier by means of which the token can later be retrieved from the store. If one of the checks fails, an exception is thrown and the verification errors are reported in the corresponding exception message.

Basic Design Principles

The Privacy GE consists of two main parts, the ABC Engine (ABCE) and the Crypto Engine. The ABCE contains all technology-agnostic methods and components for a Privacy-ABC system. That is, it contains, e.g., the methods to parse an obtained presentation policy, perform the selection of applicable credentials for a given policy or to trigger the mechanism-specific generation or verification of the cryptographic evidence. The ABCE is invoked by the application-layer and calls out the Crypto Engine to obtain the mechanism-specific cryptographic data.


The provided information is based on:

ABC4Trust H2.2 Patrik Bichsel, 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.

CDLNPP13 Jan Camenisch, Maria Dubovitskaya, Anja Lehmann, Gregory Neven, Christian Paquin, and Franz-Stefan Preiss, A language framework for privacy-preserving attribute-based authentication. In Proc. of IFIP IDMAN 2013.

Detailed Open Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

Open API Specifications

Other Open Specifications

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • Attack. Any kind of malicious activity that attempts to collect, disrupt, deny, degrade, or destroy information system resources or the information itself
  • Authentication protocol: "Over-the-wire authentication protocols are used to exchange authentication data between the client and server application. Each authentication protocol supports one or more authentication methods. The OATH reference architecture provides for the use of existing protocols, and envisions the use of extended protocols which support new authentication methods as they are defined." (OATH)
  • Access control: is the prevention of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner. (ITU-T-X-800_Link). More precisely, access control is the protection of resources against unauthorized access; a process by which use of resources is regulated according to a security policy and is permitted by only authorized system entities according to that policy. RFC 2828
  • Account: A (user) account is “typically a formal business agreement for providing regular dealings and services between principal sand business service providers.” OASIS Security Assertion Markup Language (SAML)
  • Authentication (AuthN): We adopted the following definition of authentication from RFC 3588"Authentication is “the act of verifying the identity of an entity (subject)”
TrustInCyberspace adds the term “level of confidence” to this definition:
Authentication is the process of confirming a system entity’s asserted identity with a specified, or understood, level of confidence.” This definition holds all necessary parts to examine authentication in broad sense. First of all it does not narrow the authentication to human users, but refers to a generic “system entity”. See authentication reference architecture description for a closer look at different identities that could be authenticated.
Secondly it introduces the often neglected concept of “level of confidence” which applies to each authentication of an identity. No computer program or computer user can definitely prove the identity of another party. There is no authentication method that can be secured against any possible identity-theft attack, be it physical or non-physical. It is only possible to apply one or more tests, which, if passed, have been previously declared to be sufficient to go on further. The problem is to determine which tests are sufficient, and many such are inadequate.
The original Greek word originates from the word 'authentes'='author'. This leads to the general field of claims and trust management, because authentication could also mean to verify the “author” / issuer of any claim.
The confirmation or validation process of authentication is actually done by presenting some kind of proof. This proof is normally derived from some kind of secret hold by the principal. In its simplest form the participant and the authentication authority share the same secret. More advanced concepts rely on challenge/response mechanisms, preventing the secrets to be transmitted. Refer to Authentication Technologies for a detailed list of authentication methods used today.
As stated above, each authentication method assures only some level of trust in the claimed identity, but none could be definite. Therefore it makes sense to distinguish the different authentication methods by an associated assurance level, stating the level of trust in the authentication process.
As this assurance level depends not only on the technical authentication method, but also on the overall computer system and even on the business processes within the organization (provisioning of identities and credentials), there is no ranking of the authentication methods here.
  • Countermeasures. Action, device, procedure, technique or other measure that reduces the vulnerability of an information system.
  • Cyber attack. An attack, via cyberspace, targeting an entity (industrial, financial, public...) and using cyberspace for the purpose of disrupting, disabling, destroying, or maliciously controlling a computing environment/infrastructure; or destroying the integrity of the data or stealing controlled information
  • Exploit. A program or technique that takes advantage of vulnerability in software and that can be used for breaking security, or otherwise attacking a host over the network
  • Federation: The term federation “is used in two senses - "The act of establishing a relationship between two entities. An association comprising any number of service providers and identity providers.” OASIS Security Assertion Markup Language (SAML)
“A federation is a collection of realms that have established a producer-consumer relationship whereby one realm can provide authorized access to a resource it manages based on an identity, and possibly associated attributes, that are asserted in another realm.
Federation requires trust such that a relying party can make a well-informed access control decision based on the credibility of identity and attribute data that is vouched for by another realm.” WS-Federation @ IBM
Remark: Federation according to WS-Federation @ IBM is similar to the concept of a Circle of Trust.
  • FI. Future Internet.
  • Forensics for evidence. The use of scientifically derived and proven methods toward the preservation, collection, validation, identification, analysis, interpretation, documentation and presentation of digital evidence derived from digital sources for the purpose of facilitating or furthering the reconstruction of events found to be criminal, or helping to anticipate unauthorized actions shown to be disruptive to planned operations.
  • Identity. In the narrow sense, identity is the persistent identifier of users (user name), things or services by which other parties “remember” them and, hence, are able to store or retrieve specific information about them and are able to control their access to different resources. In the wider sense, identity also covers further attributes of users, things and services; e.g. for users, such information may include personal information such as context, group membership and profile.
  • Identity (Digital): The term identity and its meaning have been discussed controversially in the “identity community” for many years. Until now, there is no commonly agreed definition of that notion. : : The IdM && AAA reference architecture applies the following three definitions of identity.
The Identity Gang defines the term digital identity as follows:
A digital identity is “a digital representation of a set of Claims made by one party about itself or another digital subject.”
The following comments were added:
A digital identity is just one set of claims about a digital subject. For any given digital subject there will typically be many digital identities.
A digital identity can be created on the fly when a particular identity transaction is desired or persistent in a data store to provide a representation that can be referenced.
A digital identity may contain claims made by multiple claimants.
A digital identity may be signed by a digital identity provider to provide assurance to a relying party.
This definition emphasizes two facts:
Normally, a principal (subject) has multiple digital identities or personas.
Identities are made out of attributes (claims).
Therefore, the scope of identity management in the reference architecture has two viewpoints: For once it focuses on identities and personas itself, and on the other side, it deals with the attributes of these identities and personas.
The Liberty Alliance Project (LAP) defines digital identity as follows:
Digital identity is “the essence of an entity. One’s identity is often described by one’s characteristics, among which may be any number of identifiers. A Principal may wield one or more identities.”
RSA uses the following definition of digital identity:
“Digital identity consists of an identity assertion and the characteristics, sometimes called attributes that are collected or observed through our computerized relationships. It is often as simple as a user name and password.”
The definition of RSA adds one important aspect to the identity discussion: Even the simplest user name and password combinations without any additional attributes or claims constitute an identity.
  • Identifier: Identifiers can be understood as a dedicated, publicly known attribute of an identity that refers to that identity only. Typically, identifiers are valid within a specific domain. Special types of identifiers are valid globally, due to the use of popular domain naming and resolution protocols such as DNS, which implies addressing capabilities to the identity. OASIS Security Assertion Markup Language (SAML) defines identifier as follows:
An identifier is “a data object (for example, a string) mapped to a system entity that uniquely refers to the system entity. A system entity may have multiple distinct identifiers referring to it. An identifier is essentially a "distinguished attribute" of an entity.”
  • Identity context: is “the surrounding environment and circumstances that determine meaning of digital identities and the policies and protocols that govern their interactions.” (Identity Gang)
  • Identity management (IdM): comprises “the management of identity information both internally and when it is passed from one entity to another.” Open Mobile Alliance (OMA)
  • Identity provider: The Open Mobile Alliance (OMA) defines the term identity provider (IdP) as follows - An identity provider is “a special type of service provider […] that creates, maintains, and manages identity information for principals, and can provide […] assertions to other service providers within an authentication domain (or even a circle of trust).”
Another notion defines identity provider as “an agent that issues a digital identity [that] is acting on behalf of an issuing Party.” (Identity Gang)
The following definition of identity provider descends from WS-Federation @ IBM: “An identity provider is an entity that acts as an authentication service to end requestors and as data origin authentication service to service providers […]. Identity providers are trusted (logical) 3rd parties which need to be trusted both by the requestor […] and the service provider which may grant access to valuable resources and information based upon the integrity of the identity information provided by the identity provider.”
The Identity Provider is part of the Identity Management infrastructure.
  • Impact. The adverse effect resulting from a successful threat exercise of vulnerability. Can be described in terms of loss or degradation of any, or a combination of any, of the following three security goals: integrity, availability, and confidentiality.
  • Partial identity: a partial identity is a set of attributes of a user. Thus, an identity is composed of all attributes of a user, a partial identity is a subset of a user's identity. Typically, a user is known to another party only as a partial identity. A partial identity can have a unique identifier. The latter is a strong identifier if it is allows for a strong authentication of the user (holder) of the partial identity, such a cryptographic "identification" protocol
  • Privacy: Dictionary definitions of privacy refer to "the quality or state of being apart from company or observation, seclusion [...] freedom from unauthorized intrusion" (Merriam-Webster online). In the online world, we rely on a pragmatic definition of privacy, saying that privacy is the state of being free from certain privacy threats.
  • Privacy threats. The fundamental privacy threats are: traceability (the digital traces left during transactions), linkability (profile accumulation based on the digital traces), loss of control (over personal data) and identity theft (impersonation).
  • Risk analysis. The process of identifying security risks, determining their magnitude, and identifying areas needing safeguards. An analysis of an organization's information resources, its existing controls, and its remaining organizational and MIS vulnerabilities. It combines the loss potential for each resource or combination of resources with an estimated rate of occurrence to establish a potential level of damage
  • Security monitoring. Usage of tools to prevent and detect compliance defaults, security events and malicious actions taken by subjects suspected of misusing the information system.
  • Service impact analysis. An analysis of a service’s requirements, processes, and interdependencies used to characterize information system contingency requirements and priorities in the event of a significant disruption.
  • Single sign-on: is “From a Principal’s perspective, single sign-on encompasses the capability to authenticate with some system entity—[…] an Identity Provider - and have that authentication honored by other system entities, [termed] Service Providers […]. Note that upon authenticating with an Identity Provider, the Identity Provider typically establishes and maintains some notion of local session state between itself and the Principal’s user agent. Service Providers may also maintain their own distinct local session state with a Principal’s user agent.” Liberty Alliance Project (LAP)
  • S&D: Security and Dependability
  • Threat. An event, process, activity being perpetuated by one or more threat agents, which, when realized, has an adverse effect on organization assets, resulting in losses (service delays or denials, disclosure of sensitive information, undesired patch of programs or data, reputation...)
  • USDL and USDL-Sec: The Unified Service Description Language (USDL) is a platform-neutral language for describing services. The security extension of this language is going to be developed FI-WARE project.
  • Vulnerability. A weakness or finding that is non-compliant, non-adherence to a requirement, a specification or a standard, or unprotected area of an otherwise secure system, which leaves the system open to potential attack or other problem.
  • WADL. The Web Application Description Language is a machine-readable XML description of HTTP-based web applications used typically with REST web services.
  • WS-SecurityPolicy: It is an extension to SOAP to apply security to web services. It is a member of the WS-* family of web service specifications and was published by OASIS.
  • The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as SAML, Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security.
Personal tools
Create a book