-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2024 06 26_Atlantic
- Date & Time: 2024-06-26 14:00 UTC
- Location: https://zoom.us/j/97456084642?pwd=bTRFVzk4ZmlRK1M3bEprRlN5c3JFZz09
Agenda
The meeting was called to order at 14:05 UTC.
- 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:
- Adopted as is.
Monday, October 28 at Cisco Details to follow
Monday and Friday of the IIW week.
July 20 - 26.
Planning for 2025 events and update of OIDF calendar
Send 2025 events information to mike.leszcz@oidf.org
OIDF calendar on website is current: https://openid.net/calendar/
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
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.
Mike and Joseph had call with CMFand addressed questions regarding FAPI 1 vs FAPI 2
They requested the timeline for FAPI 2 final
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.
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
N/A
- No other business raised
The meeting adjourned at 15:01.