-
Notifications
You must be signed in to change notification settings - Fork 0
FAPI_Meeting_Notes_2024 04 03_Atlantic
- Date & Time: 2024-04-03 14:00 UTC
- Location: https://zoom.us/j/97456084642?pwd=bTRFVzk4ZmlRK1M3bEprRlN5c3JFZz09
Agenda
The meeting was called to order at 14:05 UTC.
- Attendees: George Fletcher, Nat Sakimura, Kosuke Koiwai, Mike Leszcz, Takahiko Kawasaki, Brian Campbell, Marko Milich, Peter Stanley, Jacob Ideskog, Dima Postnikov, Daniel Fett, Joseph Heenan, Dave Tonge, Robert Gallagher, Bjorn Hjelm, Mark Andrus
- Regrets:
- Default agenda Adopted.
Rome April 10-12
All details here: https://oauth.secworkshop.events/osw2024
The certification team is meeting on Monday and Tuesday.
Tuesday meeting will discuss certification with Federation editors for the federation spec.
May also discuss ConnectID with Dima.
on Monday, April 15th in Sunnyvale – registration now open and required: https://openid.net/registration-oidf-workshop-monday-april-15-2024/
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:
Please register if you are planning to participate in-person so we can plan accordingly.
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
Identiverse agenda has been announced on the website
Berlin, bcc Berlin Congress Center
June 4 - 7, 2024
https://www.kuppingercole.com/events/eic2024
OIDF will host a brief workshop on Tuesday morning prior to EIC.
Agenda to be finalized.
OIDF calendar on website is current: https://openid.net/calendar/
Thurs (4/18) after IIW ends. I haven’t found an explicit signup page as yet.
Will focus on authorization.
Contact George for details/signup.
Continuing to process high volume of Brazil OF and OPIN recertifications requests
Received initial specs for security and authorization standards
Joseph and Mike will discuss
Will connect with Radiam and Ozone teams after reviewing them
Will provide update on April 15 board meeting at Google
Unique Identification Authority of India interested in OIDF and FAPI standards
In process of coordinating call
The Large Scale Pilot Potential will have an event April 3, 2024 1500 CET brief on the interop event, which OIDF DCP WG/ Cert team are supporting for OID4vp / OID4VCI
Still accepting participants but will need Excel form
Details available at https://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/Week-of-Mon-20240325/000231.html
Certification team is looking for a Java developer to join team
https://openid.net/certification-program-recruiting-java-developer/
Interested parties should contact Mike or Joseph
https://bitbucket.org/openid/fapi/pull-requests/481
To be merged.
https://bitbucket.org/openid/fapi/pull-requests/482
To be merged.
https://bitbucket.org/openid/fapi/pull-requests/479
To be merged.
https://bitbucket.org/openid/fapi/pull-requests/477
To be merged.
5.5. 474 - Fixing #626 - Add some more text to Introduction
https://bitbucket.org/openid/fapi/pull-requests/474
Need more approval.
Dima will review.
https://bitbucket.org/openid/fapi/pull-requests/475
Dima reviewed feedback
Ralph asked if whether we need to standardized error messages but this can be addressed separately
Need review for IANA registry - Justin
Need some editorial changes
Some ecosystems use CIBA to implement proprietary authorization APIs mainly in Nordics/Sweden
There is a new parameter required to initiate the CIBA flow. The authorization server needs to pass an parameter to the client application.
Some banks are already using non-standardized ways to pass the parameter
Need a standard way to pass the value to the client if possible
CIBA is not intended for same device flow
Sweden banks only allow fully decoupled flow when on the phone with the service provider
Should this method be reviewed by Security Analysis? It would take great effort to prove.
Need to propose a concrete attack to them.
CIBA is final but this can be put into FAPI-CIBA with note regarding to use core FAPI when on same device or redirect flow.
CIBA allows other parameters to be sent to the AS but AS does not send anything back to the client due to out of band assumption
Is there benefit to standardizing a method to send parameters back to the client?
Should center discussion around coupling vs decoupling and note that CIBA is not for coupling flow
Maybe put guidance in Deployment Advice regarding app2app flows
Main reason for using CIBA is to avoid redirecting users from app to app
Bank apps never use redirect flow and CIBA is used in decoupled flow
Main objective is to avoid bad UX caused by redirects
Find a redirect flow that would work better in this case
More discussion needed
Remove normative text regarding state length
Add note that state is not used for CSRF but may be used by clients for application state. State may be JWTs which may be large.
AS should handle large state values (at least 512) and not reject them without good reason.
A use cases for JWT state - can be used by network edge components to direct request traffic
Not specifying length makes conformance testing difficult
There is pushback regarding testing of long state values
Different ecosystems may have different length requirements, perhaps allow some customization of length?
n/a
The meeting adjourned at 15:04.