Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

NSTIC IDESG Functional Requirements status report from FMO

812 views

Published on

Slides from the Atlanta (12th) IDESG plenary, on progress towards the IDESG Functional Requirements for supporting implementable NSTIC principles. From the IDESG Framework Management Office (OASIS).

Published in: Technology
  • Be the first to like this

NSTIC IDESG Functional Requirements status report from FMO

  1. 1. 1 Functional  Requirements:  Now what?
  2. 2. 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. 3. 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. 4. 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 Requirements Committee Requirements Committee Requirements P P P P P P … TFTM  work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption  policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM  work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set;  3rd party assessment
  5. 5. You Are Here  Strategy & IDEF  Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM  work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption  policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM  work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set;  3rd party assessment Staff  help Staff  help 6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016
  6. 6. You Are Here  6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF  Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM  work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption  policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM  work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set;  3rd party assessment Staff  help Staff  help Staff  help Staff  help
  7. 7. You Are Here  6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF  Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM  work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption  policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM  work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set;  3rd party assessment Staff  help Staff  help Staff  help Staff  help Staff  help
  8. 8. You Are Here  6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF  Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM  work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption  policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM  work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set;  3rd party assessment Staff  help Staff  help Staff  help Staff  help Staff  help Staff  help Staff  help Staff  help
  9. 9. You Are Here  6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF  Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM  work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption  policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM  work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set;  3rd party assessment Staff  help Staff  help Staff  help Staff  help Staff  help Staff  help Staff  help Staff  help Staff  help Staff  help Staff  help
  10. 10. You Are Here  6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF  Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM  work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption  policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM  work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set;  3rd party assessment
  11. 11. 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. 12. 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. 13. 13 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
  14. 14. 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. 15. 15 Functional Requirements:  informal poll • First we’ll review them:  Do they cover the  topic?  Are they feasible?
  16. 16. 16 Functional Requirements:  informal poll • 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 disagree 2.  Disagree 3.  Neutral / ambivalent 4.  Agree 5.  Strongly Agree
  17. 17. 17 Functional Requirements:  informal poll This is going to be an iterative  process for IDESG and the  identity community that it  seeks to support
  18. 18. 18 Functional Requirements:  informal poll
  19. 19. 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. 20. 20 Draft SECURITY Requirements 1. Service providers in the ecosystem follow recognized information security 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. 21. 21 Draft SECURITY Requirements 6. Credentials and associated tokens are granted to the appropriate and 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. 22. 22 Draft SECURITY Requirements 12. Service Providers have established policies, procedures, and  processes in place to maintain availability of services.  13. Where  cryptographic solutions are used, key management policies and 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 process and 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. 23. 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 as account recovery, identity proofing, identity vetting and liability  that are employed in the transmission, receipt, and acceptance of  data between systems.
  24. 24. 24 Draft STANDARDS Requirements 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. 25. 25 Draft STANDARDS Requirements 6. (BP2)  Organizations shall utilize standard taxonomies to enable semantic 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 account recovery, 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. 26. 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. 27. 27 Draft PRIVACY Requirements 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. 28. 28 Draft PRIVACY Requirements 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. 29. 29 Draft PRIVACY Requirements 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.
  30. 30. 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. 31. 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 online transactions.    (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 will be treated, before agreeing to share their attributes.
  32. 32. You Are Here 6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF  Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM  work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption  policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM  work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set;  3rd party assessment
  33. 33. 33 Functional Requirements:  feedback This is going to be an iterative  process for IDESG and the  identity community that it  seeks to support
  34. 34. 34 Functional Requirements:  feedback Early 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. 35. 35 Functional Requirements:  feedback Early observations from FMO 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. 36. 36 Functional Requirements:  feedback Early observations from FMO Quality of content • MUST, SHOULD and MAY, etc. • Length and compound statements • Testable statements
  37. 37. 37 Functional Requirements:  feedback Early observations from FMO 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. 38. 38 Functional Requirements:  feedback Early observations from FMO 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. 39. 39 Functional Requirements:  feedback Early observations from FMO 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. 40. 40 Functional Requirements:  feedback Early observations from FMO 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. 41. 41 Functional Requirements:  feedback Early observations from FMO 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. 42. 42 Functional Requirements:  feedback Security 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. 43. 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. 44. 44 Functional Requirements:  feedback  Security Committee early review • 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. 45. 45 Functional Requirements:  feedback  Security Committee early review • 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. 46. 46 Functional Requirements:  feedback  Security Committee early review • 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?
  47. 47. You Are Here 6/30/2014 12/31/2014 6/30/2015 12/31/2015 6/30/2016 Strategy & IDEF  Plan Committee Requirements Committee Requirements Committee Requirements P P P P P P … TFTM  work TFTM 3rd party assessment planning UX 3rd party assessment planning Other (?) 3rd party assessment planning Standards adoption  policy Std StdStdStd StdStdStd StdStdStd … Other Projects … P TFTM self‐assessment planning UX self‐assessment planning Other (?) self‐assessment planning Committee Requirements Committee Requirements Committee Requirements TFTM  work Iterated Requirements Iterated Requirements Iterated Requirements StdStdStd Enabling projects Enabling projects Enabling projects … Enabling projects Enabling projects Enabling projects Preliminary set; self‐assessment Full set;  3rd party assessment
  48. 48. 48 How long  should this  next step take?
  49. 49. 49 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
  50. 50. 50 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
  51. 51. 51 General  questions?
  52. 52. 52 Functional  Requirements:  Now what?

×