-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2026 04 01_Atlantic
- Date&Time: 2026-04-01 14:00
- Chair: Nat Sakimura
| Name | Organization |
|---|---|
| Nat Sakimura | OIDF / Chair |
| Joseph Heenan | OIDF & Authlete |
| Filip Skokan | Okta |
| Lukasz Jaromin | Raidiam |
| Robert Gallagher | Mastercard |
| Matthew Murphy | Mastercard |
| Kosuke Koiwai | KDDI |
| George Fletcher | Practical Identity |
| Christopher Robbertse | Open Banking Limited |
| Imran Ulghar | Open Banking Limited (OBL) |
Regrets: Dave Tonge (co-chair), Mike Leszcz
Nat presented the OIDF Groups, Activities & Events Note Well (PDF version). Reference: OIDF Note Well (June 2025)
Recording policy reminder: Only Meeting Organizers may record OIDF-Sponsored Activities. Attendees are not permitted to make independent audio or video recordings. Reference: OIDF Notes & Recordings Policy (September 2025)
Attendees entered their names in chat (see table above).
Agenda adopted as proposed without additions.
Draft agenda topics:
- Note Well
- Roll Call
- Adoption of Agenda
- Events
- External Orgs & Liaisons
- Recent "spam" in the mail list
- Bitbucket Migration
- PRs (Dave)
- Issues (Dave)
- AOB (Nat)
Nat relayed the events calendar update sent by Mike Leszcz. Key note: registration is required for the OIDF Workshop prior to IIW Spring 2026. Any additional events should be sent to mike.leszcz@oidf.org.
| Date | Event | Location |
|---|---|---|
| April 14 | OECD Working Party on Digital Security | Paris |
| April 22–23 | IAM Tech Day | São Paulo |
| April 27 | OIDF Workshop prior to IIW Spring 2026 (registration required) | 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 |
OIDF Workshop registration: https://openid.net/registration-open-for-openid-foundation-hybrid-workshop-on-mon-27th-april-2026/
Mike Leszcz and Domingos Creado held a call with the CMF and Minsait teams on March 27. Key outcomes:
- Regulation is confirmed to be in place by August 2026.
- A few FAPI 2 certifications are anticipated in 2026 as a "pilot," with the ecosystem going live in earnest in early 2027.
- Shared Signals adoption is confirmed for a later phase.
- Domingos now has access to the mock bank and will soon have access to the CMF directory to support test development.
- CMF and Minsait will identify three ecosystem partners to help test the tests.
Directed funding has been received to support development of a new KSA FAPI 2 Profile. Domingos Creado is leading this work and is in contact with the SAMA team to obtain access to the published profile and mock bank. Ecosystem participants will certify to the new profile once it is in production.
A third organization is now testing the client credentials grant conformance test code. They ran tests on March 31 and encountered failures that they confirmed are issues in their own implementation — confirming that the tests are finding real problems. Joseph reported that the tests should be ready to launch for actual certifications shortly, pending a production release with the latest changes. Mastercard will be prompted to prepare their formal certification submission once the release is deployed.
-
iGov Profile for OAuth 2.0 (Implementer's Draft): Member vote is open until Sunday, April 12. Abstentions count toward quorum and are appreciated. Reference: https://openid.net/notice-of-vote-to-approve-proposed-implementers-draft-of-international-government-assurance-profile-for-oauth-2/
-
OpenID Federation 1.1 Final: Public review is ongoing. Voting scheduled to start Monday, May 4. Reference: https://openid.net/public-review-period-for-proposed-openid-federation-1-1-final-specifications/
-
OpenID Connect Advanced Syntax for Claims (ASC) 1.0 (Implementer's Draft): Public review started March 16, 2026. Voting scheduled to start Friday, May 1. Reference: https://openid.net/public-review-period-for-proposed-implementers-draft-of-openid-connect-advanced-syntax-for-claims-1-0/
-
OpenID Connect Relying Party Metadata Choices 1.0 Final Specification: Approved. Congratulations to all contributors. Reference: https://openid.net/openid-connect-relying-party-metadata-choices-1-0-final-specification-approved/
Nat reported that a registered user who has signed the OIDF contribution agreement has been sending unsolicited messages to both the OpenID Connect mailing list and the FAPI mailing list. The cause is unclear (possibly a compromised email client). Moderation has been re-enabled. Members were informed to be aware of this situation.
Nat provided a status update on the planned migration away from Bitbucket, which is being shut down (issues and wiki features).
- Wiki migration: Relatively straightforward. The wiki is a Git repository and can be pulled and pushed to GitHub.
- Issues migration: More complex, but partial migrations from Bitbucket to GitHub have been done for other working groups and are feasible.
- Source code (Git) migration: Not a problem.
- Past PRs and their comments: Potentially problematic; Nat noted more investigation is needed.
Members with relevant experience or tooling knowledge were invited to share it.
Dave Tonge was absent. Nat noted there is one PR to forward. This item was deferred.
Issue #844 — FAPI Not Currently Compliant with CNSA 2.0
Filed by: Joseph Heenan Reference: https://github.com/openid/fapi/issues/844 Related draft: https://panva.github.io/CS24/ (Filip Skokan)
Filip Skokan provided a detailed explanation:
Background: CNSA 2.0 is a US government migration document for companies wishing to engage with US government services via FedRAMP. The most stringent FedRAMP profile — required for working with the DoD and similar agencies — is CNSA 2.0 aligned. Under CNSA 2.0:
- Classified data must not be hashed with SHA-256.
- Post-quantum key agreement and digital signatures are required.
- SHA-3 is reserved exclusively for signing firmware.
- In practice, systems running under this constraint implement it similarly to FIPS certification — unsupported ciphers are disabled at the runtime or certified crypto module level, making them unavailable entirely.
Impact on FAPI: Because SHA-256 is unavailable in CNSA 2.0 environments, the following mechanisms are blocked:
- PKCE (S256): Hard-coded to SHA-256.
- DPoP: Requires SHA-256 for its digests.
- MTLS: Puts the SHA-256 thumbprint of the client certificate into the access token.
For other areas (post-quantum digital signatures, symmetric encryption), existing or easily profileable mechanisms exist. For example, upgrading from PS256 to PS384 also upgrades the hash used for AT hash in ID tokens — those cases resolve themselves. But PKCE, DPoP, and MTLS sender-constrained tokens have no current mechanism to substitute a different hash algorithm, as they are hard-coded to SHA-256 in the specifications.
Filip's draft: The draft at https://panva.github.io/CS24/ proposes adding SHA-384 and SHA-512 as alternatives and optionally defines negotiation mechanisms so that systems running under constrained crypto environments can still use PKCE, DPoP, and MTLS. The draft is not a call to migrate the whole OAuth ecosystem away from SHA-256 — it is targeted specifically at enabling CNSA 2.0-aligned deployments.
Feedback received at OAuth WG: There is interest in registering additional claims (broadly uncontroversial), but scepticism about the negotiation mechanisms. Some reviewers want negotiation mechanisms without the additional SHAs; others requested SHA-3 (which Filip considers inadvisable, to avoid ecosystem fragmentation).
Nat's related issue: Nat flagged Issue #846 regarding the updated Japanese crypto recommendations (CRYPTREC), published that Monday, which will eventually mandate moving from 128-bit to 192-bit minimum security strength — including for hashes, which would also exclude SHA-256. This transition is not enforced immediately but is expected to be enforced in approximately five years.
Discussion: The group agreed that:
- FAPI must begin preparing for this transition now, given the time needed for standardisation and adoption.
- The OAuth WG needs to define the mechanisms (this is Filip's draft work there), after which FAPI profile updates will be comparatively straightforward.
- Wherever FAPI hard-codes "shall use S256," those references will need to be relaxed once the underlying OAuth specifications provide alternatives.
Call to action: Filip will share the link to the relevant OAuth mailing list thread (posted to chat during the meeting — see reference links below) so that FAPI WG members can provide feedback directly.
Issue #846 — Crypto Strength: JP Crypto Recommendation
Reference: https://github.com/openid/fapi/issues/846
Noted during Issue #844 discussion above. The updated Japanese government crypto recommendations (CRYPTREC) now indicate a transition from 128-bit to 192-bit minimum security strength, which would eventually affect SHA-256. Enforcement is approximately five years away. Nat filed this issue to track the concern. No further action at this stage; monitoring.
Issue #842 — Approval to Launch Client Credentials Certification Tests
Reference: https://github.com/openid/fapi/issues/842
Joseph summarised the state of the FAPI 2 Client Credentials Grant certification tests:
- Authorization server (AS) tests: Three organisations have tested these. The group is satisfied and ready to go ahead with a production release.
- Client (RP) tests: Only internal certification team testing has been done — no external parties have run them.
Joseph's recommendation (wearing his certification team hat): Launch the client tests alongside the AS tests without waiting for the usual three-party external validation. Precedent exists from the FAPI 2 launch. The tests have been validated by running the client conformance test against the AS conformance test to verify self-consistency.
George Fletcher expressed support for publishing: if tests are available only in a beta state, potential users may not find them or may assume they are unavailable. Contacting organisations that already completed AS-side certification to ask their clients to run the RP tests was suggested as a way to gather additional real-world validation.
Resolution: The group agreed to proceed as follows:
- Once the server-side bug is fixed and a production release is made, go ahead with the AS-side certification launch.
- For the client-side tests, Joseph will contact the two non-Mastercard AS testers to ask if they have clients that could run the RP tests.
- Robert Gallagher (Mastercard) will take the same ask internally to Mastercard.
- Once that outreach is done (even if no external testing results), the working group is inclined to proceed with publishing the client tests.
Issue #831 — Browser Swapping Attacks
Reference: https://github.com/openid/fapi/issues/831
Filed by Joseph Heenan, based on presentations at IETF 124. Filip and George reported no material progress from IETF 125 — the OAuth WG had only one meeting slot and it was occupied by other topics.
Filip noted that Dick Hardt has been proposing a mechanism to the HTTP WG that could, in theory, replace the use of query strings as the redirect-based transfer mechanism, which would help address browser-swapping attacks. However, this proposal did not gain traction in the HTTP WG. The HTTP WG indicated they are not interested in doing this work, while leaving open the possibility of the OAuth WG extending HTTP itself. Browser buy-in to the proposed mechanism was also questioned.
Resolution: No action for FAPI WG at this time. Continue monitoring the OAuth and HTTP WG mailing lists.
Issue #434 — Certification Team Query: Error Messages
Reference: https://github.com/openid/fapi/issues/434
An older issue. The certification team's current guidance is that error messages presented to users must be factually correct from the perspective of both the end user and the relying party developer. Concretely, responding "please try again later" to a developer who has specified an invalid redirect URI is not factually correct and will not be accepted during certification review. Joseph confirmed this policy has been in place for roughly two years with little pushback. It is consistent with comments previously made by Serkan.
Action: Nat to check whether this guidance has been formally incorporated into the FAPI deployment advice document. If not, it should be added.
Issue #273 — Security Considerations: Large Access Tokens
Reference: https://github.com/openid/fapi/issues/273
Nat noted this is a dangling issue that is being addressed by PR #539, which has been merged. Nat indicated he can close this issue.
No additional business was raised. Nat closed the meeting approximately five minutes early, noting that the eKYC-IDA Working Group call follows immediately.
| # | Action | Owner | Due |
|---|---|---|---|
| 1 | Share OAuth mailing list thread link for Filip's CNSA 2.0 / SHA hash draft (CS24) so FAPI WG members can provide feedback | Filip Skokan | Done (posted to chat during meeting) |
| 2 | Contact the two non-Mastercard AS-certification testers to ask if they have clients available to run FAPI 2 Client Credentials RP tests | Joseph Heenan | ASAP |
| 3 | Internally check whether Mastercard clients can run FAPI 2 Client Credentials RP tests | Robert Gallagher (Mastercard) | ASAP |
| 4 | Schedule a production release for Client Credentials Grant test suite; prompt Mastercard to prepare formal certification submission | Joseph Heenan / Cert Team | ASAP |
| 5 | Check whether error message guidance (Issue #434) has been incorporated into FAPI deployment advice; add if missing | Nat Sakimura | Next call |
| 6 | Resolve Issue #273 (large access tokens) as addressed by merged PR #539 | Nat Sakimura | Next call |
| 7 | Continue investigating Bitbucket migration tooling, particularly for migrating past PRs and comments | Nat Sakimura | Ongoing |
| 8 | Cast member vote on iGov Profile for OAuth 2.0 Implementer's Draft before voting closes | All OIDF members | April 12, 2026 |
The next FAPI WG Atlantic call will be held the following week. The eKYC-IDA Working Group call followed immediately after this session.