-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2026 02 11_Atlantic
- Date&Time: 2026-02-11 14:00 UTC
- Chair: Dima Postnikov (standing in for Nat Sakimura, who was unavailable)
- Peter Stanley (OBL)
- Mike Leszcz (OIDF)
- Joseph Heenan (OIDF & Authlete)
- Matthew Murphy
- Damian Hickey (Duende Software) (new participant)
- Robert Gallagher (Mastercard)
- Imran Ulghar (OBL)
- Dima Postnikov (Chair)
- Bjorn Hjelm
- Kosuke Koiwai
- Filip Skokan
- George Fletcher
- Chris Robbertse (Open Banking)
Mike Leszcz presented the OpenID Foundation Note Well, which references:
- OIDF Code of Conduct policy
- OIDF Antitrust policy
- Requirement for a signed Contribution Agreement to contribute to OIDF Working Groups
- Requirement for a signed Participation Agreement to participate in OIDF Community Groups
- All reference policies available at: openid.net/policies
Damian Hickey (Duende Software, Chief Architect and Engineering Director) introduced himself. Key points:
- Duende Software is an OIDF member and builds an SDK and .NET tooling for OAuth, OIDC, and related security systems.
- Duende's identity server can be configured to be FAPI 2.0 conformant as well as OAuth 2.1 / draft 14 conformant.
- Damian is exploring potential integrations between FAPI conformance and GRC (Governance, Risk, and Compliance) systems using the OSCAL standard — he raised Bitbucket Issue #839 and was invited by Nat to join the call.
- Confirmed that Duende Software has signed the necessary participation and contribution agreements.
All 2026 internal meetings and industry events have been added to all OIDF calendars (Google Calendar, website calendar, and internal director calendars). Mike Jones and other colleagues were noted to be attending the TIIME Unconference in Amsterdam during the week of the call.
Upcoming events:
- February 9–12 — TIIME Unconference, Amsterdam
- March 9–13 — ISO/IEC JTC 1/SC 27 WG Meeting, Nürnberg, Germany
- March 14–20 — IETF 125, Shenzhen, China
- March 16–17 — ISO/IEC JTC 1/SC 27 Plenary, Nürnberg, Germany
- March 16–19 — FDX Global Summit 2026, Washington, DC
- April 27 — OIDF Workshop (prior to IIW Spring 2026), Mountain View
- April 28–30 — IIW Spring 2026, Mountain View
- May 12–15 — ID4Africa, Abidjan
- May 19–22 — EIC 2026, Berlin
- May 27–29 — OAuth Security Workshop (OSW), Leipzig, Germany
- June 2 — FIDO Authenticate APAC 2026, Singapore
- June 15–18 — Identiverse, Las Vegas
- June 22–24 — DICE 2026, Copenhagen
- July 18–24 — IETF 126, Vienna
- September 1–3 — Global Digital Collaboration Conference 2026, Geneva
- September 14–17 — ISO/IEC JTC1/SC 17 Plenary, Chengdu, China
- October 19–21 — FIDO Authenticate 2026, Carlsbad, CA
- November 2 — OIDF Workshop (prior to IIW Fall 2026), Mountain View
- November 3–5 — IIW Fall 2026, Mountain View
- November 14–20 — IETF 127, San Francisco
- December 7–9 — Gartner IAM US, Las Vegas
To add a 2026 event to the calendar, contact: mike.leszcz@oidf.org
Chile / CMF:
- Regulation is planned to be in place by August 2026. A few FAPI 2.0 certifications are anticipated in 2026, with the ecosystem going live in earnest in early 2027.
- Minsait is CMF's implementation partner; confirmed the week of January 19th that their OIDF membership is in process so they can provide directed funding.
- Domingos and Mike L had a follow-up call the week of January 19th to address questions regarding the CMF FAPI Profile.
- CMF is now considering adopting Shared Signals. The next call with CMF will include a Shared Signals WG co-chair and Thomas from the certification team.
SAMA (Saudi Arabia):
- Directed funding is anticipated in early 2026 to support development of a new KSA FAPI 2.0 Profile. The ecosystem will then certify to the new profile.
UAE:
- Domingos and Mike L had a follow-up call the week of January 19th regarding the transition from FAPI 2.0 Implementer's Draft (ID) to FAPI 2.0 Final.
- Minimal impact on ecosystem partners (primary TTPs) and conformance tests is expected.
- UAE and partner Ozone believe the heavy lift is communicating to TTPs and are coordinating those efforts currently. The transition is anticipated sometime in Q2 2026.
OFB & OPIN:
- 2026 certifications confirmed.
Peru:
- Gail and Domingos had a follow-up call the week of February 2nd covering Peru's interest in the Ecosystem Support Community Group and OIDF Working Groups.
- Peru's adoption of FAPI 2.0 is well underway. They will share an updated roadmap by the end of February.
- Peru is reviewing the Ecosystem Support CG Participation Agreement and a contribution agreement to participate in the FAPI WG and other OIDF working groups. They are also looking at OIDF membership.
- OIDF has offered an ecosystem outreach workshop to introduce OIDF, OpenID specifications, and the value of conformance and certification, as has been done in other markets. Coordination of this workshop will begin in coming weeks.
- OpenID Federation 1.0 Final Specification — Vote is open until next Tuesday. Quorum must be reached; an abstain vote counts toward quorum. Vote link
- Authorization API 1.0 Final Specification — Approved. Announcement
- OpenID Connect Relying Party Metadata Choices 1.0 Final Specification — Public review period started January 9, 2026. Voting scheduled to start March 11, 2026.
2. Special Item: OSCAL Integration with FAPI (Issue #839)
Link: https://github.com/openid/fapi/issues/839
Damian Hickey introduced Issue #839, which he raised on Bitbucket and was invited by Nat to discuss with the group.
- Duende's identity server can be configured to be FAPI 2.0 conformant. Damian explored the next stage: automated compliance reporting for auditors.
- Auditors need to understand if a system is fully or partially compliant, what remediations exist, and whether configuration drift has caused non-compliance over time.
- Duende is building an HTML/PDF report for auditors that gives a configuration breakdown of the identity server. Looking further ahead, Damian explored OSCAL (Open Security Controls Assessment Language) — a NIST-driven standard for machine-readable schema defining how a system conforms to a set of controls.
- The core question: can an OSCAL profile be defined for FAPI 2.0 that maps FAPI controls to machine-readable, auditable representations consumable by GRC systems (such as Drata, Vanta, etc.)?
Dima Postnikov: FAPI has a narrow set of requirements focused on security and interoperability. Conformance testing already covers everything prescribed by the profile, but there are gaps — things that must be true for the system to be secure (e.g., storing private keys in a secure location) that cannot be verified during conformance test execution. Automating those untested assumptions in machine-readable form could add value. The topic is potentially broader than FAPI alone, but FAPI-specific controls could be a focused starting point.
Joseph Heenan: New to OSCAL. Generated a sample OSCAL catalogue for FAPI via Codex (ChatGPT) to explore feasibility — link shared in chat: gist.github.com/jogu/aa1fe54248e389edbf51eb8bbc523fc3. Noted that conformance test failures could potentially be written out as OSCAL findings. Observed that current conformance tool adoption has been driven by regulators mandating conformance by law; OSCAL could represent an alternative pathway via auditors rather than regulators. Judged the topic worth further investigation. After the main discussion, confirmed that BCP 195 states that implementations should support TLS 1.3.
George Fletcher: Questioned whether evidence gathering via OSCAL would be globally applicable or jurisdictionally specific, and whether feasibility exists for a single viable profile covering multiple jurisdictions. Noted the challenge of maintaining layered controls when global and jurisdiction-specific controls diverge. Suggested OSCAL feels orthogonal to the core FAPI spec — more of a useful GRC evidence-gathering tool — and expressed uncertainty about how to turn it into a formal standard alongside FAPI.
Damian Hickey: Acknowledged jurisdictional complexity. Noted that OSCAL supports layered profiles — a base layer with jurisdiction-specific extensions on top — which could help manage variance. Emphasized that the envisioned OSCAL profile would be complementary to, not a replacement for, conformance testing: the conformance test is an outside-in black-box check, whereas an OSCAL endpoint would be an inside-out self-assertion. Both would be needed; an auditor would still need to verify that a system's OSCAL endpoint is not simply asserting compliance without basis.
Dima Postnikov: Agreed with the complementary nature of the two approaches. Also raised trust marks as an alternative mechanism (e.g., "this entity has been certified by the OpenID Foundation as a compliant implementation as of date X"). Recommended the issue also be discussed in the Ecosystem Support Community Group, which has broader ecosystem representation. The group consensus was that no one is objecting to the topic; it is worth exploring within the FAPI context.
- Damian Hickey: Develop a few specific OSCAL examples relevant to FAPI 2.0 (focusing on controls that are within FAPI scope), and explore an initial OSCAL profile draft for FAPI. Update Bitbucket Issue #839 with findings.
- Dima Postnikov: Mention the OSCAL topic in the next Ecosystem Support Community Group call.
The following PRs were reviewed briefly by Dima Postnikov. Several are awaiting Nat's attention or Dave Tonge's input before final decisions can be made.
| PR | Topic | Status |
|---|---|---|
| PR #529 | Strict validation / security consideration edit | Awaiting Nat; to be progressed without him where possible |
| PR #545 | AS rejecting non-state items | A few approvals received; good for Dave to address |
| PR #541 | Synchronization / editorial fix | Reviewed; mostly editorial |
| PR #540 | DPoP vs. MTLS / implementation guidelines | Under review; to be left for now |
Note: Several PRs contain comments from Filip Skokan — mostly editorial but with some substantive items that warrant discussion. Dima suggested reviewing them individually on the next call so the group can accept or reject them one by one.
4.1 Issue #840 — TLS 1.3 Requirement
Link: https://github.com/openid/fapi/issues/840
Joseph Heenan provided an update:
- He reviewed the relevant draft IETF spec and found it is less strong than a previous response on the TLS mailing list had suggested. The draft spec states only that new protocols using TLS must specify TLS 1.3 as their default — this would not apply to HTTP as an existing protocol.
- When that RFC is published and incorporated into the BCP, it is unlikely to trigger required updates to the FAPI conformance tests or implementation requirements.
- However, BCP 195 currently already states that implementations should support TLS 1.3.
- Joseph has raised a ticket in the conformance suite to begin flagging implementations that do not support TLS 1.3 as a warning (non-blocking — would not prevent certification). This aligns with Dima's intent to give implementers a signal.
- The group agreed that, absent additional feedback requiring normative changes, Issue #840 can likely be closed. The conformance suite warning is the appropriate action.
4.2 Issue #838 — FAPI 2.0 Attacker Model: ISO/IEC 26083-2
Link: https://github.com/openid/fapi/issues/838
Dima noted this issue has an additional set of comments related to the Attacker Model document. Most comments appear to be editorial. The group has conflicting style conventions across specifications; the approach is to move common goals to a shared section applicable to both the Security Profile and Attacker Model. A draft version of such a document has been created. Further review of individual comments is deferred to the next call.
4.3 Issue #837 — FAPI 2.0 Security Profile: ISO/IEC 26083-1
Link: https://github.com/openid/fapi/issues/837
Related to Issue #838 above. Similar editorial and style-consistency comments. Deferred to next call for detailed review.
4.4 Issue #648 — Define Requirements for OpenAPI / FAPI Integration
Link: https://github.com/openid/fapi/issues/648
Chris Robbertse (Open Banking) updated the group:
- On Monday, February 9th, Chris joined a newly established OpenAPI Initiative Special Interest Group for Industry Standards — the first meeting of the year for that group.
- Several participants in the OpenAPI SIG are keen to continue conversations about incorporating FAPI within the OpenAPI ecosystem. Conversations are ongoing.
- Peter Stanley confirmed there was prior interest in arranging a dedicated session between the two groups. The timing of regular FAPI calls does not work for the OpenAPI representatives, so a separate call for interested parties from both sides was proposed previously.
- Dima noted that Nat's time zone constraint need not limit participation — other FAPI WG members (e.g., Dima himself, Dave Tonge, Lucas) can represent the working group. A representative from the FAPI WG would attend to ensure FAPI 2.0 (and potentially FAPI 1.0) security profile variants are properly represented in any OpenAPI specification work.
- The group agreed not to wait for the next weekly meeting to coordinate. Peter and Chris will reach out via Slack first, and if needed, also use the mailing list.
Action Items:
- Peter Stanley & Chris Robbertse (OBL): Contact the OpenAPI SIG to identify available time slots for a liaison call. Use the FAPI WG Slack channel to coordinate with interested FAPI WG members and identify attendees based on time zone availability.
4.5 Issue #595 — Create a Resource Server Profile on Top of FAPI 2.0
Dima noted the group previously decided to discuss this topic in the Ecosystem Support Community Group and bring conclusions back to the FAPI WG. No new updates were reported this week.
4.6 Issue #594 — Address Concerns Related to JWT
Link: https://github.com/openid/fapi/issues/594
Dima noted this issue was a reaction to discussions on a mailing list, primarily around NIST, where not all participants understand the nuances of JWT. Progress is being made; documentation and linked reference documents are being prepared. Dima regards this as one of the more active issues currently.
No additional business was raised. The call closed on time.
| Owner | Action | Due |
|---|---|---|
| Damian Hickey | Develop specific OSCAL examples relevant to FAPI 2.0; draft an initial OSCAL profile for FAPI; update Bitbucket Issue #839 with findings | Ongoing — report back to group |
| Dima Postnikov | Raise the OSCAL topic at the next Ecosystem Support Community Group call | Next CG call |
| Peter Stanley & Chris Robbertse | Contact OpenAPI SIG to find liaison call time slots; coordinate via FAPI WG Slack channel | Ongoing |
| All OIDF Members | Vote on OpenID Federation 1.0 Final Specification (deadline: following Tuesday) | Next Tuesday |
| All | Review Filip Skokan's comments on ISO PRs (#838 / #837) ahead of next call for accept/reject discussion | Next call |
Weekly Atlantic Call — same time next week.