Skip to content

FAPI_Meeting_Notes_2023 09 27_Atlantic

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

FAPI WG Agenda & Meeting Notes (2023-09-27)

The meeting was called to order at 14:03 UTC.

1.   Roll Call (Nat)

  • Attendees: Nat, Brian, Bjorn, Kouske, Peter Stanley, Daniel, Peter Wallach, Robert, Dave, Mike L. Michael Palage, Takahiko.
  • Regrets:

2.   Adoption of agenda (Nat)

  • Adopted as is.

3.   Events (Mike L.)

3.1.   IIW Workshop

OIDF planning workshop prior to IIW on Oct 9 at Cisco in Mountain View, California. Need to register by Oct 2 Noon PST.

Link: https://openid.net/registration-workshop-october-9-2023/

3.2.   FDX Summit

4-6 Oct. Joseph and Mike will be presenting FAPI certification. Lukasz will also be presenting FAPI ecosystem and profiling.

4.   Liaison/Ext Org (Mike/Chris)

4.1.   OFB

Open Finance Brazil making FAPI profile updates.

Test suite is going to be completed in next couple of days.

Proposed milestones for recertification - Feb to Apr. etc.

4.2.   OIB

OIB recertifications will follow afterwards. (May-June 2024)

Will be adopting same profiles as OFB

4.3.   ISO/SC27/WG5

Time to send liaison statement.

Will have meeting in 3 weeks.

Ping Nat if there is anything to be stated there.

5.   PRs (Dave)

  • PR #432 - Update http signing intro text
    • Clarifies that requests or responses or both can be signed
    • Please review.
  • PR #433 - make clear that requests and responses can be signed independently
    • Previous text assumes that requests would always be signed
    • Created two clauses to address the issue.
    • Also links the response to the signed request
    • Please review.
  • PR #417 - ciba refactor to support FAPI2
    • Refactored and moved to new file name and format
    • This PR is to make CIBA applicable to both FAPI1 and FAPI2.
    • Signed request are optional in FAPI2
    • Removed text concerning requirement for user to authenticate to a certain level
    • The PR is ready for review. It is big but much appreciated.

6.   Issues (Dave)

  • #610 - Review FAPI1 security considerations for clarity
    • FAPI2 has some intro text in security considerations that describe the theoretical attacks and preconditions but do not apply in many ecosystems. Same text should apply to FAPI1 also
    • ##`#8 <https://github.com/openid/fapi/issues/8>`__.3.2 Client credential and authorization code phishing at token endpoint
      • private keys jwt keys are not exposed but code and assertions can be replayed
      • current text does not have details of attacks
      • attacks are independent of client authentication method so they would apply even if using MTLS
    • ##`#8 <https://github.com/openid/fapi/issues/8>`__.3.3 Identity provider (IdP) mix-up attack
      • Client is registered with multiple IdPs and a rogue IdP returns the same client_id as a honest IdP
      • FAPI2 uses issuer parameter for mitigation
      • Mitigations are present
    • ##`#8 <https://github.com/openid/fapi/issues/8>`__.3.5 Access token phishing
      • Have 2 layers of defense (metadata document and at_hash)
      • Preconditions do not apply in many ecosystems and require powerful attacker
      • Align wording with FAPI2.
      • Need to define access token phishing.
      • OAuth BCP mentions AT phishing so FAPI2 does not explicitly talk about it.
      • Aligning with FAPI2 will involve adding lots of text to both
    • ##`#8 <https://github.com/openid/fapi/issues/8>`__.4.2 Authorization request parameter injection attack
      • References the IdP confusion attack which already has robust mitigations using request object or request_uri
    • ##`#8 <https://github.com/openid/fapi/issues/8>`__.4.3 Authorization response parameter injection attack
      • Does not apply because response only contain the authorization code
      • The wording of the first one could be improved but others seem to be fine.
    • Some preconditions requirements:
      • a powerful attacker,
      • attacker has control of an AS that is trusted by the client to issue access tokens for the targeted resource server
  • #591 - Clock skew
    • shall be at least 10 seconds and should not be more than 60 seconds.
  • #614 - DPoP Reference
    • #614 Assigned to Daniel
  • #607 Authentication property of FAPI 2.0
    • Assigned to Daniel
    • Clarify that identity management layer is out of scope
  • #596 - Make clear that requests and responses to resource servers don't have to be bound
    • discussed as part of PR #433
  • #613 - Changes to introduction of http signing section
    • discussed as part of PR #432
  • #555 -T racking: Implementers of FAPI 1.0 and FAPI 2.0
    • Updated information

7.   AOB (Nat)

  • n/a

The meeting adjourned at 15:00.

Clone this wiki locally