Skip to content

FAPI_Meeting_Notes_2026 06 25_Pacific

Jump to bottom
Nat Sakimura edited this page Jul 10, 2026 · 1 revision

FAPI WG Agenda & Meeting Notes (2025-06-25)

Date & Time: 2025-06-25 17:00 PST

Agenda

  1. Roll Call
  2. Adoption of Agenda
  3. Events
  4. External Orgs & Liaisons
  5. PRs
  6. Issues
  7. AOB

Meeting Notes

1. Roll Call & Agenda Adoption

  • Anoop
  • Nat
  • Dima

2. Events Update

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

3. External Organizations & Liaisons

3.1 Ecosystem Partner Updates

4. Member Updates & Reminders

Vote Announcements

5. Pull Requests

6. Issues

Issue #648 — Define requirements for OpenAPI FAPI securityScheme type

Link: https://github.com/openid/fapi/issues/648

Background https://github.com/OAI/OpenAPI-Specification/discussions/5304

Problem Statement

The OpenAPI specification currently supports OpenID Connect as a security scheme type, but lacks a standardized way to express:

  • FAPI family profile types and versions
  • Hierarchical relationships between base profiles and ecosystem extensions
  • Ecosystem-specific metadata and discovery endpoints
  • Conformance profile references for tooling integration

Options Discussed/reviewed

Current 

components:   securitySchemes:     OIDCAuth:       type: openIdConnect       openIdConnectUrl: https://example.com       description: "Log in using our centralized corporate identity provider.”

Option1 : Go with FAPI as scheme

components:
  securitySchemes:
    FAPI:
      type: profile
      profileMetadata:
        name: fapi-20-security-profile
        schema: https://examples.openapis.org/fapi20-profile-schema.json
        servers:
          - name: Development
            url: https://examples.openapis.org/dev/.well-known
          - name: Production
            url: https://examples.openapis.org/prod/.well-known
      ecoSystemMetadata:
        name: brasil-fapi-20-security-profile
        schema: https://examples.openapis.org/brasil-fapi20-profile-schema.json
        servers:
          - name: Development
            url: https://examples.openapis.org/dev/.well-known
          - name: Production
            url: https://examples.openapis.org/prod/.well-known

Option2: Add under the umbrella of OpenID (OIDCAuth).

components:
  securitySchemes:
    OIDCAuth:
      type: fapi-profile
      openIdConnectUrl: https://example.com
      description: "Log in using our centralized corporate identity provider."
      profileMetadata:
        name: fapi-20-security-profile
        schema: https://examples.openapis.org/fapi20-profile-schema.json
        servers:
          - name: Development
            url: https://examples.openapis.org/dev/.well-known
          - name: Production
            url: https://examples.openapis.org/prod/.well-known
      ecoSystemMetadata:
        name: fapi-20-security-profile
        schema: https://examples.openapis.org/brasil-fapi20-profile-schema.json
        servers:
          - name: Development
            url: https://examples.openapis.org/dev/.well-known
          - name: Production
            url: https://examples.openapis.org/prod/.well-known

Discussion on options and feedback

  • Hierarchical relationship is needed — FAPI profiles have parent/child relationships (e.g., Brazil FAPI 2.0 extends FAPI 2.0 baseline)
  • Ecosystem metadata should live separately, pointing to an ecosystem-specific discovery endpoint (like a .well-known)
  • FAPI should be the type, not buried under OIDC — though OIDC can coexist as its own scheme
  • A link to conformance/certification profile is important so tooling knows what to validate against
  • Keep OpenAPI spec simple — point to an ecosystem .well-known for deeper details rather than embedding everything

Action Item

  • Anoop to start a mailing list thread sharing this proposal for broader feedback
  • Dima to reach out to the Ecosystem Community Group for interested participants
  • A small task group (Anoop, Dima, Nat, Joseph) to refine the proposal (options) before July 14
  • Review conformance testing page for official profile names and URLs to populate schema fields
  • Investigate feasibility of a centralized FAPI discovery endpoint for ecosystem registry
  • Assess whether FAPI Foundation needs to host or template the ecosystem .well-known metadata

Clone this wiki locally