OASIS Identity Based Attestation and Open Exchange Protocol Specification (IBOPS) TC

One of our highest priorities in the information security field is the development of techniques to confirm that a person accessing online resources is who he claims to be. Simply stated, a person must be able to validate its identity before it is allowed to gain access to information, otherwise access to a resource should be denied.

Many recent enterprise level security breaches have been made by hackers with the aim to gain access to sensitive information. Such attacks have enhanced the awareness for the need for better authentication methods and means for protecting identity information to prevent crime and fraud at all levels.

There are five categories of authentication methods used by resource owners: 1) something you have, 2) something you know, 3) something you are, 4) something you do and 5) the context of your interaction. One of the most used authentication methods in today’s online systems belongs to the “something we know” category and is generally based on user name and password. A more sophisticated method of authentication for example, can be based on “something we have” category such as smart cards or tokens; these are not widely adopted due to cost and other factors.

In order to capitalize on strong authentication as a service types deployment, many countries are working towards establishing trust-based identity systems to enable the use of stronger authentication among relying parties across the identity landscape. Federation technologies, coupled with national and industry-specific trust frameworks, are emerging as a viable solution to capitalize on emerging stronger methods of authentication.

Until recently, the use of biometrics technology was resource intensive. However, the advent of smart phones, smart watches and mobile devices that include sensors (such as cameras, fingerprint scanners, and microphones, and GPS) has made it feasible and affordable to use biometrics for identification and authentication for online access. Biometrics Recognition systems can identify users based on either physiological or behavioral characteristics along with contextual information.

The demand for the ease and reliability offered by biometrics is growing. Individuals have password fatigue and tend to reuse passwords across many sites, which add to the risk of identity theft and fraud. At present, biometrics technology holds a great deal of promise as the solution the industry has been searching for.

Biometric technologies can potentially provide consumers with a long-awaited convenience to securely enter into the cyberspace using unique biological traits rather than user name and password combinations. The traits can be stored directly on the device or stored at the server. The Fast Identity Online (FIDO) Alliance is developing methods using universal authenticators that can support biometric methods that are local to a device and enable them to be used for strong authentication. There are other use cases, however, that require the enterprise or provider to store the biometric information on local servers either in addition to local clients or as an alternative to provide enhanced authentication solutions. These are the use cases that IBOPS is intended to address.

The goal of this Technical Committee is to develop the Identity-Based Attestation and Open Exchange Specification (IBOPS) with the aim to protect digital assets and digital identities on the client, server and the data exchange in-between. The TC will also develop a set of APIs that can be used by applications to interact with servers that store biometric information locally. IBOPS will define a standard API to be used by application developers to interact with such servers. The IBOPS communication architecture will run on any secure protocol such as Transport Layer Security (TLS) connections over the encryption mechanism to servers that hold identity data. IBOPS will not compete with other standards such as FIDO, since IBOPS is designed to address use cases that require the relying party to have access to biometric or other identity information.

The IBOPS standard will allow systems to meet security needs by using the IBOPS API coupled with the use of appropriate security concepts. In particular, IBOPS works with the assumption that security is accomplished by securing the identity data at the server, in transit, and on the device. The working assumption here is a hack of the central server will only compromise the data of one entity, thus a hacker would need to break the IBOPS system one user at a time before obtaining access to mass data.

The IBOPS functionality will offer developers the ability to use appropriate security to systems in development. IBOPS may be used as the sole security mechanism or it may be used in conjunction with other mechanisms, such as SAML.

IBOPS does not prevent the use of biometric or authentication work that is being developed or has been developed in other standardization bodies. In particular, IBOPS will adopt the authentication assurance concepts and principles as developed in ISO/IEC 29115, ITU-T X.1254 and OASIS Trust Elevation Specifications, and OASIS Biometric Identity Assurance Services (BIAS).

IBOPS will also reference best practices documents for Biometric-with-Mobile devices such ISO/IEC TR 30125, as the goal of IBOPS is to secure biometric data by eliminating the need for storing images on local devices or servers.

As such, IBOPS will not conflict or replace standards such as ISO/IEC 19794, (Biometric data interchange formats) or ISO/IEC 19785 (Common Biometric Exchange Formats Framework) or ISO/IEC 19795 (Biometric performance testing and reporting), ISO/IEC 24761:2009 (Authentication context for biometrics), ISO 19092:2008, (Financial services, Biometrics. Security framework)

IBOPS interoperability requires IBOPS to function through the IBOPS API, allowing pluggable components for Identity Assertion, Role Gathering, Access Control, Assurance, and Storage. Any tool using any implementation may “plug” into any IBOPS-enabled server and continue conversational input for secure access.

The TC will develop the IBOPS specification to enable security systems to provide Identity Assertion, Role Gathering, Multi-Level Access Control, Assurance, and Auditing capabilities. IBOPS will define how software running on a client device can communicate with an IBOPS-enabled server. Methods for enabling security components to work with existing IBOPS components for integration into current operating environments will also be considered.

The TC will develop IBOPS specification with the aim of providing continuous protection of identity resources in a manner that enables defining of mechanisms that ensure security to a given service level guarantee of security.

IBOPS will allow systems to meet security needs by interacting with an API through a secure protocol and architecture that is RESTful and is language neutral. To facilitate maximum interoperability, all tools used and resulting IBOPS deliverables will adhere to open standards. Interoperability and conformance criteria will be clearly defined and developed in the TC Specifications.

The scope does not consider the “how” of the standard. The specification shows the “what” and is independent of implementation.

• A use case and gap analysis document that depicts the problems that IBOPS is addressing.
• An end-to-end specification describing the standards necessary to perform server-based enhanced biometric security. This solution will consider enrollment phase, maintenance, storage, and revocation. Version 1.0 of the specification should be completed within 18 to 24 months of the first meeting.
• The TC might also develop interoperability profiles for OASIS Trust Elevation Protocol, FIDO, SAML, Open ID Connect and OAuth if deemed appropriate by the TC.
• The TC may produce other deliverables as interoperability testing tools, tutorials, presentations, best practices, or non-normative definitions to be used for testing, as the TC may deem useful to implementers of the standard.

This TC will operate under the Non-Assertion IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy effective 21 June 2012.

Security evaluators, system underwriters, developers, and systems engineers will all benefit from IBOPS. For those wishing to underwrite an application, IBOPS will provide a mechanism that if adhered to, will ensure risk mitigation. Adhering to IBOPS removes the “how to” for adjudicators, developers, administrators, and managers. Simply adopting IBOPS and adhering to its rules will mitigate security risk.

The audience for creating and considering IBOPS includes developers, system engineers, and adjudicators.

The IBOPS TC operates and publishes its work products in English.