1. STANDARDS COORDINATION COMMITTEE PLENARY BREAKOUT 18 SEPTEMBER 2014 Interoperability Requirements

2. Agenda  Introduction  Requirements presentation (M. Garcia)  Review of the derived requirements on interoperability (Tilton) o https://www.idecosystem.org/filedepot/folder/10?fid=1448 https://www.idecosystem.org/filedepot/folder/10?fid=1448 o Note: Hold off on discussion till later  Functional relationship diagram exercise (Paul & Joe) o Identify interoperability points o Potential applicable standards  Preliminary pilot view (Tilton) o Understanding & interpreting the requirements  Prioritization of requirements o Identify requirements to be addressed in “baseline” framework/trustmark  What can we do NOW to support the initial IDEF development?  Next steps

3. Interoperability Requirements Organizations shall accept external users authenticated by third parties. NSTIC, page 13 Organizations shall issue credentials capable of being utilized by multiple different service providers. NSTIC, page 13 Organizations shall utilize technologies that communicate and exchange data based upon well-defined and testable interface standards. NSTIC, page 13 Organizations shall adopt common business policies and processes (e.g., liability, identity proofing, and vetting) related to the transmission, receipt, and acceptance of data between systems. NSTIC, page 13 Organizations shall implement modular identity solutions. NSTIC, page 14 Organizations shall utilize solutions and technology that allow for identity portability. NSTIC, page 14

4. Pilot notes Cathy is sharing some notes from the pilot collaboration meetings where the derived requirements were discussed. This does NOT constitute an official contribution from the pilots.

5. Considerations The pilots reviewed the interoperability derived requirements. They identified the following three considerations vital to the success of each requirement: Is it commercially viable today? Some of the drafted interoperability requirements are not feasible in the current market, and thus would be better suited as guidelines. The wording could reflect this by stating that organizations “should” follow a requirement as opposed to “shall”. Is it specific to particular actors in the ecosystem? Many of the draft interoperability requirements are not equally applicable to all roles. Narrow requirements should be clearly targeted to a particular actor, or they should be broad enough to apply to all. To which LoAs does it pertain? Interoperability requirements must specify the level of assurance that is associated with each specific requirement, since interoperability concerns will vary between lower and higher LoAs.

6. Specific feedback The pilots provided specific feedback to the IDESG on three distinct interoperability requirements: Requirement 28: “Organizations shall utilize technologies that communicate and exchange data based upon well- defined and testable interface standards.”  Discussion:  Is this SAML/OpenID Connect? Or could it use ex. Facebook? Is someone precluded from offering others in addition to SAML, etc.? This seems focused on the CSPs, not the RPs.  Feedback for IDESG:  We recommend SAML and OpenID Connect for all assurance levels, and others for lower levels to be supported by IdPs. A similar standardized protocol should be created for APs but this is aspirational at this point. Aspirationally, RPs should also be included, but at this time market forces make this challenging.

7. Specific feedback Requirement 27: “Organizations shall issue credentials capable of being utilized by multiple different service providers.”  Feedback for IDESG: IdPs shall issue credentials capable of being utilized by multiple different RPs (we are assuming Service Providers = RPs). Need to consider more policy around level of assurance, in terms of what utilized means. Requirement 31: “Organizations shall utilize solutions and technology that allow for identity portability.”  Feedback for IDESG: There is no current format for this and perhaps this requirement may be more focused on the portability of metadata regarding consent, etc. Work is developing in this area but it should not be a near term requirement. Overall, the pilots support the creation of interoperability requirements and believe that additional requirements, potentially for attributes and relying parties, will be needed in the future. Effective baseline interoperability requirements, combined with advances in the marketplace, are imperative to enhance interoperability between all actors in the identity ecosystem.

8. Low hanging fruit What can we do NOW to support the initial IDEF development? Organizations shall utilize technologies that communicate and exchange data based upon well- defined and testable interface standards. Interface point: Authentication interface Existing standards (candidates for nomination):  SAML 2.0  OpenID Connect 1.0 Discussion

9. Advantages 1.Exercise (and ring out) the process 2.Set an example for other committees 3.‘Prime the pump’ 4.Quick win

10. Next steps Continue discussions in SCC meetings Setup a subgroup to progress?