OWASP Knowledge Based Authentication Performance Metrics Project

=Main=



{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 * valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

The KBAPM Project
There is a lack of standard performance metrics regarding the use of knowledge based authentication (KBA) for remote identity proofing. KBAPMP's goal is to establish standard performance metrics for knowledge based authentication.

What is Knowledge Based Authentication?
Knowledge Based Authentication (KBA) is much more complex than the following description from Wikipedia might lead one to expect. In order to establish reliable and standard performance metrics these complexities will need to be identified and addressed.

From Wikipedia— "Knowledge-based authentication, commonly referred to as KBA, is a method of authentication which seeks to prove the identity of someone accessing a service, such as a website. As the name suggests, KBA requires the knowledge of personal information of the individual to grant access to the protected material. There are two types of KBA: "static KBA", which is based on a pre-agreed set of "shared secrets"; and "dynamic KBA", which is based on questions generated from a wider base of personal information."

KBAPM Project Supports the NSTIC Guiding Principles
KBAPM Project is dedicated to developing KBA Standards in alignment the the NSTIC Guiding Principle. To that end KBAPM Project has answered the IDESG Standards Committee Solicitation to develop Knowledge Based Authentication Performance Metrics Standards.

The IDESG, its components, and its members shall at all times operate in accordance with four Guiding Principles set forth in the NSTIC. They are:

1. Identity solutions will be privacy-enhancing and voluntary.

The Identity Ecosystem will be grounded in a holistic, integrated implementation of the Fair Information Practice Principles to promote the creation and adoption of policies and standards that are privacy-enhancing, including the preservation of the capacity to engage in anonymous and pseudonymous activities online. Ideally, identity solutions within the Identity Ecosystem should preserve the positive privacy benefits associated with offline identity-related transactions while mitigating some of the negative privacy aspects. Finally, participation in the Identity Ecosystem will be voluntary: the government will neither mandate that individuals obtain an Identity Ecosystem credential nor that companies require Identity Ecosystem credentials from consumers as the only means to interact with them. Individuals shall be free to use an Identity Ecosystem credential of their choice, provided the credential meets the minimum risk requirements of the relying party, or to use any non-Identity Ecosystem mechanism provided by the relying party. Individuals’ participation in the Identity Ecosystem will be a day-to-day—or even a transaction-to-transaction—choice.

2. Identity solutions will be secure and resilient.

Identity solutions within the Identity Ecosystem will provide secure and reliable methods of electronic authentication by being grounded in technology and security standards that are open and collaboratively developed with auditable security processes. Credentials within the Identity Ecosystem are: issued based on sound criteria for verifying the identity of individuals and devices, when appropriate; resistant to theft, tampering, counterfeiting, and exploitation; and issued only by providers who fulfill the necessary requirements. Identity solutions must detect when trust has been broken, be capable of timely restoration after any disruption, be able to quickly revoke and recover compromised digital identities, and be capable of adapting to the dynamic nature of technology.

3. Identity solutions will be interoperable.

Interoperability encourages and enables service providers to accept a wide variety of credentials and enables users to take advantage of different credentials to assert their identity online. Two types of interoperability are recognized in the Identity Ecosystem: technical interoperability is the ability for different technologies to communicate and exchange data based upon well-defined and testable interface standards; policy-level interoperability is the ability for organizations to adopt common business policies and processes.

4. Identity solutions will be cost-effective and easy to use.

The Identity Ecosystem will promote identity solutions that enable individuals to use a smaller number of identity credentials across a wide array of service providers. These identity solutions must be cost-effective for users, identity and attribute providers, and relying parties. Furthermore, identity solutions should be simple to understand, intuitive, easy-to-use, and enabled by technology that requires minimal user training.

Licensing
Creative Commons Attribution ShareAlike 3.0 License


 * valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

Project Leaders

 * [mailto:luis.enriquez@owasp.org Luis Enriquez]
 * [mailto:ann.racuya.robbins@owasp.org Ann Racuya-Robbins]

Project Manager

 * [mailto:ann.racuya.robbins@owasp.org Ann Racuya-Robbins]

Join our Mailing List
Mailing List

Monday January 26, 2015 at 11:00 AM US Eastern Time
Our Meetings are Open and All are Welcome to Attend

Previous Meeting Minutes []

AGENDA
Welcome


 * Discussions:
 * IDESG KBAPM Project Responses
 * Draft Project Policies Update
 * Outreach to KBA Providers and other Stakeholders


 * Ongoing:
 * International Participants
 * Discuss and Document Tools/Ways Update
 * Information Management Update
 * Blog Article Update
 * Application to Conference in Amsterdam Update
 * https://2015.appsec.eu/call-for-papers/
 * https://2015.appsec.eu/call-for-research/


 * Take aways: Tasks
 * Schedule next meeting
 * Adjourn

WHERE
GoToMeeting https://www3.gotomeeting.com/join/642177878 Access Code: 642-177-878

2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. Dial +1 (571) 317-3112 Audio PIN: Shown after joining the meeting Meeting ID: 642-177-878 GoToMeeting® Online Meetings Made Easy® Not at your computer? Click the link to join this meeting from your iPhone®, iPad® or Android® device via the GoToMeeting app

Related Projects
OWASP Security Labeling System Project



OWASP NIST NSTIC Initiative

KBAPM Project Metrics
https://www.openhub.net/accounts/KBAOpenHub A performance metrics tool for the KBAPM Project

Classifications

 * }

=FAQs=

How can I participate in your project?
All you have to do is make the Project Leader's aware of your available time to contribute to the project. It is also important to let the Leader's know how you would like to contribute and pitch in to help the project meet it's goals and milestones. There are many different ways you can contribute to an OWASP Project, but communication with the leads is key.

If I am not a programmer can I participate in your project?
Yes, you can certainly participate in the project if you are not a programmer or technical. The project needs different skills and expertise and different times during its development. Currently, we are looking for researchers, writers, graphic designers, and a project administrator.

= Acknowledgements =

Contributors
= Road Map and Time Line =

OWASP KBAPMP - Knowledge Based Authentication Performance Metrics Project

Goals - To meet the requirements of the IDESG KBA Solicitation:

KBA PROJECT PHASES (PROPOSAL) Dear KBA collegues, we propose an action plan divided in the following phases:

FIRST PHASE: SCANNING THE MARKET The goal of this first phase, is to understand how KBA is working today (static and dynamic), and how KBA methodologies have been implemented by KBA providers. I think this a good departure point.
 * 1. Footprinting the KBA market providers.
 * 2. Identifying the KBA product providers used by the main market players.
 * 3. Identifying the advantages and drawbacks of KBA provider's methodology.
 * 4. Draw the document's structure.
 * Complete document structure v1
 * 5. Initial Timeline
 * 5. Launch Participant Outreach

SECOND PHASE: DEVELOPMENT Once the advantages and drawbacks of the KBA market have been clearly identified, it would be necessary to have our own plattform for testing purposes. This will give us the right perspective about developing a transnational, neutral, secure, and market wise KBA standard. I would also suggest building an open wiki, to get community feedback.
 * 1. Setting an Application for KBA testing purposes.
 * 2. Build an open wiki for community feedback.
 * 3. Test the KBA proposals in our test application.
 * 4. Analyzing the framework in crucial legal areas (such as Dynamic KBA and privacy).

THIRD PHASE: EDITION This phase is very important, as it concerns the text edition. Once all proposals have being tested in our lab, we should translate them into a clear document.
 * 1. Edit the contents of the sources (sources such as the wiki).
 * 2. Release the version 1.0. and license it under the terms of a suitable license.

Initial Overview
 * 1) Survey and research the Global OWASP Community and other networks to identify and recruit appropriate participation.
 * 2) Develop Opinion polls, foundations' research, interviews, perspectives on project, input from communities outside of the networks.
 * 3) Survey and research other standards groups and their interests.
 * 4) Phase I footprinting
 * 5) Phase II Development
 * 6) Phase III Implementation, Lessons Learned, Continuous refinement, Ongoing participation model, etc.
 * 7) Research Licensing models //