Skip to content

Standard WG Meeting - Feb 27th, 2025 #1522

@kriswest

Description

@kriswest

Date

Thursday 27th Feb 2025 - 10am (US eastern timezone EST) / 3pm (London, GMT)

Zoom info

  • Join Zoom Meeting
  • Meeting ID: 969 4029 4948
  • Passcode: 636931
  • Dial-in:
    Country International Dial-in Toll-free Dial-in
    US +1 929 205 6099 (New York) 877 853 5247
    UK +44 330 088 5830 0800 031 5717
    France +33 1 8699 5831 0 800 940 415
    Find your local number https://zoom.us/u/ad2WVnBzb8

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.

Participation Requirements

Note: Meeting participants are expected to accept the terms of the FDC3 license (Community Specification License), understand the governance process and have a CLA in place.

Please click the following links at the start of the meeting if you have not done so previously.

Tracking Attendance

Note: Meeting participants are expected to add a comment to this GitHub issue in order that we can track attendance of FDC3 project meetings. Please do this at the start of the meeting.

Agenda

Minutes

  • Actions items from previous meeting
    • Still in need of reviewers for GoLang contribution - @kriswest recommends acceptance as @experimental
    • Rolled over actions relating to JSON/Typescript bindings for context
  • 2.2. release status
    • Open PRs accepted and merged before and during the meeting - including FDC3 for the Web implementation, we are just about content complete!
      • Thanks to @robmoffat for restoring release system to working state and performing beta release: Release 2.2.0-beta.1 #1520
        • Some additional work is warranted to simplify the publishing of prereleases - currently requires support from FINOS due to access to NPM account being required
      • Docusaurus site updated to current and versioning script fixed (thanks to @patrocinio , @robmoffat , @kriswest)- eliminating vulnerable dependencies
    • NPM module Beta releases available for testing: https://www.npmjs.com/package/@finos/fdc3/v/2.2.0-beta.1?activeTab=versions - with provenance
    • Additional NPM modules available for constituent parts for the first time
      • Missing readmes for some of the new NPM modules noted, fix needed for final release
    • fdc3-dotnet an docs contain signatures for addEventListener, but there is much still to do to implement the rest of 2.2 support (context type updates)
    • @kriswest requested and received consent to open the adoption vote for 2.2 via email, upon completion of minor tasks (readmes, website release version created)
  • Kickoff: 2.3 scope
    • Strategic initiative
      • @robmoffat provided details of the FINOS boards promotion of a strategic initiative in 2024 for developing better identity and security support in FDC3, the goal of signing up executive sponsors for the initiative
      • A meeting will be held Friday with prospective executive sponsors for the initiative
      • @robmoffat will be spending a significant portion of his time on this initiative in 2024
        • At OSFF NY last year, there was a presentation between Morgan Stanley and Wellington and Symphony, and we looked at FDC3 and encryption. I'd like to expand beyond that, lots of firms interoperating with each other, using secure FDC3.

        • @bingenito: As long as we want to facilitate between selll side and buy side, it's a show stopper until we have identity figured out.
        • @kriswest: We also need to make sure we confirm user identities, especially for workflows that spread across multiple identities. If one person can send things to another user, you need to be able to confirm those users. We have to figure out both APP identities and USER identities.
        • @robmoffat: Doing things in the browser makes things so much more public than just keeping things on the desktop.
        • @kriswest: There are more FDC3-supported environments being released in 2024. FDC3 is being heavily used inside firms, but there are various firms releasing Desktop Agents and whole suites of apps that use FDC3. These will need to integrate with other DAs and apps on the Desktop, which is likely to make both Desktop Agent Bridging and Identity far more important concepts than they are today.
    • OSFF London CFP is open
  • Should the desktop agent support both unqualified appIds and fully qualified ones? #1475
    • The definitions of unqualified (e.g. myApp) and fully-qualified (e.g. myApp@appd.example.com appIds, and the problem they present was discussed
      • including the impact of that issue on the FDC3 conformance framework, which hard-codes unqualified IDs and will not pass (correctly written) DAs that fully qualify its apps without supporting some form of resolution between the two types.
    • Method proposed in Resolving Fully-qualified and unqualified AppId values #1523: first atetmpt simple string match, then split input fq-appIds on @ symbol, match against first section., OR for uq-appId input, split known fq-appIds on '@' and match.
    • Where uq-appIds were given as input that can result in some edge cases where they match multiple known fq-appIds.
      • Perhaps resolve with a resolver UI as we do with intents? Less clear on other API calls, like .open() and getAppMetadata that don't already use resolver UIs.
        • A number of participants noted that intent resolver dialogs are often not popular
    • Need reviewers to look at Resolving Fully-qualified and unqualified AppId values #1523 and comment on it ready for next month's meeting
  • No defined behaviour when incorrect arguments are passed to API calls #1490
    • Relatively simply issue for creating some additional error messages to return when bad inputs are passed to API calls
    • A participant whether this addition would create new conformance tests?
      • @kriswest: I'm not sure we NEED to have this in conformance, but it should be possible to define a small set of tests. We would not want to test every API call and parameter combination.
      • A participant posited that this wouldn't be an issue in a compiled language like Java - another stated that you could still provide (for example) meaningless string parameters in some cases...
    • Next step: participants review PR and comment ready for next month
  • Add property to support analytics across apps #1290
    • Multiple proposed solutions - a number of participants expressed a preference for passing separate params with metadata (rather than adding them to context messages), and it was noted that this might work well for message signatures
    • @Davidhanson90 drew attention to his additional proposal that we consider switching API calls to accepting a single parameters object as input, as this can soften breaking changes as we add or change parameters on functions. Including the ability to pass multiple contexts to some calls. Could be achieved in a non-breaking way via a function override.
    • @kriswest: There is already a defined way of passing arrays of context, by defining a context type that contains the array - e.g. fdc3.contact and fdc3.contactList - part of the original context design. There were thoughts in the past of using generics. We'd also need to explore the existing function overrides to make sure there are no conflicts.
    • The proposed metadata parameter does at least allow future extension with additional metadata fields, e.g. broadcast(context, metadata) or raiseIntent(intent, context, metadata)
    • Next steps: DA implementors to review and comment then bring it back for a decision on direction.

Action Items

Rolled over from previous meetings:

Untracked attendees

Full name Affiliation GitHub username

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions