nstic idesg functional requirements status report from fmo

1

Functional Requirements:

Now what?

2

Thursday: Functional Requirements

• This program assumes you know why IDESG is focusing on Functional Requirements. See our brief into from Wednesday afternoon, and the IDEF plan: http://j.mp/IDEFsept2014

• Four Committees (Privacy, Security, Standards and UX) have shipped preliminary sets.http://j.mp/reqtssumm They match up moderately well to the Derived Requirements and NSTIC strategy document: http://j.mp/reqtsderive

• Now what?

3

Functional Requirements: Now what?

• Today’s exercise will (a) review the preliminary material we received, (b) get some early Plenary feedback, and share (c) some of our own observations, and the early feedback we have sought from other sources.

• Then we’ll talk about what IDESG and its committees plan to do next with the Functional Requirements, and how to do it.

• But first, a map.

4

You Are Here(not a complete picture, but illustrative)

6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016

Strategy & IDEF Plan

Committee RequirementsCommittee RequirementsCommittee Requirements

P P P P P P …TFTM work

TFTM 3rd party assessment planningUX 3rd party assessment planning

Other (?) 3rd party assessment planning

Standards adoption policy Std StdStdStd

StdStdStdStdStdStd …Other Projects …

P

TFTM self‐assessment planningUX self‐assessment planning

Other (?) self‐assessment planning


TFTM work

Iterated RequirementsIterated RequirementsIterated Requirements

StdStdStd

Enabling projectsEnabling projectsEnabling projects

… Enabling projectsEnabling projectsEnabling projects

Preliminary set; self‐assessment Full set; 3rd party assessment

You Are Here








P




TFTM work


StdStdStd




Staff help

Staff help

6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016

You Are Here

6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016








P




TFTM work


StdStdStd




Staff help

Staff help

Staff help

Staff help

You Are Here

6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016








P




TFTM work


StdStdStd




Staff help

Staff help

Staff help

Staff help

Staff help

You Are Here

6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016








P




TFTM work


StdStdStd




Staff help

Staff help

Staff help

Staff help

Staff help

Staff help

Staff help

Staff help

You Are Here

6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016








P




TFTM work


StdStdStd




Staff help

Staff help

Staff help

Staff help

Staff help

Staff help

Staff help

Staff help

Staff help

Staff help

Staff help

You Are Here

6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016








P




TFTM work


StdStdStd




11

Functional Requirements: successive passes over time

• By January 2015: first‐pass draft

• By June 2015: first baseline set, and a self‐assessment program

• After June 2015: iterations and improvements of that set and that program

• By June 2016: second full set, and a third‐party assessment program

• After June 2016: iterations and improvements of that set and that program

12

Functional Requirements: various things IDESG could discuss

• Talk About the Project of Doing Requirements (Where it Fits Into the IDEF)

• Talk About the Content Quality of these Requirements (Prelim Feedback)

• Talk About Next Steps for Developing the Requirements

13





14

Functional Requirements: the first pass

• First we’ll review them: Do they cover the topic? Are they feasible?

• Then, we’ll share some FMO observations about what’s in the early set and what’s not.

• Then, we’ll share some early feedback from stakeholders.

• Then, we’ll discuss how IDESG wants to proceed from here.

15

Functional Requirements: informal poll

• First we’ll review them: Do they cover the topic? Are they feasible?

16


• 1 to 5 The set is close to complete, covers the needed issues

• 1 to 5 The set is feasible, makes clear and reachable demands on implementers

1. Strongly disagree2. Disagree3. Neutral / ambivalent4. Agree5. Strongly Agree

17


This is going to be an iterative process for IDESG and the identity community that it

seeks to support

18


19

Functional Requirements: the early set

• Draft SECURITY Requirements

• Draft STANDARDS Requirements

• Draft PRIVACY Requirements

• Draft USER EXPERIENCE Requirements

http://j.mp/reqtssumm

Thanks again to all four committees for “bringing it”These four committees aren’t the end of the search

pattern

20

Draft SECURITY Requirements

1. Service providers in the ecosystem follow recognized informationsecurity standards, frameworks, and/or appropriate practices.

2. Each account credential pair is uniquely identifiable for authentication purposes.

3. The confidentiality and integrity of identity data (e.g., attribute values) is protected during the execution of all identity functions and across the entirety of the data lifecycle (collection through destruction).

4. Credential and token issuance processes protect against unauthorized disclosure and/or reproduction.

5. Users are able to authenticate the source of all token and credential data received from service providers.

21


6. Credentials and associated tokens are granted to the appropriateand intended user(s) only.

7. There are clear processes, policies, and procedures in place for the execution of identity functions.

8. End users have access to the policies and procedures in place for the execution of identity functions.

9. The confidentiality and integrity of authentication data are protected. Data (such as passwords and passphrases) used for authentication are never stored in plaintext.

10. User control of the token is proven during the authentication process.

11. Users must be able to choose authentication mechanisms that are stronger than single factor passwords and passphrases and are commensurate with the level of risk associated with the transaction.

22


12. Service Providers have established policies, procedures, and processes in place to maintain availability of services.

13. Where cryptographic solutions are used, key management policiesand practices are established and used consistent with industry standards and best practices.

14. Processes for the reissuance and/or recovery of credentials and authentication tokens are commensurate with the original processand procedures followed during registration and credentialing core operations, including identity assurance procedures.

15. Transactions and security events (to include the execution of identity functions) are logged in a manner that supports system audits and, where necessary, security investigations. Timestamp synchronization and granularity are appropriate to the level of risk associated with the environment, sector, or transaction.

23

Draft STANDARDS Requirements

1. Entities shall be capable of accepting external users authenticated by 3rd parties.

2. Entities shall issue credentials and/or assertions that conform to IDESG adopted standards and are capable of being utilized by multiple 3rd parties.

3. Entities that perform Identity Ecosystem core operations and functions that support transactions requiring digital identity, authentication, and/or access control shall utilize technologies to communicate and exchange identity and/or attribute related data that conform to IDESG approved standards.

4. Entities shall employ documented, publicly available business policies and processes for identity management functions such asaccount recovery, identity proofing, identity vetting and liability that are employed in the transmission, receipt, and acceptance of data between systems.

24


5. (BP1) Entities should utilize solutions and technologies that allow for identity account portability.a. Identity Providers and Attribute Providers SHOULD provide an

easy to use method to allow individuals to switch to a new provider(s).

b. Identity Providers and Attribute providers SHOULD provide individuals a mechanism to link their Relying Party accounts with their new provider(s).

c. Relying Parties SHOULD provide individuals with a mechanism to associate multiple credentials to a single account.

d. Relying Parties SHOULD provide individuals with a mechanism to have a single account per credential.

e. Service Providers should utilize solutions and technology that allow for affordable identity account portability, when established open standards are available.

25


6. (BP2) Organizations shall utilize standard taxonomies to enablesemantic interoperability of identity attributes within communities where standards have been established in which they operate, consumer consent and identity metadata.

7. (BP3) Organizations shall employ standardized common models and processes for identity management functions, such as accountrecovery, identity proofing, identity vetting and liability, when established open standards are available and appropriate to fulfill those functions in the context of that organization's activities.

8. (OOS) Entities SHOULD implement modular identity solutions.

26

Draft PRIVACY Requirements

1. Organizations shall limit the collection and transmission of information to the minimum necessary to fulfill the transaction’s purpose and related legal requirements.

2. Organizations shall limit the use of the individual’s data that is collected and transmitted to the specified purposes of the transaction.

3. Organizations shall limit the retention of data to the time necessary for providing and administering the services and transactions to the individual end‐user for which the data was collected, except as otherwise required by law.

4. Organizations shall provide concise, meaningful, timely, and easy‐to‐understand mechanisms to communicate to end‐users how they collect, use, disseminate, and maintain personal information.

5. Organizations shall minimize data aggregation, including linkages across transactions.

6. Organizations shall provide appropriate mechanisms to enable individuals to access, correct, and delete personal information.

27


7. Organizations shall determine the necessary quality of data used in identity assurance solutions based on the risk of that transaction, including to the individuals involved.

8. When terminating business operations or overall participation in the Identity Ecosystem, organizations shall, while maintaining the security of individuals' information, transfer it upon their request and destroy it unless they request otherwise.

9. Organizations shall be accountable for conformance to these requirements, and provide mechanisms for auditing, validation, and verification.

10. Organizations shall provide effective redress mechanisms for, and advocacy on behalf of, individuals who believe their rights under these requirements have been violated.

11. Where individuals make choices regarding the treatment of their information (such as to restrict particular uses), those choices shall be automatically applied to all parties downstream from the initial transaction.

12. Organizations shall, where feasible, utilize identity solutions that enable transactions that are anonymous, anonymous with validated attributes, pseudonymous, and/or uniquely identified.

28


13. Organizations will request individuals’ credentials only when necessary for the transaction and then only as appropriate to the risk associated with the transaction or only as appropriate to the risks to the parties associated with the transaction.

14. Participation in the Identity Ecosystem shall be voluntary.

15. Privacy controls should be situated as low in the technology stack as possible.

16. Organizations shall clearly indicate to individuals what personal information is mandatory and what information is optional prior to the transaction.

17. Controls on the processing or use of individuals' information shall be commensurate with the degree of risk of the processing or use.

18. Identifiers shall be segregated from attributes whenever feasible.

29


19. Organizations shall, upon any material changes to a service thataffect the prior or ongoing collection, use, dissemination, or maintenance of users’ personal information: a) provide clear and conspicuous descriptions of the changes and their impacts on users in advance, and b) with respect to previously collected personalinformation, provide users with compensating controls designed to mitigate privacy risks that may arise from the material changes,which may include seeking express affirmative consent of users in accordance with relevant law or regulation. In the event that users elect to terminate the service, organizations shall meet other stated requirements on termination and retention.

30

Draft USER EXPERIENCE Requirements

1. Information presented to users should be in plain language, which is clear and easy to understand.

2. All choices, pathways, and solutions should be available and clearly identifiable by the user.

3. The system shall make reasonable accommodations to be accessible to as many users as is feasible.

4. The system should have a way to collect user feedback on site usability, while conforming with the other high level requirements.

5. The system should provide opportunity for redress: an easy way for users to report errors, complaints, etc., while preserving user privacy.

31

Draft USER EXPERIENCE Requirements

6. Where user requirements standards exist, users should have structured opportunities to document and express their requirements before interacting with Service Providers in onlinetransactions. (e.g., Do Not Track, link?)

7. User shall (should) see simple, easy‐to‐understand and persistent methods for choosing and communicating their unique requirements (state, claim and promote) about their attributes and how they are used. Users should see simple, clear‐language responses from an organization about how these requirements willbe treated, before agreeing to share their attributes.

You Are Here

6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016








P




TFTM work


StdStdStd




33

Functional Requirements: feedback

This is going to be an iterative process for IDESG and the identity community that it

seeks to support

34

Functional Requirements: feedbackEarly observations from FMO

(This is not a substitute for TFTM’s or the Plenary’s later formal review)

• Missing topics?

• Quality of content

• Harmonized meanings

• Who’s being addressed?

35


Missing topics / coverage issues

• Pseudonymity / anonymity?• Do we adequately address identity theft

via stolen PII?• “Use our standards from the standards

registry” … which is empty• How do these apply to vertical industries?

36


Quality of content

• MUST, SHOULD and MAY, etc.

• Length and compound statements

• Testable statements

37


Quality of content• Length and compound statements

Privacy # 19: Organizations shall, upon any material changes to a service that affect the prior or ongoing collection, use, dissemination, or maintenance of users’ personal information: a) provide clear and conspicuous descriptions of the changes and their impacts on users in advance, and b) with respect to previously collected personal information, provide users with compensating controls designed to mitigate privacy risks that may arise from the material changes,which may include seeking express affirmative consent of users in accordance with relevant law or regulation. In the event that users elect to terminate the service, organizations shall meet other stated requirements on termination and retention.

38


Quality of content• Testable statements

Privacy # 1: Organizations shall limit the collection and transmission of information to the minimum necessary to fulfill the transaction’s purpose and related legal requirements.

User Experience # 1: Information presented to users should be in plain language, which is clear and easy to understand.

39


Quality of content• Length and compound statements

Privacy # 19: Organizations shall, upon any material changes to a service that affect the prior or ongoing collection, use, dissemination, or maintenance of users’ personal information: a) provide clear and conspicuous descriptions of the changes and their impacts on users in advance, and b) with respect to previously collected personal information, provide users with compensating controls designed to mitigate privacy risks that may arise from the material changes,which may include seeking express affirmative consent of users in accordance with relevant law or regulation. In the event that users elect to terminate the service, organizations shall meet other stated requirements on termination and retention.

40


Harmonized meanings

• Who is the “user” or “end user”?

• What is the “Identity Ecosystem”?Privacy # 8: When terminating business operations or overall

participation in the Identity Ecosystem, organizations shall, while maintaining the security of individuals' information, transfer it upon their request and destroy it unless they request otherwise.

• Glossary may be useful here

41


Who’s being addressed?

“Organizations should … ““Relying parties should … “

Our Functional Model, and the roles it defines, may be used to clarify

which principles apply in which cases

42

Functional Requirements: feedbackSecurity Committee early review

• Security Committee asked the FMO to seek stakeholder feedback on the draft requirements.

• A broad review, like formal surveys or focus groups, is possible, but• Couldn’t be launched in late December• Might be a good thing to do more broadly (output from more than one committee)

• Security Committee wished to discuss it further

• So we sought approval for a shorter informal set of feedback exercises

• We’ll return on Friday to larger scale possibilities

43

Functional Requirements: feedback Security Committee early review

• Roundtable with the NSTIC pilot project participants: informal discussion

• Limited interviews with IdMs, RPs and other stakeholders across a range of entity sizes

• Nonattribution ground rules: what do you really think? (“Chatham house rules”)

• Structured questions: http://j.mp/SecReqQs

https://www.idecosystem.org/filedepot_download/1809/1641

44


• Some are outcomes, not processes

Security # 6: Credentials and associated tokens are granted to the appropriate and intended user(s) only.

• How does this map to the requirements I already face? (HIPAA, FFEIC, FIPP, CSA, etc.)

• Are these immediate, entry‐level requirements or aspirational plans?

• What’s the source, and how do I get there?Security # 5: Users are able to authenticate the source of all token and

credential data received from service providers.

45


• Many of the draft requirements appeared to reviewers to be current best practices, or within conventional reach, but they see others as either too vague or too ambitious

• Would help focus customer expectations in unregulated industries

• “Some kind of tool set, in the form of benchmarks or a test harness or similar, would be very helpful to make this real for those considering it”

• Applying these criteria is a resource decision

46


• There may be multiple methods for fulfilling a requirement

• “You need some ‘big names’ to take the pledge.”

• What a prospective adopter will ask: • Is it measurable?

• Is it feasible?

• What’s the remediation?

• What’s the governance?

You Are Here

6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016








P




TFTM work


StdStdStd




48

How long should this

next step take?

49





50





51

General questions?

52

Functional Requirements:

Now what?

nstic idesg functional requirements status report from fmo

Technology

youarehere notacompletepicture

mpreqtsderive nowwhat

bgetsomeearly plenaryfeedback