OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tc-announce message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Proposed Charter for OASIS Biometric Open Protocol (BOPS) TC


OASIS Members:

A draft TC charter has been submitted to establish the OASIS Biometric Open Protocol (BOPS) TC. In accordance with the OASIS TC Process Policy section 2.2: (https://www.oasis-open.org/policies-guidelines/tc-process#formation) the proposed charter is hereby submitted for comment. The comment period shall remain open until 23:59 GMT on 21 July 2014.

OASIS maintains a mailing list for the purpose of submitting comments on proposed charters. Any OASIS member may post to this list by sending email to: oasis-charter-discuss@lists.oasis-open.org. All messages will be publicly archived at: http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to receive emails must join the group by selecting "join group" on the group home page: http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees of organizational members do not require primary representative approval to subscribe to the oasis-charter-discuss e-mail.

A telephone conference will be held among the Convener, the OASIS TC Administrator, and those proposers who wish to attend within four days of the close of the comment period. The announcement and call-in information will be noted on the OASIS Charter Discuss Group Calendar.

We encourage member comment and ask that you note the name of the proposed TC (BOPS) in the subject line of your email message.

--- TC CHARTER 

Section 1: Charter

(1)(a) TC Name 

OASIS Biometric Open Protocol (BOPS) TC

(1)(b) Statement of Purpose  

One of our highest priorities in the information security field is the development of techniques to confirm that a person accessing online resources is authorized and allowed to do so. Simply stated, an entity must be able to validate its identity before accessing information, otherwise access to a resource should be denied. 

Much of the recent enterprise-level security breaches have been made by hackers with targeted activities to steal clients’ information for fraud and identity theft. This trend has enhanced awareness for the need for better authentication methods 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 based on the user name and password or other personal information. A more sophisticated method of authentication relates to “something we have” such as smart cards and tokens; these are not widely adopted due to cost and other factors.

At the national level, 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 weaker methods of authentication based on user name and password.   

Until recently, the “something that we are” authentication method, such as 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) has made it feasible and affordable to use biometrics for identification and authentication for online access. Biometrics systems can identify users based on either physiological or behavioral characteristics.

The demand for the ease and reliability offered by biometrics is growing. Consumers want security systems in place that prevent unauthorized access to their personal data. They are also concerned about having their identities stolen and used by thieves. 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--but it is not without its limitations and certainly not without its critics.

Biometric technologies 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 Alliance (FIDO) 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. On the other hand, there are some use cases that require that the enterprise or the provider to store the biometric information on local servers in order to provide enhanced biometric solutions.

This goal of this Technical Committee is to develop the Biometric Open Protocol Standard (BOPS) with the aim to protect digital assets and digital identities on the server.  The server may be any type of hardware running on a private or public network. BOPS will define a biometrics-agnostic standard API for registered developers.  The BOPS communication architecture will run on any secure protocol such as Secure Socket Layer (SSL) or Transport Layer Security (TLS)) connections over the encryption mechanism to servers that employ Intrusion Detection Systems (IDS). BOPS assume that the server will be protected against threats and attacks.  BOPS will not compete with other standards like FIDO, since BOPS is designed to address use cases that require the relying party to have access to biometric information.

The BOPS standard will allow systems to meet security needs by using the BOPS API. The BOPS functionality will offer a “point and cut” mechanism to add the appropriate security to the production systems as well as to the systems in development.  By point and cut, we mean that BOPS may be used as the sole security mechanism or it may be used in conjunction with other mechanisms, such as SAML or Active Directory.  

(1)(c) Scope  

The TC will develop the BOPS standard to enable biometric security systems that provide Identity Assertion, Role Gathering, Multi-Level Access Control, Assurance, and Auditing.   BOPS will define how software running on a client device (Android, iPhone, etc.) communicates with a trusted BOPS server. Methods for enabling security pluggable components to work with existing BOPS component functionality and its support for integration into current operating environments in a short period of time will also be considered.  

The TC will develop the BOPS standard in such a way as to provide continuous protection of resources and to assure the placement and viability of adjudication and other key features. Accountability will also be defined as the mechanism that proves a service level guarantee of security.  

BOPS will allow systems to meet security needs by using the API. The BOPS architecture will be language-neutral, allowing REST, JSON, and Secure Socket Layers to provide the communication interface.  The architecture will be built on the servlet specification, open secure socket layers, Java, JSON, REST, and Apache Solr.  To facilitate maximum interoperability, all tools used will adhere to open standards.

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

(1)(d) Deliverables  

1. The deliverable is an end-to-end specification describing the standards necessary to perform server-based biometric security. This solution will consider pluggable initial setup for a user called genesis or enrollment. The first end-to-end specification will be completed within 18 months of the first meeting. 
   * The solution offers the minimum criteria necessary for liveness (determining if the user is live and not a facsimile). It prevents replay and the use of compromised devices.  The delivery includes all RESTFul calls and the criteria necessary for Intrusion Detection.  
   * Development of Interoperability profiles for OASIS Trust Elevation Protocol, FIDO, SAML, Open ID Connect and OAuth if deemed appropriate by the TC

2. The TC will produce other deliverables as tutorials, presentations, best practices, or non-normative definitions to be used for testing, as the TC may deem useful to implementers of the standard. 

(1)(e) IPR Mode  

This TC will operate under the RF on Limited Terms IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy effective 21 June 2012. 

(1)(f) Audience  

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

The audience for creating and considering BOPS includes developers, system engineers, and adjudicators.  The audience considers the assumption of risk as key pertains to software running a BOPS implementation.    

(1)(g) Language  

English

Section 2: Additional Information

(2)(a) Identification of Similar Work  

None. However, the TC will work closely with the ITU-T SG 17, ISO, FIDO and other bodies. The TC intends to further standardize the work in ITU-T and ISO.

(2)(b) First TC Meeting  

The first meeting will be held 24 September 2014 in Geneva at a location and time to be determined. The meeting will be face-to-face. Hoyoslabs will sponsor the first meeting. 

(2)(c) Ongoing Meeting Schedule 
 
The TC will meet bi-weekly by teleconference and hold fact-to-face meetings as needed. Sponsorship of the meetings will rotate among the members. 

(2)(d) TC Proposers  

Scott Streit, scott@scottstreit.com, Villanova University
Abbie Barbir, abbie.barbir@bankofamerica.com, Bank of America
Liz Votaw, liz.votaw@bankofamerica.com, Bank of America
Eileen Bridges, eileen.bridges@innovate.bankofamerica.com, Bank of America
Don Thibeaux, don.thibeau@openidentityexchange.org, Open Identity Exchange
Gill, Davindar, davindar.gill@bankofamerica.com, Bank of America
Hector Hpyos,  hhoyos@hoyoslabs.com , HOYOS Labs Corp 
Anil Saldhana,  anil.saldhana@redhat.com, Red Hat, 
Shahrokh Shahidzadeh, shahrokh.shahidzadeh@intel.com, Intel

(2)(e) Statements of support  

Abbie Barbir, abbie.barbir@bankofamerica.com, Bank of America: As Bank of America’s Primary Representative, I approve the BOPS TC Charter and support our proposers Abbie Barbir, Liz Votaw, Eileen Bridges, and Gill, Davindar as a named co-proposers.

Scott Streit,scott@scottstreit.com, Villanova University: As Villanova University’s Primary Representative, I approve the BOPS TC Charter and agree to have my name as a named co-proposer.

Don Thibeau, don@oidf.org, Open Identity Exchange: As Open Identity Exchange’s primary representative I approve the BOPS TC Charter and agree to have my name as co-proposer.

Hector Hoyos, hhoyos@hoyoslabs.com, as HOYOS Labs Corp primary representative I approve the BOPS TC Charter and agree to have my name as co-proposer.

I Mark Little, mlittle@redhat.com, Red Hat: As Red Hat’s" Primary Representative, I approve the BOPS TC Charter and support our proposer Anil Saldhana as a named co-proposers.

I, Shahrokh Shahidzadeh, shahrokh.shahidzadeh@intel.com, Intel, as Intel’s Primary Representative, I approve the BOPS TC Charter, and agree to have my name as  a named co-proposer.

(2)(f) Convener 

Abbie Barbir of Bank of America will be the convener.

(2)(g) Member Section Affiliation 

The TC intends to request affiliation with the IDTrust Member Section. 


--

/chet 
----------------
Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393 

Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html 

TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin

Follow OASIS on:
LinkedIn:    http://linkd.in/OASISopen
Twitter:        http://twitter.com/OASISopen
Facebook:  http://facebook.com/oasis.open


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]