1.   Roll Call (Nat)

• Attending:
  • Ali Adnan
  • Brian Campbell
  • Dave Tonge
  • Dima Postnikov
  • Filip Skokan
  • Gail hodges
  • Joseph Heenan
  • Kosuke Koiwai
  • Mike Leszcz
  • Nat Sakimura
  • Takahiko Kawasaki
  • Brian Campbell
  • Dima Postnikov
  • Lukasz Jaromin
  • Rifaat Shekh-Yusef
• Regrets:
• Guest:

2.   Adoption of Agenda (Nat)

• Default agenda.
• issue #490

3.   Events (Nat)

4.   Internal Liaison (Nat)

n/a

5.   External Organizations (Nat)

6.   Specs (Dave)

7.   PRs (Dave)

N/A

8.   Issues (Dave)

• #490 - Request for suggestions for tests for FAPI2-Baseline RP/client testing
  • Currently, certification team is working on FAPI 2.0 RP tests
  • Uses FAPI 1.0 tests as starting point, but many are related to front-channel ID token validation, so they do not apply to FAPI 2.0.
  • ID Token validation in backchannel via TLS is not required by specs.
  • Tests related to nonce, state are no longer relevant since they’re not required.
  • PKCE requirement mitigates attacks when nonce/state are not used.
  • Make sure the security analysis model takes into account the lack of state/nonce requirement.
  • Joseph will email Daniel.
  • OP/RP tests already test for PKCE
  • DPoP tests are in development. Many at RS side.
  • RP tests mainly tests happy flow where PKCE/DPoP parameters are sent correctly.
  • There are 20 checks for DPoP at the RS.
  • Filip asked that to perform same checks at AS
  • End to end binding of authorization_code to DPoP was recently added which can apply to PAR.
  • https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-07.html#name-dpop-with-pushed-authorizat
  • Should perform checks for DPoP at PAR endpoint also.
  • Need to check PKCE code_verifier for enough randomness in RP tests
  • Also need to check that code_verifiers are different for each request
  • Requiring AS to check code_verifier reuse may be burdensome
  • ID Token validation should still be performed if returned.
  • More discussions to follow
• #469 - Add protocol version and variant identifier
  • Discussions indicate it’s good in principle
  • May work well for dynamic client registration management endpoints
  • May cause problems for authorization/token endpoints.
  • Wait for formal analysis results before closing
• #479 - Change to the naming of FAPI
  • Nat proposed changing the name to Fortified API since FAPI can be applied to non-financial APIs (healthcare, etc…)
  • WG asked for suggestions for other suitable names
• #477 - fapi2 + dpop nonces
  • DPoP nonces are not required but AS/RS can require clients to support them
  • If there is no substantial security benefit, then don’t require nonces.
  • If security analysis shows problems, then nonces will be required.
  • Put clause that AS/RS must not send nonce
  • FAPI should not prohibit something that is meant to add additional security.
  • Nonce provides liveliness checks for pre-generated proofs and also provides work arounds for time sync issues but the value in the context of FAPI is limited due to confidential client requirement.
  • Interoperability problems will occur if there is no clear guidance.
  • Make PR removing the nonce requirement for review.
  • Can always add it back if problems arise.
• #480 - Baseline: shall support authorization details if scope is not expressive enough needs enhancement to cover standard oidc claims.
  • Currently, there is text that
  • AS shall support the authorization_details parameter according to RAR to convey the authorization clients want to obtain if the scope parameter is not expressive enough for that purpose
  • There was prior discussion to create a separate profile for advance authorization protocol that provides guidance for these use cases and grant management..
  • Text has been removed from Grant management but is still present in Baseline.
  • Separate the advanced authorization requirements from the security profile.
  • Action to remove clause from Baseline.
• #336 - FAPI 2 Baseline - Client types
  • FAPI 2.0 currently requires that AS shall support confidential clients but that is unclear whether that is “shall only” support confidential clients.
  • AS should be free to support other clients for non-FAPI use cases.
  • OAuth 2.1 defines a credential client that has credentials but has no prior relationship which is almost like a confidential client.
  • FAPI will not reference the term credentialed client and the requirement for client authentication disallows public clients.
  • Can put text in the scope that states FAPI 2.0 is to be considered in the context of a confidential client.

9.   AOB (Nat)

n/a

The call adjourned at 15:00 UTC