1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi

Wiki

Clone wiki

fapi / FAPI_Meeting_Notes_2024-03-13_Atlantic

View History

FAPI WG Agenda & Meeting Notes (2024-03-13)

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

1.   Roll Call (Dave)

  • Attendees: Daniel Fett, Nat Sakimura, Peter Wallach, Filip Skokan, Robert Gallagher, Brian Campbell, Dima Posnikov, Dave Tonge, Jacob Ideskog, Kosuke Koiwai, Bjorn Hjelm
  • Regrets:

3.   Events (Mike L.)

3.2.   OAuth Security Workshop

Rome April 10-12 – final call for speakers is open until March 10th.

All details here: https://oauth.secworkshop.events/osw2024

3.3.   OIDF Workshop at Google

on Monday, April 15th in Sunnyvale – registration now open and required: https://openid.net/registration-oidf-workshop-monday-april-15-2024/

3.4.   The OpenID Foundation DCP working group

WG is hosting a hybrid meeting on Friday, April 19, 2024 after IIW Spring 2024. The meeting will allow for in-person and virtual participation and will be hosted at Google in Sunnyvale, CA (address and meeting room to be confirmed).

Note that registration is only required if you are attending in-person:

https://www.eventbrite.com/e/openid-foundation-dcp-working-group-hybrid-meeting-tickets-841453930357?aff=oddtdtcreator.

Please register if you are planning to participate in-person so we can plan accordingly.

3.5.   Identiverse

May 28-31, Las Vegas

OIDF has a meeting room available for use for the duration of the event

Any working groups wanting to hold a F2F meeting should contact Mike Lescz to coordinate.

FAPI WG will hold F2F

3.6.   OIDC Calendar

OIDF calendar on website is current: https://openid.net/calendar/

4.   External Orgs & Liaisons (Mike L.)

4.1.   Brazil

OFBR + OPIN – continue to process FAPI re-certification requests.

4.2.   Certification Team

Certification team has posted a Java developer opportunity and is actively recruiting:

https://openid.net/certification-program-recruiting-java-developer/

4.3.   UAE - (United Emirates)

  • On target to launch later this year.
  • Timeline is still for this calendar year.
  • Open Banking with 8 banks with 80% market share, and 2-3 insurers with car insurance only
  • Later 8 products targeted, second tier of banks and insurance

4.4.   ISO/IEC JTC 1/SC 27/WG 5

  • Liaison statement is to be sent.
  • Info about FAPI 2 that it is close to final. Send the drafts.
  • Also mentioned that it is getting adopted in some jurisdictions and growing number of implementations and certifications

5.   Issue #682 Clarify allowed use of state and required CSRF protection in FAPI 2.0 SP (Daniel)

  • PKCE provides CSRF protections and technically don’t need state any longer since it works in similar ways
  • Code verifier checked by AS so it is more reliable
  • A very creative way of shooting ones foot was found: using state to carry the PKCE info instead of cookie.
  • Attacker can inject authorization response into the client and the client would use state to figure out which code verifier to use, thus loosing protection
  • Security BCP prohibits it. FAPI 2 should do so as well.
  • FAPI non-nomatively states that PKCE can be used instead of state but lacks statement that code challenge/verifier must be securely bound to the session
  • Security Analysis assumed code challenge/verifier was bound to the session
  • Text is to be created.
    • Proposed “The PKCE challenge shall be transaction-specific and securely bound to the client and the user agent in which the transaction was started.”
    • From BCP 2.1.1
    • Proposed changing “transaction” to “flow”
    • “Transaction” needs to be defined if used
  • How would it be tested?
    • A basic test to catch it can be built by sending different state from the AS.
  • Regarding binding state : see https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.7.1 second bullet point
  • Common problem is that state is not bound to the session and clients just trust the state returned from AS
  • Assigned to Dave.

6.   PRs & Issues (Dave)

6.1.   PR 474 - Fixing #638 - Add some more text to the Introduction

  • PR #474 - https://bitbucket.org/openid/fapi/pull-requests/474
  • Made both introduction clauses consistent per Dima’s comment
  • The attacker model applies only to this document and not the entire set of the FAPI, so it should state this by first introducing the document set and then stating that the attacker model applies to this document.
  • Various grammar errors to be fixed.
  • Nat will update

6.2.   PR 475 First draft for MTLS ecosystems

  • PR #475 - https://bitbucket.org/openid/fapi/pull-requests/475
  • Allows AS to advertise more endpoints in the mtls_aliases parameter (.e.g. PAR)
  • Clarified that clients are required to use new discovery metada
  • Dima will remind Ralph and Mark to review
  • 5.5 may need revision if PR is merged
  • Intent/purpose of PR is not clear
  • New metadata is not clear that client must use mtls always and does not specify the metadata parameters
  • Context needs to be clear
  • MTLS controls may be at the transport layer and is out of client’s control
  • Need a way to inform client to use MTLS for endpoints that normally would not use MTLS
  • IANA registration text should be descriptive only and should not contain normative text and just refer back to the document
  • mtls_aliases original intent was to support same endpoint for different contexts
  • Dima will update

7.   AOB (Nat)

n/a

The meeting adjourned at 15:04.

Updated