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

Wiki

Clone wiki

fapi / FAPI_Meeting_Notes_2024-03-20_Atlantic

View History

FAPI WG Agenda & Meeting Notes (2024-03-20)

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

1.   Roll Call (Dave)

  • Attendees: Joseph Heenan, Nat Sakimura, Daniel Fett, Dima Postnikov, Kosuke Koiwai, Dave Tonge, Bjorn Hjelm
  • Regrets:

3.   Events (Mike L.)

3.2.   OAuth Security Workshop

Rome April 10-12 – final call for speakers is open until March 10th.

All details here: https://oauth.secworkshop.events/osw2024

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

3.4.   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.5.   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 website

3.6.   OIDC Calendar

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

4.   External Orgs & Liaisons (Mike L.)

4.1.   Chile

  • Coordinating the call with regulators
  • Had a call with a bank with Mark Haine. They are still wondering whether to go to 2.0.
  • May go live in 2025

4.3.   Brazil

OFBR + OPIN – continue to process FAPI re-certification requests.

4.4.   Certification Team

The certification team has posted a Java developer opportunity and is actively recruiting:

https://openid.net/certification-program-recruiting-java-developer/

4.5.   UAE - (United Emirates)

  • The first draft should come out tomorrow. FAPI2 w/private key JWT client authentication, MTLS sender constrained access tokens, RAR, signed request objects

4.6.   ISO/IEC JTC 1/SC 27/WG 5

  • Liaison statement is to be sent.
  • Info about FAPI 2 that it is close to final. Send the drafts.
  • Also mentioned that it is getting adopted in some jurisdictions and growing number of implementations and certifications

5.   PRs (Dave)

5.1.   475 - First draft for MTLS ecosystems

PR #475

Dima updated but Ralph request other updates

Will coordinate meeting with Ralph, Brian, Mark from DSP in Brisbane

5.3.   474 - Fixing #638 - Add some more text to Introduction

PR #474

Awaiting PR

5.4.   479 - change this specification to this document - for ISO

PR #479

Editorial text change from “specification” to “document”

May conflict with OIDF IPR notice text

IPR text to remain unchanged

5.5.   478 - make security considerations top level

PR #478

Changes will affect clause numbering

Note regarding refresh token rotation refers to clause 10, should be 5.3.2.1-10

5.6.   476 - add wording for state and nonce

PR #476

Explicit support for state values up to 512 and nonce values up to 64

Will merge

5.7.   477 - improve wording to remove shall be

PR #477

Looks fine

Need to fix typo

Joseph questioned whether we need “shall only” for serving JWK since supporting both HTTP and HTTPS is still compliant

Change to “shall only serve the jwks_uri over TLS”

6.   Issues (Dave)

6.1.   684 - typ in request objects

#684

Conformance suite does not validate typ values

Some Brazil banks rejected objects with typ values

Specs are not clear, only JAR mentions it but there is no normative text

Proposed putting some validation for typ values in OP and RP tests

Proposes testing for JWT, oauth-authz-req+jwt, and absent value

Brian suggested to drop JWT value since it’s meaningless. Should not disallow it but also not encourage its usage.

There are various uses for JWTS but typ value may help mitigate type confusion according to BCP

Makes sense to be as strict as possible

JAR recommends requiring explicit typ values for new OAuth deployment profiles where compatibility is not a consideration

Will affect Message Signing, PAR with JAR

WG agrees to make requirement for clients to use “oauth-authz-req+jwt” and AS to reject if not present

Need resolution for FAPI1 conformance tests

=> Check OP accepts recommended value and RP not sending unacceptable values for interoperability, AS should also accept “JWT”

Will discuss further

6.2.   683 - minimum length for EC keys?

#683

FAPI2 SP requires 160 minimum bits but ES256 and EdDSA (Ed25519) uses 256

FAPI1 requires 160 minimum

Text seems to be about key length for JWTS instead of TLS

TLS BCP requires 224

Suggested requiring 3072 for RSA and 256 for EC

Conformance suite does not test TLS keys size

Agree to require 224 for EC

Need more input regarding move to 3072/256

6.3.   642 - Continuation of #619 -- Add some text to make the readers aware of the caveats.

#642

Addressed in Attacker Model

Nat will confirm

7.   AOB (Nat)

n/a

The meeting adjourned at 15:04.

Updated