OIDF and other standards bodies produce several specifications that enable secure and privacy-enabling technologies. 

Ecosystem providers still need to spend much time and effort trying to understand the decisions they need to make, and combining these specifications. For example,

• If I select the FAPI 2.0 specifications, what decisions do I need to make and what are the pros and cons of each?
• How do I use the FAPI security profile to secure OpenID Connect for Identity Assurance, Shared Signals and Events, or OpenID Federation? 
• How do I combine Shared Signals and Events with FAPI and OpenID Federation in one ecosystem? 
• How do I use OpenID Federation in a FAPI-based Open Banking ecosystem? 
• How do I use the OpenID certification test suite to test multiple specifications?

After supporting deployments of multiple ecosystems, the OIDF noticed that there are still common requirements that (if left unsatisfied) lead to divergences, interoperability, and security issues. These gaps introduce an unnecessary “cost to change” for every participant in the ecosystem within an ecosystem, and typically even larger gaps that complicate cross border interoperability in the future. .

Deliverables 

The proposed ES CG will focus on the following deliverables:

• Initiation
• Sprint: CG to identify ecosystems’ common needs and requirements  that are currently not addressed by

1. Existing specifications or the combined use of specifications
2. OIDF conformance suite or self-certification processes  

• Communicate requirements to a relevant WG, OIDF staff team, OIDF board sub-group, OIDF Strategic Task Force or OIDF Board as required.

• Set up an ecosystems tracker to understand what versions of OIDF specifications are used where, starting with ecosystem “Strategic Partners” that the OIDF is actively supporting . 
• Development of “best practice guides” to support different types of ecosystems. For example: “Current best practices for Open Banking ecosystem architects” covering:  
  • All the key decisions that an implementer needs to make in their profile
  • Some of the obvious “pros and cons” for the decisions, and the FAPI WG recommendation – if any. 
  • The implementer can use the contents to inform their own internal governance decision processes.
  • The outputs can be used to affirm the local profile of FAPI 2.0 required, and the corresponding tests.
  • Subsequent governance decisions change the profile, will then drive revisions to the profile and tests, then deployed as appropriate.  

Participation Criteria: 

• To be effective, a minimum of three ecosystem governing bodies should be participating consistently. 
• The CG is open to anyone that signs a participation agreement for the CG. However, if the co-chairs determine that contributions from an individual or an entity are “sales oriented” and out of step with the objectives of the CG to serve ecosystem leaders, then an individual or entity may be removed from a specific call (or in more extreme cases from the CG).

Organizing Principles

The community group will operate under the following Organizing Principles:

• Sharing: Provide a safe community for ecosystem governing bodies to share experiences and learnings and ask questions.

• End User privacy and consent: The CG’s work must promote enhancing user privacy and control by using explicit consent accompanied by the best consent practices.

• Security: The CG’s work must identify and promote best current security practices for all ecosystem participants.

• Interoperability:  The CG’s work must promote interoperability within each ecosystem as well as between the ecosystems

• Respect:  The CGs culture will be to recognize that Individual ecosystem may need to make pragmatic decisions in the short term (or may have in the past), while supporting an ecosystem’s journey towards interoperability over time.  

• Lower cost of deployment: A primary goal of the CG’s work is to promote lower cost of adoption and change for ecosystem participants (data recipients, data providers, ecosystem governing bodies and others).

Logistics

• Initial Term: 2 years.  We seek a two-year charter to develop the deliverables identified above.At the end of this two-year charter, we will assess the state of the ES CG and determine whether to extend the charter, charter a working group to develop related protocols, or disband the community group.

• Communication tools. The work will progress via mailing list and telephone/internet conference calls combined with face-to-face meetings, where possible. Standard tools can be utilized by the CG such as OIDF email list, zoom calls, slack channels, OIDF website and calendar. 
• Language: English. 

Ecosystem CG Forms: Participation Agreement and Operating Rules   

• After OIDF Board approval of Charter, the CG can propose changes to the Charter for Board approval
• CG can propose changes to Participation and Operating Rules for Board Approval
• OIDF Board approval will not be unreasonably withheld. Key criteria: no adverse impact to OIDF brand or ability to deliver on OIDF mission/vision
• Timely reports to OIDF board to ensure CG operates in keeping with the Charter 

The following are out of scope for the proposed ES CG:

• Development of any specifications. Any such work will be deferred to a relevant working group. 

Proposers

• Dima Postnikov (ConnectID and OIDF)
• Ralph Bragg (Raidiam)
• Mark Verstege (OIDF Corporate Representative)
• Mark Haine (SelectID, Considrd.Consulting, & OIDF Technical Director)
• Gail Hodges (OIDF Executive Director)