requirements development & template presentation to all chairs 8/12/2014

Requirements Development & Template

Presentation to All Chairs8/12/2014

Objectives

• Clarify the intent and purpose of Identity Ecosystem Framework Requirements

• Discuss potential approaches to requirements development

• Introduce and discuss the requirements catalog template

Agenda

• Overview• Development Considerations• Proposed Requirements Catalog Template• Proposed Requirements Development

Lifecycle• Questions/Additional Items

Requirements Overview• Requirements are a foundational component of the Identity Ecosystem

Framework intended to:– define a baseline for participation in the Identity Ecosystem

• What is the baseline? Improving the security, privacy, usability, and interoperability of everyday online transactions

• What benefits could the everyday consumer see if this baseline was established? (e.g., reduced account compromise through increased use of multifactor authentication; greater user control through notice, consent requirements; etc.)

– provide the foundation for the compliance/conformance program.• I.E., to be part of the NSTIC inspired, IDESG defined ecosystem your

organization must/should do A,B, and C with respect to security, privacy, interoperability, and usability

• These will be the basis for a future trustmark(s)

Requirements Overview

• The requirements are:– Discrete statements of activities, behaviors, and expectations for the

various participants that are to be part of the identity ecosystem as envisioned in the NSTIC

• These requirements are not:– Business requirements– Software/technology/solution design requirements

• The IDESG is not building a specific identity solution or technology—but instead setting the general parameters, based on the Guiding Principles, in which solutions will operate

• May help shape and contribute to these other requirement types for future participants in the ecosystem

Requirements Overview: Goals for 2014

• Develop requirements for all 4 guiding principles

• Establish an initial self-assessment and attestation compliance program– Assessment and attestation will be to applicable

requirements

2014 Development Considerations

• Requirements should be ecosystem level requirements—not specific to sectors, communities, or technologies– Should not dictate specific solutions

• Should take into account the core operations of the functional model and the roles—specifically at the functional element layer– Some requirements may apply to more than one

role, core operation, or function

Development Considerations: Criteria

• Should be relevant; should be tied to the four Guiding Principles, the NSTIC, and the establishment of the identity ecosystem

• Should be realistic; Potential participants should be capable of achieving conformance with these requirements without excessive technological or policy development time (i.e., quantum crypto should not be a requirement…)

• Should be balanced; taking into account the need to establish and maintain a marketplace while also preserving the NSTIC Guiding Principles

• Should be measurable; participants should be able to clearly state compliance through a binary or measurable response

• Should be technology agnostic; requirements should not specify or mandate a specific type of technology or solution and should be able to be met by multiple means (i.e., different technical solutions or combinations of tech and policy)

Development Considerations: Examples

• Ecosystem participants follow an adopted IDESG information security standard– Is it relevant to the identity ecosystem? Yes, all ecosystem participants should

operate according to a strong, recognized set of information security principles, practices, and processes

– Is it realistic? Yes, most organizations that handle customer or individual data already (or should) follow established information security standards or frameworks; implementing or using an IDESG adopted standard should not require an “excessive” shift in policy—though this will require IDESG to identify and adopt existing standards and frameworks in a timely manner

– Is it balanced? Yes, the use of strong information security standards will only enhance the delivery of services and expansion of the market place

– Is it measurable or binary? Yes, participants can clearly and easily state whether or not they follow an adopted standard

– Is it technology agnostic? Most core information security standards do not specify solutions or technology types

Development Considerations: Examples

• Ecosystem participants provide and/or technically support the use of multi-factor authentication solutions.– Is it relevant to the identity ecosystem? Yes, all ecosystem participants

should provide strong, multi-factor authentication options– Is it realistic? Yes, there are a significant number of existing multi-factor

solutions in different forms and technologies; integration with these should not be excessive for ecosystem participants

– Is it balanced? Yes, the need for strong, multi-factor authentication options is the primary driver behind the NSTIC and should only improve market growth and delivery of services

– Is it measurable or binary? Yes, organizations can clearly and easily state whether or not they provide users access to multi-factor authentication options

– Is it technology agnostic? Yes, no specific form or technology is included in the requirements

Development Considerations: Artifacts and Resources

• Many artifacts support requirements development:– The NSTIC; is the cornerstone of IDESG and essential

guidance for requirements– Derived Requirements; a set of requirements statements

derived from the NSTIC intended to stimulate requirements development

– Existing standards, frameworks, and compliance programs; for example PCI-DSS, FICAM, ISO/IEC 27001 provide fertile ground for identification of potential ecosystem requirements

– Pilot and operational experience; engage the pilots as participants in the development process

Development Considerations: Language and Structure

• Shall vs should, etc.:– Committee judgment matters: if it’s required, shall is

likely appropriate. Use may or should appropriately• If/then/else:– The fewer conditionals the better, but if needed, use

them• Hierarchical/sub-requirements:– This probably makes sense in some contexts, but this

should be determined by the needs of the chairs. If committees need conditionals, use them.

Development Approach: Privacy Committee

• Privacy Committee has initiated requirements development• Started with the Derived Requirements

– Refined and updated to use as “guidance” – Creating more granular requirements based on the derived requirements

and committee feedback; referring to these internally as “functional requirements”

• Incorporated several NSTIC pilots into the discussion to provide input

• Goal will be a set of requirements for incorporation into the identity ecosystem framework—the initial set may be updated, augmented, and added to as the framework matures

• Security committee is currently considering a similar approach for their own requirements development

Proposed Requirements Catalog Matrix• Will be provided to the committees as a template that is intended to:

– Capture requirements in a common format– Allow for consistent approaches, language, and structure

• Must think of these from the point of view of those who will need to consume these – Provides a uniformity and a foundation for the compliance program and

ultimately trustmarks– Once IDESG requirements have been established they can then be compared

to existing Trust Frameworks and Trust Framework Provider requirements; laying the foundation for streamlined self-assessment and future accreditation programs

• All information contained in the sample version of the matrix is for ILLUSTRATIVE PURPOSES ONLY

IDESG Requirements Catalog

# Guiding Principle Requirement statement

Applies to

Source (Std., derived requirements,

framework, etc.)

Standard or Reference

(spec, profile, etc.)

Specific control(s), criteria, or additional info (Optional)

Establishing Committee Last Modified Date ApprovedRegist

rationCredentiali

ng

Authentication

Authorizat

ion

Transactio

n Intermediation

1 Secure and Resilient

Ecosystem participants follow an adopted IDESG information security

standardX X X X X None ISO 27001

Certification None Identified Security Committee 7/28/2014 7/29/2014


Ecosystem participants provide and/or technically support the use of multi-

factor authentication solutions.X X X None FIDO U2F

specification None Identified Security Committee 7/28/2014 7/29/2014


Ecosystem participants utilize credentials that are resistant to theft, tampering,

counterfeiting, and exploitation.X X

Modified from NSTIC Derived Requirements

FICAM Trust Framework

Solution (TFS) Trust

Framework Provider Adoption

Process (TFPAP) V 2.0

Trust Criteria:The authentication process shall

resist online guessing threat.The authentication process shall

resist replay threat.The authentication process shall

resist session hijacking threat.The authentication process shall

resist eavesdropping threat. The authentication process shall at

least weakly resist man-in-the-middle threat.

Security Committee 7/28/2014 7/29/2014

4 Privacy Enhancing

Ecosystem participants determine the necessary quality of data used in identity assurance solutions based on the risk of

that transaction, including to the individuals involved

XModified from NSTIC Derived Requirements

None None Identified Privacy Committee 7/28/2014 7/29/2014

5 InteroperableEcosystem participants utilize an

adopted IDESG standards and protocols for the exchange of identity data

X X X X XModified from NSTIC Derived Requirements

Fido U2F Specification

SAML 2.0None Identified Standards

Committee 7/28/2014 7/29/2014

Proposed Requirements Catalog Matrix



Applies to


framework, etc.)





rationCredentiali

ng

Authentication

Authorizat

ion

Transactio

n Intermediation
























4 Privacy Enhancing










Committee 7/28/2014 7/29/2014


The NSTIC Guiding Principle that most closely relates to the requirement; there may be more than one

1



Applies to


framework, etc.)





rationCredentiali

ng

Authentication

Authorizat

ion

Transactio

n Intermediation
























4 Privacy Enhancing










Committee 7/28/2014 7/29/2014


2A concise statement of the requirement (those contained in this document are for illustrative purposes only)



Applies to


framework, etc.)





rationCredentiali

ng

Authentication

Authorizat

ion

Transactio

n Intermediation
























4 Privacy Enhancing










Committee 7/28/2014 7/29/2014


3 The core operations to which the requirement applies (may be one or many); will be hyperlinked to a separate page that lists the functions and definitions of each core operation (registration shown below)

Function Definition

ApplicationProcess by which an entity or agent requests initiation of registration.

Attribute ControlProcess of managing and releasing attributes for the purposes of registration or authorization.

Attribute VerificationProcess of confirming or denying that claimed identity attributes are correct and meet the pre-determined requirements for accuracy, assurance, etc.

Elligibility DecisionDecision that an entity does or does not meet the pre-determined eligibility requirements for a digital identity or credential.

Updates

Process by which an entity updates accounts, attributes, credentials, and other identity information to determine eligibility for an entitlement; may be periodic in nature or event based (e.g., marriage, end of subscription, etc.)

Registration:Process that establishes a digital identity for the purpose of issuing or associating a

credential.



Applies to


framework, etc.)





rationCredentiali

ng

Authentication

Authorizat

ion

Transactio

n Intermediation
























4 Privacy Enhancing










Committee 7/28/2014 7/29/2014


4 Source of the requirement (if adapted from an existing document)



Applies to


framework, etc.)





rationCredentiali

ng

Authentication

Authorizat

ion

Transactio

n Intermediation
























4 Privacy Enhancing










Committee 7/28/2014 7/29/2014


5Candidate standards, protocols, or profiles that can be used to fulfill the stated requirement or referenced to illustrate conformance with the requirement; not all requirements will have existing standards (etc.) to reference



Applies to


framework, etc.)





rationCredentiali

ng

Authentication

Authorizat

ion

Transactio

n Intermediation
























4 Privacy Enhancing










Committee 7/28/2014 7/29/2014


A specific control or additional detail from an existing standard, protocol, or specification that can be used to further illustrate conformance with the stated requirement

6



Applies to


framework, etc.)





rationCredentiali

ng

Authentication

Authorizat

ion

Transactio

n Intermediation
























4 Privacy Enhancing










Committee 7/28/2014 7/29/2014


7 8The establishing committee, date the requirement was last modified, and the date the document was last approved

9

Proposed Requirements Lifecycle

• Provides a high level over view of a potential approach to creating, consolidating, approving, and refreshing Identity Ecosystem Framework Requirements


PrivacyCommittee

Security Committee

UX Committee

Standards Committee

TFTMConsolidates

Self-Assessment and Attestation Program

Requirements “Catalog”

Produces

Identify

Adopted Standards

Requirements

Standards

Develops


2014 Identity Ecosystem Framework


Periodic Review and Update

Standards Committee

Consolidates

Plenary Approval Process

Standards Adoption Process

Functional Model

Functional Model

Dev

elop

s

Informs

Info

rms

Met w

ith

Sour

ce o

f

PrivacyCommittee

Security Committee

UX Committee

Standards Committee

TFTMConsolidates



Produces

Identify

Adopted Standards

Requirements

Standards

Develops





Standards Committee

Consolidates



Functional Model

Functional Model

Dev

elop

s

Informs

Info

rms


1

Committees produce requirements1

Met w

ith

Sour

ce o

f

PrivacyCommittee

Security Committee

UX Committee

Standards Committee

TFTMConsolidates



Produces

Identify

Adopted Standards

Requirements

Standards

Develops





Standards Committee

Consolidates



Functional Model

Functional Model

Dev

elop

s

Informs

Info

rms


2

TFTM consolidates committee requirements2

Met w

ith

Sour

ce o

f


TFTM produces self assessment documentation (questionnaire, assessment criteria, etc.) and requirements catalog

3

PrivacyCommittee

Security Committee

UX Committee

Standards Committee

TFTMConsolidates



Produces

Identify

Adopted Standards

Requirements

Standards

Develops





Standards Committee

Consolidates



Functional Model

Functional Model

Dev

elop

s

Informs

Info

rms

3

Met w

ith

Sour

ce o

f

PrivacyCommittee

Security Committee

UX Committee

Standards Committee

TFTMConsolidates



Produces

Identify

Adopted Standards

Requirements

Standards

Develops





Standards Committee

Consolidates



Functional Model

Functional Model

Dev

elop

s

Informs

Info

rms


4

Requirements catalog, self-assessment documentation are approved through the plenary

4

Met w

ith

Sour

ce o

f


Requirements are periodically reviewed and updated as necessary by the committees; dependent documents are subsequently updated and approved.

5

PrivacyCommittee

Security Committee

UX Committee

Standards Committee

TFTMConsolidates



Produces

Identify

Adopted Standards

Requirements

Standards

Develops





Standards Committee

Consolidates



Functional Model

Functional Model

Dev

elop

s

Informs

Info

rms

5M

et with

Sour

ce o

f


Security committee develops functional model and standards committee manages standards adoption process

A & B

PrivacyCommittee

Security Committee

UX Committee

Standards Committee

TFTMConsolidates



Produces

Identify

Adopted Standards

Requirements

Standards

Develops





Standards Committee

Consolidates



Functional Model

Functional Model

Dev

elop

s

Informs

Info

rms

B

A

Met w

ith

Sour

ce o

f

Suggested Milestones• Decision to progress with self-assessment and attestation compliance program

– TFTM consensus decision 28 May 2014• Finalize and approve standards adoption policy

– Standards committee; September 2014• Develop GP based requirements– Security, Standards, UX, Privacy

– Security, privacy, UX, and standards committees; November 2014• Consolidate requirements

– TFTM; November 2014• Finalize self assessment documentation

– TFTM; December 2014• Plenary approval of requirements catalog

– Plenary; January 2015• Plenary approval of self-assessment documentation

– Plenary; January 2015

Questions/Discussion?

requirements development & template presentation to all chairs 8/12/2014

Documents