Standard WG Meeting - Oct 27th, 2022

[kriswest]

Date

Thursday 27 Oct 2022 - 10am EST / 3pm GMT

WebEx info

• Meeting Link
  Meeting number: 665 568 411

More ways to join

• Join by video system:
  • Dial 665568411@finos.webex.com
  • You can also dial 173.243.2.68 and enter your meeting number
• Join by phone
  • +1-415-655-0003 US Toll
  • +44-20319-88141 UK Toll
• Access code: 665 568 411

Meeting notices

• FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

• All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

• FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.

• FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

• Convene & roll call, review meeting notices (5mins)
• Review action items from the previous meeting (5mins)
  • Standard WG Meeting - September 22nd, 2022 #818
• Call for contributions: FINOS App Directory (5mins)
• Discussion of open issues (40mins)
  (will not get to all, the remainder to roll over to future meetings):
  • Specs precision needed about intent handler and app metadata intents property  #825
  • AppD v2 routes don't define error response samples #827
  • Question: App-specific context metadata #829
  • Unit Test Policy #832
  • FDC3 Explained: SemGrep Failures #811
  • findIntent functions docs need to clarify expected response when no apps are found #841
  • fdc3.valuation has incorrect COUNTRY_ISCODE member #833
    • Valuation schema update due to a misspelling #834
    • regenerate context_types after valuation correction #842
  • Allow Desktop Agent To Join Multiple Channels #242
  • Reset context  #301
  • Provide better documentation and examples for AppD auth support #559
  • Revive and update or replace AppD reference implementation #563
  • Upgrade exposure of originating app identity to a requirement (MUST) from recommended (SHOULD) #735
  • Add save and restore state API calls - so FDC3 apps can fully participate in save and restore layout #386
  • Provide Notification API's #387
  • Add vendor agnostic default window size and position settings to the App Directory app definition format #564
• AOB & Adjourn (5mins)
  • Please raise issues for any topic that you'd like discussed at future meetings.

Minutes

• @robmoffat provided a demo of the draft FINOS app directory and website https://directory.fdc3.finos.org/
• Specs precision needed about intent handler and app metadata intents property  #825
  • There was consensus that the Standard does allow for dynamic registration of intent handlers at runtime as an optional feature (MAY), while apps SHOULD be registered via appD Configuration.
  • The wording used should be clarified with compliance keywords and, perhaps, referred to from the raiseIntent/findIntent functions docs.
  • PR to be raised to update 2.0 and next documentation.
• AppD v2 routes don't define error response samples #827
  • Error responses are in fact defined for v2 routes, but they're missing response samples which makes them less obvious. Response samples should be added to the OpenAPI spec.
• Question: App-specific context metadata #829
  • @pierreneu gave an overview of the use case for being able to pass supplementary context for the source of an interaction within an application that raises an intent:
    • For example, a chat message might contain a button to raiseIntent to ViewChart or ViewNews etc. with a specified fdc3.instrument context, additional context would identify what ChatRoom that came from to enable targeting of any messages sent in reply.
    • I.e. the intention is to enable any secondary or response actions to be better targeted or specified - without changing the context type that is sent to a Symphony or chat integration specific type (which might cut down the number of apps available to process the intent, as they require specific context types).
  • @kriswest provided a summary of a proposed solution (posted on the issue), involving adding additional optional parameters to broadcast and raiseIntent calls to supply the additional context and then delivery of that context/intentHandlers at the destination via a new field in the optional ContextMetadata object they can receive in 2.0.
  • @nkolba observed that this could also be solved by decorating context types with additional fields - which is similar to how the id field is handled which is open, allowing many different identifiers to be added.
    • @nkolba observed that this route has the advantage of not requiring changes to the Desktop Agent API, only the context types/schemas.
    • In discussion, @kriswest observed that this is workable, but might promote non-standard structures/variation in context types and that, if we go this route, we could standardize a location in the base Context type additional source metadata.
      • However, @kriswest also observed that the ContextMetadata contains the AppIdentifier for the source application, which is provided by the DesktopAgent to prevent spoofing. The additional metadata we are looking to provide is relative to / supporting that information (as you would, for example, want to target an intent to reply at the chat application (using the AppIdentifier and provide the chatRoom context to deliver it to the right room within the application, so it would make sense to keep these together.
  • Consent was sought to start moving proposals to PRs - both @nkolba and @kriswest expressed an interest in working on proposals.
• Unit Test Policy #832
  • @robmoffat provided an overview of the OpenSSF badging effort, intended to promote best practices in OS projects - as well as the FINOS security scanning tools being applied to the FDC3 repo in PR FINOS Security Scanning #808
  • FDC3 currently achieves a 99% score - to achieve 100% it needs to have a unit testing policy and code coverage tests ensuring that code coverage always increases with changes.
  • @kriswest gave an overview of software delivered by FDC3 (NPM module, FDC3 Workbench, FDC3 Explained, website), current testing (NPM module only) and known issues (vulnerabilities in FDC3 workbench dev server, website, semgrep identified issue in FDC3 Explained and typegen code used for NPM module).
    • FDC3 workbench needs updating to latest react scripts as part of maintenance
    • typegen solution in NPM module needs updating
    • FDC3 Explained needs a small code change to mitigate
    • website needs upgrading to docusaurus v2
  • FDC3 maintainers to investigate code coverage scanning and raise a PR to add a unit testing policy to governance, with repository restrictions based on codecoverage testing (must not decrease).
• FDC3 Explained: SemGrep Failures #811
  • Semgrep failure in FDC3 Explained requires a code change to resolve. @openfin-johans to try and find someone to resolve - fallback to @kriswest and @WatsonCIQ if necessary.
• findIntent functions docs need to clarify expected response when no apps are found #841
  • As discussed at Desktop Agent Bridging Discussion group 26th Oct 2022 #839, the wording of findIntent's docs is less clear that the NoAppsFound error should be returned rather than an AppIntent with an empty apps array
    • @nkolba would seem a valid and normal response
      • @nkolba the metadata could come from the appD if we add the proposed /intents endpoint Add /intents and /contexts endpoints to the AppD API #719.
      • However, symmetry with raiseIntent functions may be more useful
    • @kriswest having two interpretations promotes variation and makes compliance testing harder. I believe the error is what was intended as the AppIntent metadata had to be retrieved from apps in the past (although we are deprecating that under The AppIntent interface incorrectly describes an intent #312).
    • Consent was sought and received to clarify the wording in the 2.0 and next documentation to specify that the error should be returned.
• fdc3.valuation has incorrect COUNTRY_ISCODE member #833
  • Error in Context schema and types generated for it (that appear in NPM module)
  • PR Valuation schema update due to a misspelling #834 raised by @mistryvinay to resolve
  • PR regenerate context_types after valuation correction #842 raised by @kriswest to regenerate types (as this didn't happen automatically) and to release an updated NPM module
  • @bingenito commented that he was willing to take this on (which is much appreciated!) however documentation of how to handle type generation / prepare an NPM module release for FDC3 is not provided.
  • @kriswest remarked that work on the typegen system is needed (both updating deps and implementing a solution for Ensure types are generated when new contexts are merged into master branch #749 to help release new context and intent types on adoption, without waiting for a new FDC3 version to be released).

Decisions Made

• ...

Action Items

• @kriswest prep next meeting agenda to include next issues on list
• @pgn-vole @kriswest Raise a PR to resolve Specs precision needed about intent handler and app metadata intents property  #825
  • clarify (with compliance keywords) the Standard's support for dynamic registration of intent handlers for use in a resolver.
  • Clarified spec requirements for registration of intent handlers #844
• @kriswest Raise a PR to resolve AppD v2 routes don't define error response samples #827
• Add error response samples to appD v2 API routes to make them more obvious in the Swagger spec for appD.
• @kriswest @nkolba @pierreneu to work on proposals/PRs demonstrating possible solutions to Question: App-specific context metadata #829. These should include example use-cases demonstrating the need for and utility of the revision
• @finos/fdc3-maintainers to investigate adding code coverage scanning to repo and to propose a unit testing policy/raise a PR to add to governance and resolve Unit Test Policy #832.
• @openfin-johans find a volunteer to help resolve FDC3 Explained: SemGrep Failures #811 - fallback to @kriswest and @WatsonCIQ if necessary
• @kriswest of volunteer: raise PR to resolve findIntent functions docs need to clarify expected response when no apps are found #841
  • Clarify findIntent function docs to specify ResolveError.NoAppsFound error when no apps are found.
  • Clarify docs and comments on Errors and and findIntent error response #843
• @finos/fdc3-maintainers to review regenerate context_types after valuation correction #842 to enable NPM module release

Rolled over from previous meetings:

• @kriswest or volunteer: raise PR to resolve Add /intents and /contexts endpoints to the AppD API #719
  • Add optional/recommended API endpoints for /intents and /contexts to the appD API.
• @kriswest or volunteer: raise PR to resolve The AppIntent interface incorrectly describes an intent #312
  • deprecate interop.intents.listensFor[<intentname>].displayName field in appD and AppIntent.intent.displayName in the API types and add explanation of using intent name for display to documentation.
• @kriswest or volunteer: raise a PR to resolve Error cases need better documentation, they are rejected Promises #807
  • Clarify (in the 2.0 version of the documentation) that FDC3 API calls the result in errors should reject with an Error object, rather than a String.
  • Clarify docs and comments on Errors and and findIntent error response #843
• @kriswest or volunteer: raise a PR to resolve Deprecate appD name field and make it optional #820
  • Make name optional and deprecated in appD records and making title required.

Untracked attendees

Full name	Affiliation	GitHub username

[Julia-Ritter]

Julia / FINOS

[kriswest]

Kris West / Cosaic 🚀

[milindchidrawar]

Milind / Singletrack

[openfin-johans]

Johan Sandersson / OpenFin 🎁

[pierreneu]

Pierre Neu / Symphony

[luiemilio]

Luis Espinola / OpenFin

[dimiter-georgiev]

Dimiter Georgiev / Symphony

[bingenito]

Brian Ingenito / Morgan Stanley

[timjenkel]

Tim Jenkel / Wellington

[robmoffat]

Rob / FINOS

[MichaelMCoates]

Michael Coates / OpenFin

[nkolba]

Nick / Connectifi

[mistryvinay]

Vinay Mistry / Symphony

[robmoffat]

Security scanning tools being used at FINOS: https://github.com/finos/security-scanning