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

Wiki

Clone wiki

fapi / FAPI_Meeting_Notes_2024-06-26_Atlantic

View History

FAPI WG Agenda & Meeting Notes (2024-06-26)

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

1.   Roll Call (Nat)

  • Attendees: Robert Gallagher, Nat Sakimura, Mike Leszcz, Peter Wallach, Mark Andrus, Justin Richer, Filip Skokan, Peter Stanley (OBL), Chris Wood, Dave Tonge, Lukas Jaromin, Hideki Ikeda, Joseph Heenan, Dima Postnikov
  • Regrets:

3.   Events (Mike L.)

3.1.   OIDF Workshop

Monday, October 28 at Cisco Details to follow

3.2.   Working Group Meetings

Monday and Friday of the IIW week.

3.3.   IETF

July 20 - 26.

3.4.   2025 Events

Planning for 2025 events and update of OIDF calendar

Send 2025 events information to mike.leszcz@oidf.org

3.5.   OIDF calendar

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

4.   External Orgs & Liaisons (Mike L.)

4.1.   US

Published open letter to CFPB

Gail met with member of CFPB team yesterday

CFPB is welcoming pre-filing meetings with a potential standard setting organization.

Gail is working to setup meeting and coordinating follow-up with Linda Jeng

4.2.   Canada

Joseph, Gail, and Mike has call with Open Banking Canada team ad director of financial services innovation team.

They have read OIDF’s CFPB letter and have requested a similar letter providing guidance, which OIDF has agreed to draft along with recommendations, rationale, and risks.

Will review draft in 2 weeks and publish publicly after edits.

4.3.   Chile

Mike and Joseph had call with CMFand addressed questions regarding FAPI 1 vs FAPI 2

They requested the timeline for FAPI 2 final

5.   FAPI 2.0 Timeline Discussion

Working group last call has started

Some issues, mainly editorial and clarifications have been found

We are still hopeful that we can close all the issues and move on during the summer (northern hemisphere).

2-6 weeks ETA fo finish open FAPI 2 issues before review and voting.

6.   PRs (Dave)

6.1.   505 - RT rotation alternative wording

PR #505

Clarifies that refresh tokens shall not be used except for extraordinary circumstances and that previous refresh tokens shall have a limited retry window.

Adds notes explaining that there are no security benefits for refresh tokens when using sender constrained access tokens.

Joseph disagreed with putting “time limited retry” into the text.

The AS should be responsible to make sure that clients don’t lose consent.

The spec should not dictate implementation details.

Current note regarding refresh token rotation was added to discourage usage due to lack of security benefits and operational issues.

WG agrees that refresh token rotation shall not be used

Details of rotation can be moved into the guidance document.

But if spec does not specify details of rotation, then there can be interoperability issues for ecosystems due to differences in how rotation is implemented.

Make recommendations to ecosystems to make sure that rotation is transparent and implemented in a consistent way.

Another option is to make it clear that rotation is not fully specified and that if ecosystems allow it’s usage, it will result in significant interoperability issues.

Testing for allowing usage in extraordinary situations is not possible.

Spec can be profiled to allow refresh token rotation by ecosystems and interoperability considerations can be mentioned there. Recommend them to keep it transparent and consistent for AS and clients.

Conformance suite requires RPs to support refresh token rotation due to client requirement

Conformance tests will test AS refresh token rotation by retrying with previous refresh token to make sure it’s success.

It doesn't not test whether the old refresh token is revoked after getting a new access token.

The tests are not implemented in a prescriptive way so that can lead to real world interoperability issues

The issue is really about how refresh token rotation is implemented. If ill-defined and leaving to implementers will lead to fragmentation in interoperability problems.

Profiles of specs can further constrain the base spec but cannot relax conditions in the base spec.

Test should have a corresponding location in the spec.

Need to describe how refresh token rotation will work without prescribing the implementation details.

2 options

  • Be prescriptive and normative
  • Revoke old refresh token after first usage of new refresh token/ access token

Leave to guidance or other documents

Nat suggested to revoke old refresh token only after the new refresh token is used

There can be different relationships between refresh token and access tokens.

Can be 1-1 or 1-many.

If the new refresh token is never used, the old refresh token will forever be valid. N+1 option.

Discussion to be continued on the mailing list and a possible WG vote.

Possible votes:

  • Shall support refresh token rotation
  • Should support refresh token rotation
  • Shall WG describe how refresh token rotation works
  • Shall implementation specify how rotation works
  • Should not support refresh token rotation for reasons including interoperability, but if supported, it is up to the ecosystems/implementations to specify how

Add options to the issue for further discussion

8.   AOB

  • No other business raised

The meeting adjourned at 15:01.

Updated