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.)

4.   Liaison/Ext Org (Mike/Chris)

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)

• #622 - 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.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.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.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.4.2 Authorization request parameter injection attack
    • References the IdP confusion attack which already has robust mitigations using request object or request_uri
  • ### 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
• #603 - Clock skew
  • shall be at least 10 seconds and should not be more than 60 seconds.
• #626 - DPoP Reference
  • #626 Assigned to Daniel
• #619 Authentication property of FAPI 2.0
  • Assigned to Daniel
  • Clarify that identity management layer is out of scope
• #608 - Make clear that requests and responses to resource servers don't have to be bound
  • discussed as part of PR #433
• #625 - 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.