STANDARDS COORDINATION COMMIT TEE

PLENARY BREAKOUT

18 SEPTEMBER 2014

Interoperability Requirements

Agenda

Introduction Requirements presentation (M. Garcia) Review of the derived requirements on interoperability (Tilton)

o 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 pointso Potential applicable standards

Preliminary pilot view (Tilton)o Understanding & interpreting the requirements

Prioritization of requirementso Identify requirements to be addressed in “baseline” framework/trustmark

What can we do NOW to support the initial IDEF development? Next steps

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

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.

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.

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.

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.

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 interfaceExisting standards (candidates for

nomination): SAML 2.0 OpenID Connect 1.0

Discussion

Advantages

1. Exercise (and ring out) the process2. Set an example for other committees3. ‘Prime the pump’4. Quick win

Next steps

Continue discussions in SCC meetingsSetup a subgroup to progress?