1. Progress Report on the U.S. NSTIC Efforts Jack Suess – Delegate for Research, Development, Education & Innovation Jack@umbc.edu

2. NSTIC Background Information Presidential directive signed in 2011 that stated internet identity and cyber-security are both lacking. Stated this must be a partnership between the private sector and governments. Suggested a consensus driven approach to governance using a plenary style process. Launched first Plenary in August of 2012. In 2014, created a not-for-profit corporation, named IDESG, to operate what is produced.

3. Launching the IDESG IDESG is designed to be the non- governmental entity that can operate what is approved through the plenary process. Plenary is a global entity open to any organization, not just U.S. organizations. Summer 2014, I chaired a IDESG board subcommittee that drafted the plan for rolling out our first product – a self-attested system for IdP’s and SP’s – called Identity Ecosystem Framework (IDEF) plan.

4. The Big Questions Debated in the IDEF What must the IDESG have as operational capabilities in order to deliver and maintain a Framework? How should the IDESG design and implement a Framework?

5. What IDESG Is Planning to Deliver 1.Requirements 2.Evaluation mechanisms 3.Trustmark management

6. What Requirements Are Necessary? 1.Requirements 2.Evaluation mechanisms 3.Trustmark management

7. Requirements ●Based on NSTIC principles and goals ●Forms part of language that IDESG uses to instruct organizations on how to operate in NSTIC ways ●Itemize the practices that uphold the NSTIC vision ●If implemented widely it will increase the trustworthiness of digital interactions for all parties

8. Approach to Requirements Definition ●As a starting place, IDESG committees should focus on requirements found in existing frameworks, standards, certifications, and protocols. ●Where there are gaps, the NSTIC committees process should develop their own requirements.

9. Evaluation Mechanisms ●What does the process of evaluating an organization look like? o IdP and SP will be evaluated. o Trust Framework committee defines the approach and is involved in disputes. o Framework office handles the back office operations. o Initial launch is a web-based listing service, similar to cloud security alliance.

10. What is the Role for Federations? In the initial version, none. In the next iteration, we are hoping to add in a model for federations to join. The rationale for delay is we needed to better understand the business models and value proposition for federations to join.

11. Third-Party Assessors ●Initial version is self-attested; however, self attestation should have some basis in 3 rd -party assessment. ●Have you been audited for basic IT controls? ●Do you have publicly accessible policies in place? ●For self-attestation, there will be little, if any, review of the self-attestation; however, the listing service will show the form. ●Being part of a federation can be noted in your attestation as evidence of good behavior.

12. Trustmark Management 1.Requirements 2.Evaluation mechanisms 3.Trustmark management

13. Why Trustmarks? ●The framework planning committee felt that the Georgia Tech Trustmark pilot was the best example of where the future will be. ●We felt that trustmarks provide a flexible approach that gives IDESG and organizations room to learn and improve ●There is still much debate over the degree of granularity for trustmarks.

15. Where Are We Today?

16. IDEF Requirements The committees generated 45 requirements that make up the baseline. Interoperability – 8 Privacy – 15 Security – 15 Usability – 7 https://www.idecosystem.org/filedepot_download/1887/1824

17. Example Requirements INTEROP ‐ 6. FEDERATION COMPLIANCE When conducting digital identity management functions within an identity FEDERATION, entities MUST comply in all substantial respects with the published policies and system rules that explicitly are required by that FEDERATION, according to the minimum criteria set by that FEDERATION. PRIVACY ‐ 6. USAGE NOTICE Entities MUST provide concise, meaningful, and timely communication to USERS describing how they collect, generate, use, transmit, and store personal information.

18. SALS (Self-Attested Listing Service) SALS will provide a listing service – similar to cloud security alliance to list who self-attested. The process for self-attestation is being driven by Framework Monitoring Office (FMO). Expectation is that we initially work with NSTIC pilots and then tweak the business processes as we expand the offering.

19. Can You Say POP? The SALS process has many parallels to the original InCommon Principles of Practice, but much more detail is required. Ultimately, the plan is that federations may join. If Federation is shown to be conformant with the requirements, being a federation member will likely be sufficient for attestation. I personally believe there is a role for electronic trustmarks; however, that was decided to be out–of-scope for the initial release.

20. Why Should REFEDS Community Care? 1.Governments – especially in UK, Canada, Austrailia, and New Zealand are participating and sharing practices to support NSTIC and the IDESG. These groups will ultimately align on a solution. 2.If it is successful, the IDESG offers a potential way to improve practices, especially in privacy and accessibility, by pressuring cloud service providers. 3.We all want to increase the value of federation. Making certain that the NSTIC aligns with REFEDS work will help both parties. edugain, R&S, scalable privacy, and second factor are all aligned.

21. When you come to a fork in the road, take it. Yogi Berra