Wiki
Clone wikifapi / FAPI_Meeting_Notes_2024-04-10_Atlantic
FAPI WG Agenda & Meeting Notes (2024-04-10)
- Date & Time: 2024-04-10 14:00 UTC
- Location: https://zoom.us/j/97456084642?pwd=bTRFVzk4ZmlRK1M3bEprRlN5c3JFZz09
Agenda
- 1. Roll Call (Dave)
- 2. Adoption of agenda (Dave)
- 3. Events (Mike L.)
- 4. External Orgs & Liaisons (Mike L.)
- 5. PRs (Dave)
- 6. Issues (Dave)
- 6.1. 685 - Use of TLS 1.2 Ciphers
- 6.2. 656 - Create terms and definition as well as the abbreviations for the attacker model document
- 6.3. 688 - Simplifying the usage of FAPI-CIBA and FAPI 2 profiles together
- 6.4. 633 - Implementations of FAPI2 Message Signing - Particularly HTTP Message Signatures
- 6.5. 686 - CIBA response parameters in PSD2 TPP use-cases
- 7. AOB (Nat)
The meeting was called to order at 14:05 UTC.
1. Roll Call (Dave)
- Attendees: Nat Sakimura, Kosuke Koiwai, Mike Leszcz, Takahiko Kawasaki, Brian Campbell, Marko Milich, Peter Stanley,Dima Postnikov, Daniel Fett, Joseph Heenan, Dave Tonge, Robert Gallagher, Kelly Burgin, Steiner Noem, Daniel Lindau, Filip Skokan
- Regrets:
2. Adoption of agenda (Dave)
- Default agenda Adopted.
3. Events (Mike L.)
3.1. OAuth Security Workshop
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.
3.2. 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/
Will send the link for virtual participation to all WG mail lists before end of this week.
3.3. 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:
Please register if you are planning to participate in-person so we can plan accordingly.
3.4. 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
Identiverse agenda has been announced on the website
3.5. EIC
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.
3.6. OIDF Calendar
OIDF calendar on website is current: https://openid.net/calendar/
4. External Orgs & Liaisons (Mike L.)
4.1. OF & OPIN Brasil
Continuing to process high volume of Brazil OF and OPIN recertifications requests
4.2. UAE
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
4.3. UIDAI
Unique Identification Authority of India interested in OIDF and FAPI standards
Gail, Mark, Joseph, Mike will have a call with them this Friday
4.4. Chile
Chile is considering using FAPI but there are differences in interpretation of law which mentions FAPI and OAuth 2. In process of coordinating call to clarify
4.5. Certification Program
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
5. PRs (Dave)
5.1. 475 - First draft for MTLS ecosystems
Need review for IANA registry - Justin
Will be merged after review
5.2. 483- reworking the text around length of the state parameter
Lack of normative language for state and nonce lengths causing interoperability issues
Nonce is limited to 64 characters
State length is problematic due to possibility of using JWT values
Add note “state parameter is not used for CSRF protection, but maybe used by the client for application state instead, in circumstances where clients encode application, state as JWTs, the length of the state parameter value could be in excess of a thousand character.”
Need to base conformance tests on spec requirements but it’s better than not mentioning at all WG to review
6. Issues (Dave)
6.1. 685 - Use of TLS 1.2 Ciphers
There is still concern about the text
Only use allowed ones in BCP195, but doesn’t restrict ciphers to ones listed in issue
Joseph will check certification suite conformance
Conformance suite is still not testing TLS 1.3.
AS supporting only TLS 1.3 should still pass tests, but clients need to support 1.2 due to limitations of test suite architecture
Need to add second host name to support TLS 1.3 when TLS mutual authentication is used
FAPI2 is not checking that clients only accept listed ciphers
Joseph will check certification suite conformance
6.2. 656 - Create terms and definition as well as the abbreviations for the attacker model document
Daniel suggested add sentence referencing the clause where attackers are defined
Nat will confirm
6.3. 688 - Simplifying the usage of FAPI-CIBA and FAPI 2 profiles together
Would like to put a new subsection for a CIBA as a supported flow and reference the CIBA spec for the AS and Client requirements
There are certification tests for FAPI1 CIBA which should work with FAPI2 but only using authorization code flow
There are limitations with decoupled flow that redirect flow does not have. Should they both be on the same level?
Cannot use redirect with multiple devices so CIBA is a legitimate flow that needs to be supported. Security issues will be discussed within the CIBA spec.
There is support to address this in CIBA/implementation advice rather than the security profile
6.4. 633 - Implementations of FAPI2 Message Signing - Particularly HTTP Message Signatures
Track Message signing implementations
Would like to test interoperability with Conformance suite
There are Cavaugh implementations but none have transitioned to the standard
Need some implementations to move Message Signing to final
AWS uses HTTP signatures but not with FAPI
Might take another 1+ years for Message Signing to final which includes signed request/responses
Some ecosystems prefer to adopt final specs
Either remove HTTP signatures from Message Signing or try and encourage more implementations
Would like to work out ambiguous parts of HTTP signatures spec
6.5. 686 - CIBA response parameters in PSD2 TPP use-cases
Would like the ability to pass a startup token to TPP application in same device flow
Should not encourage CIBA for same device flow but provide some guidance : look at security BCP and security issues
Using CIBA to do direct redirects from a client app that’s federated from the AS. Useful to standardize method.
Put it in implementation advice
Updated