Rob asked everyone to put in the chat their name and organization. 

No actions to review

New Participant Intros

• new participants in FDC3 and new attendees to the meeting introduce themselves
  • organization and role
  • why is interoperability important to you / your organization?
  • what do you hope to accomplish with FDC3?

There were no new participant introductions.

Nick provided an update on the the overall standard development and ratification process, including that the PMC ratified standards for AppD and ContextData completing the full first set of standards along with 9 approved use cases.

Working Group Updates

•  API WG
• App Directory WG
• Context Data WG
• Intents WG
• Use Cases WG

Nicholas Kolba

Espen Overbye

Tim Kolecke

Frank Tarsillo (Deactivated)

Former user (Deleted)

Jonathan Teper

API Update from Nick - discussions continuing on:

• How does the API support more precise app identification?
• Cross platform (container) communications 
• Data returns / use case group

Frank asked how the different working groups will more collectively work on the overall release process and present a more cohesive set of standards.

Nick noted that there was some interesting work at OSSF about applying use cases across the standards of the different working groups. Frank suggested that it would be good to have someone test cohesiveness across the WGs to understand usefulness across the whole. Espen noted that there is additional work planned on mapping use cases to the standards.

AppD update from Frank

• Approved 1.0 specification at last PMC 
• Next mtg focus on next priorities, primarily ability to filter/search; types of data to store; and possibility of including an event model
• Noted would like to test end to end

Context Data update from Tim Kolecke

• Ratified the first version of the context data spec
• Had some dialog with financial objects working group 
• Johan submitted some objects that can be used "as is" to financial objects and expected continued discussion on how/what to pass 
• Rob noted that Securities Reference Data WG could also have interest in Instrument

Intents update from Espen

• Paused the intents group while the other groups establishing standards

Use Cases from Kat

• Largely covered in previous discussions
• Agreed to put all use cases in GitHub. Working with Mao to get this going.
• Planning an informal meeting in London to go through use cases.

Nick noted that there is an FDC3 focused meetup tomorrow at 6:30 at IHS Markit.

Focus over next month (or more) is to get the standards well documented and the overall FDC3 story, context and continuity completed and presented in consumable fashion.

Rob Underwood provided an update as below:

• FINOS has done initial analysis looking at the existing documentation and identifying gaps.
• This was presented to the PMC and you can find a documentation release plan here (covering existing sites and content needed such as value proposition, business info, technical info, getting started, reference implementations, etc.) and a go-live checklist here.
• The aim is to produce a microsite that contains the information that anyone new to FDC3 would need as well as a central point for those knowledgeable about FDC3 already. All comments welcome.
• The Community handbook also has valuable information about what FINOS expects for something in released state.

Dylan provided some context on what he might be looking for in the documentation; agreed that technical folks work with github but others may need more and the microsite is good for that. Thinks the direction of the standards is positive and they hope to do more of a deep dive on it in the future with an aim to implement them. Part of what has prevented implementation so far is having all standards/specifications complete (and not just some of them).

Nick noted that they have loosely coupled interdependencies. For example Context Data or AppD can be use used independently; Intents could be use independently but with more limited value; API does have dependencies. The idea is that there are layers that can be independent and the API would tie them all together. This is a working thought/assumption that is partially tested.