Wiki

Clone wiki

fapi / FAPI_Meeting_Notes_2024-04-10_Atlantic

FAPI WG Agenda & Meeting Notes (2024-04-10)

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:

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.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

PR #475

Need review for IANA registry - Justin

Will be merged after review

5.2.   483- reworking the text around length of the state parameter

PR #483

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

#685

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

#656

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

#688

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

#633

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

#686

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

7.   AOB (Nat)

n/a

The meeting adjourned at 15:04.

Updated