1.   Roll Call (Nat)

• Attendees: Tim, Nat, Perdum, Robert, Brian, Peter, Lukasz, Peter Wallach, Mark Andrus, Dave Tonge, Kosuke Koiwai. Bjorn, Takahiko
• Regrets:

2.   Adoption of agenda (Nat)

• Adopted as is.

3.   Victorrio

Remembrance for Victorrio who passed away this weekend for his great contributions to the OIDF.

4.   Events (Mike L.)

5.   Liaison/Ext Org (Mike/Chris)

Camara Project —------------------ formal liaison agreement is in place

6.   Security Analysis

Security Analysis report has been sent to the WG

https://lists.openid.net/pipermail/openid-specs-fapi/attachments/20231009/88f6be44/attachment-0001.pdf

Tim provided a summary of Security Analysis +

• FAPI 2 MS
• DCR
• DCM
• FAPI-CIBA

Use Web Infrastructure Model (WIM) with mathematical definitions and semantics.

Application FAPI 2 model is layered on top

Defined mathematical security properties and proved properties.

Assumptions are made and properties are proven within these models.

FAPI 2.0 Security Goals from Attacker Model

• Authorization - no attacker can access resources belonging to a user
• Authentication - no attacker is able to log in at a client under the identity of a user
• Session Integrity - no attacker is able to force a user to use resources of the attacker
  • no attacker is able to force a user to be logged in under the identity of the attacker

Same goals for DCR and DCM

Message Signing specifies non-repudiation requirements for * PAR * Authorization Responses * Introspection Responses * Resource Requests/Responses

Assumptions in section 6 of report * FAPI-CIBA - User starts flow with their own identity * FAPI-CIBA Mitigation for cross device consent phishing attack * Assumptions on Dynamic Client Registration - no initial access tokens but clients are allowed to register

Analysis has 50 pages of proofs

Second assumption for cross device flow references BCP https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/

First assumption assumes user is human and is legitimate user

Nat asked about

#619 - Authentication property of FAPI 2.0

Since FAPI2 does not use OIDC, there is no ID Token. The user might gain access to previous session resources by mistake when reauthenticating but using a different account.

Should be the responsibility of the client to make sure the user is the same.

Should be OK because the user is the same user and not an attacker and resource belongs to the same user???

WG is considering adding security considerations to add mechanisms to detect account change, by using OIDC or in conjunction with data payload account IDs if available.

Analysis assumes authentication is always with an ID token.

7.   PRs (Dave)

• PR #435 - Add note on identity and session management
  • Dima suggested alternative wording with doesn’t use the term RP
  • Will discuss further
• PR #436 - Add text on conformance testing
  • Dima pointed out that it can be used for wider audience than those using OIDC
• PR #437 - move MTLS Protection of all endpoints to SP
  • Moves clause from Message Signing to Security Profile
  • But will do later due to review process
• PR #438 - attempt to clarify code phishing attack in fapi1
  • Current wording sounds like attack is prevented however when using MTLS, private key corresponding to TLS certificate is not exposed to attacker, but there is potential for phished code to be injected into an honest client flow
  • It’s not just about leakage but also what attacker can inject into the misconfigured endpoint
  • Change to “potential for a phished code to be injected into a different flow involving a honest client”
• PR #439 - adjust scope to make clear its not just clientS
  • added additional scopes for clarification besides those just for clients
  • Added AS and RS security goals to scope
  • generalize REST APIs to “access protected resources at resource servers”
• PR #440 - add text about clock skew
  • shall accept iat/nbf lower bound of 10 seconds and should reject upper bound of 60 seconds in the future
  • added note regarding 10 seconds for interoperability
• PR #441 - make note around audience param clearer
  • clarifies audience value acceptance of token endpoint URLs for interoperability
  • PAR has more explicit restrictions
  • Make note of PAR requirements and recommends them for other endpoints
  • Dave will update PR

8.   Issues (Dave)

NA

9.   AOB (Nat)

• n/a

The meeting adjourned at 15:00.