1 / 18

Framework Planning Draft 1

Framework Planning Draft 1. Jack Suess Ian Glazer Peter Alterman Andrew Hughes Michael Garcia. Overview. There is no single “right” solution -- all involve tradeoffs between growth and risk.

chipo
Download Presentation

Framework Planning Draft 1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Framework PlanningDraft 1 Jack Suess Ian Glazer Peter Alterman Andrew Hughes Michael Garcia

  2. Overview • There is no single “right” solution -- all involve tradeoffs between growth and risk. • We need to have a conversation across committees and plenary on growth vs risk and what community is comfortable with. • Value proposition and creating positive feedback loops are key to long-term sustainability. • IDESG contains many stakeholder groups, we need to be flexible and assume some stakeholder groups will need to move more quickly than others.

  3. Framework Planning Goals • Do no harm. Make certain that we are helping to advance better practices in security, privacy, usability, and interoperability. • Component trustmarks as defined by GTRI can be beneficial is assessing interoperability of requirements. • Build off the existing work that has been done in the Identity space in the US and around the world. • Use an iterative design that allows the IDESG to deploy, learn, and update our approach. • Provide value in proportion to effort for those participating.

  4. Do No Harm • We do not want to offer over-blown assertions of trustworthiness if those claims cannot be backed up. • Self-attestation can be used to get the program off the ground but won’t be sufficient longterm. • We want to find ways that incentivize parties in the ID ecosystem to go beyond the minimum required and get credit for all they do. • Scaling something to be as big as the IDecosystem is a large undertaking, we need to build our capacity as an organization. • Perfect is the enemy of the good. We can improve the Identity space with some quick actions today and learn what works.

  5. Trustmarks • The GTRI pilot is demonstrating the benefit of componentized trustmarks with well-defined definitions. This granular approach allows for quick comparison of the trustmarks available across a variety of standards. • Through this model, stakeholders can quickly get credit for what they do already and see what they are missing to reach a particular trustmark profile used by a community. • We should be wait to validate the use of full electronic trustmarks before adopting them in the IDESG. • Creation of a trustmark registry or catalog that is ties trustmarks to requirements would be very valuable.

  6. Building – Electronic Trustmarks(2) • A key point in the use of electronic trustmarks is that these need to be usable without underlying modification of existing software. This can be done today through registries. • Long-term we envision that some communities of interest will require that to operate in that community the entities participating as IDP and SP will require electronic trustmarks be integrated.

  7. AttributeProviders Build on Existing Work. IDESG Service Providers IDP/CSP ID Ecosystem Exists Today • We must leverage all the strengths and capabilities of the current members of IDESG to make this work. • Utilize what has been learned in the pilots to shape the path towards the future. • Leverage others to help in the scaling that must occur to get the benefits we want. Audit/Assessors& 3rd Party

  8. Building – LeveragingTrust Framework Providers • IDP/CSP – Bringing organizations to the IDESG that have been known to be good actors internationally. • Leverage existing national and international programs in the Identity and Credential Access Management (ICAM) space. • Incent current members of IDESG that are Trust Framework Providers to participate. • We recommend an approval process be setup to review TFPs and their members early on. • Incent the NSTIC pilots to participate early in this.

  9. TFP Questions • Do we allow TFPs to participate before we have IDESG baseline requirements established. • If not, are we at risk of letting in TFPs that won’t stay in IDESG. • What incentives exist for TFPs to join? • Allow TFPs to propose accreditation standards they use for trustmark analysis. • Should members of TFPs be allowed to join? • Committee discussed this and felt this was important to get the IDESG off the ground and was a benefit for TFPs to participate early. • Want to hear from plenary & committees on this.

  10. Building – Service Providers and Relying Parties • How do we incent SP’s to join? • Work through the Trusted Framework Providers that are members to bring in their SPs • Leverage our existing pilots that are SPs to join. • Identify organizations that can be strategic partners and work with them. • Develop a lightweight program for SPs to join a registry. • Questions exist on what level of requirements to have SP’s self-attest too?

  11. Use a Staged Approach • The Framework planning subcommittee is proposing staged approach. We want to see the IDESG work on four concurrent but related efforts that would be phased in over time. • By using a staged approach we want to quickly get a proof of concept working and get data back so we may adjust our approach as we learn from those participating. • Similarly the Identity ecosystem will continue to undergo change that might require changes to our plans – such as speeding up some stages.

  12. Requirements Definition • IDESG requirements definition is key. • Standards adopts proposed standards for use. • Security, Usability, Privacy define requirements. • TFTM adopts trustmarks based on requirements to be added to registry and defines self-attestation and 3rd party procedures. • Framework committee proposed up to four possible phases be considered by plenary and committes. • Transparency - Immediate. Organization disclosure. • Baseline - minimum requirements • Full - complete NSTIC requirements. • Ongoing - New and Community specific

  13. Phased Design

  14. High Level Plan Note: - Stages 1, 2, 3 transform into normal program operations after their intensive startup-focused timeframe is done. - “Registry Level 3” is the desired mode of operations

  15. Stage 0 – Bootstrap IDESG Program • Leverage pilots and IDESG members to quickly build out processes around on-boarding entities and preparing them for future stages. • Work with GTRI and committees to develop trustmark component definitions that will enable our work in future stages. • SPs & TFPs would propose “standards” for consideration by Standards committee. • Should run from fall 2014 through summer 2015.

  16. Stage 1 – Focus on CSP/IDP • Tap into trust communities that already exist. • Work closely with existing TFPs and Federation operators to develop procedures for on-boarding. • Trustmarks registry would be available and recommended for use. • This effort would run for 18 months and overlap stage 0. • Timeframe would be January 2015-June 2016

  17. Stage 2 – External Certification of ___ IDESG Requirements • How do we acknowledge work done through auditors and 3rd-party accreditors today for certification? • Trustmark profiles could contain a mix of certified and self-attested trustmarks. • IDESG requirements would be in place. • Allow communities of interest to identify and define bodies that certify and accredit against open standards and criteria. • Begin testing Electronic trustmarks in some communities of interest. • Timeframe would start in summer 2015 and continue forward.

  18. Stage 3 – Community Specific Trustmarks • Work closely with stakeholder communities to identify specific needs not addressed through existing trustmarks to define community specific trustmarks. • Work with communities of interest to identify and define bodies that certify and accredit against open standards and criteria. • Electronic trustmarks are required. • Definition of community specific trustmarks being in summer 2015. Requirements for using electronic trustmarks begin in early 2017

More Related