-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2026 02 19_Pacific
- Roll Call
- Adoption of Agenda
- Events
- External Orgs & Liaisons
- PRs
- Issues
- AOB
- Anoop
- Nat
- Dima
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
Note: Nat flagged a newly announced OECD Working Party on Digital Security on 14 April. One of the agenda item is security on artificial intelligence, and quantum computing. Mike will add the date to the OIDF calendar.
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.
OpenAPI & FAPI Collaboration :
Chris Robbertse (FAPI WG) arranged for guests from the OpenAPI Initiative (OAI) to present and explore potential collaboration. The following guests introduced themselves:
- Mark Boyd — Co-chair of the OAI Industry Standards Special Interest Group, currently focused on financial services.
- Chris Wood — Content Director at OAI; also works for Ozone and has a keen interest in open banking API standards. He is involved in the OAI Industry Standards SIG.
Chris Wood conducted a screen-share presentation covering two related opportunities for FAPI-OpenAPI alignment, using the UAE Open Banking ecosystem API descriptions (published as OpenAPI 3.0 / Redoc) as a live example.
- Opportunity 1 — Canonical OpenAPI descriptions for FAPI endpoints
Chris demonstrated UAE's OpenAPI description of the Pushed Authorization Request (PAR) endpoint and token endpoint, covering:
-
- Representation of client assertion properties and request payload (acknowledging that in practice these are JWTs, and that OpenAPI 3.1+ / 2020-12 JSON Schema brings improved support for serialized vs. payload separation).
-
- Authorization details (RAR), showing ecosystem-specific consent payload variants (AIS, PIS, insurance data sharing) as open objects within the canonical framework.
-
- Token endpoint responses including the lifecycle representation of rich authorization requests.
The goal is to produce a FAPI-endorsed framework that ecosystems can take, and then apply local overlays (using the OpenAPI Overlay mechanism) to produce jurisdiction-specific descriptions — e.g., UAE-specific consent payloads on top of the common security framework. Chris noted that FDX is currently at risk of developing its own parallel representation, so an authoritative canonical source would benefit multiple ecosystems.
- Opportunity 2 — Extending OpenAPI security schemes to better represent FAPI/OIDC requirements
The current OpenAPI security scheme object is a thin representation (token endpoint URL + scopes), which does not meaningfully capture the security requirements of a real FAPI operation. Chris proposed:
-
- Strengthening the relationship between the OpenAPI security scheme and OpenID Connect / OAuth Server Metadata discovery documents.
-
- Publishing enough in the API description (profiles supported, permitted response types, scope taxonomy, environment URLs — production vs. sandbox) that a developer or AI agent has sufficient context without having to separately parse the discovery endpoint.
-
- Discovery would remain the master record; OpenAPI would carry a meaningful subset.
Chris shared a related GitHub issue at OAI/OpenAPI-Specification #4106 where he had posted exploratory notes.
- 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.
- Strict validation / security consideration edit
- AS rejecting non-state items
- A few approvals received; good for Dave to address
- Synchronization / editorial fix
- Mostly editorial
Issue #838 — FAPI 2.0 Attacker Model: ISO/IEC 26083-2
Link: https://github.com/openid/fapi/issues/840
- Most comments are 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. (review comment from Atlantic call)
OSCAL Integration with FAPI (Issue #839)
Link: https://github.com/openid/fapi/issues/839
Background
- 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.)?
Action Item
- 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.