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

Wiki

Clone wiki

fapi / FAPI_Meeting_Notes_2023-07_12_Atlantic

View History

FAPI WG Agenda & Meeting Notes (2023-07-12)

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

1.   Roll Call (Nat)

  • Attendees: Nat Sakimura, Gail Hodges, Joseph Heenan, Dave Tonge, Kosuke Koiwai, Lukasz Jaromin, Peter Stanley, Victor, Craig Borysowich, Chris Michael, Chris Wood, Dima Postnikov, Bjorn Hjelm
  • Regrets:

3.   Events (Nat)

3.1.   EIC Submission started

  • Early submission has started.

3.2.   OAuth Security Workshop

  • Certification team get together
  • Joseph got two talks accepted
    • High security and interoperability
    • OIDC4VC conformance testing

4.   Liaison/Ext Org (Gail)

4.1.   FDX

Still contemplating big pictures.

Preparing their certification program.

4.2.   Canada

Expect some recommendations by end of the summer

4.3.   Australia

  • Work package 2 is going on.
  • Work package 3 preparation is going on.

4.4.   Latam

  • Gavin Littlejohn is preparing an event.

4.5.   Certifications

4.5.1.   Saudi Arabia

  • Certification launch on functional tests.

4.5.2.   Brazil

  • CIBA: ID Token as the hint for six months.

4.5.3.   ConnectID

  • FAPI 2 certification

4.5.4.   OIDF-Japan

Starting WG on education of newcomers and related.

Will have meeting tomorrow

Preparation is proceeding for OpenID Summit in Tokyo Jan 19, 2024

5.   Drafts Updates

5.2.   FAPI 2.0 Roadmap

  • We have under ten issues, and we should be able to sort them out over the summer.
  • We need to do a close read in parallel.
  • Implementer's feedback is also sought.
  • Incorporating those, we could do the WG last call in September, sort the issues out, and hopefully be able to advise the foundation to start the public review in October. Since the public review is 60 days, this means we are targeting the end of the year for the final.
  • FAPI 2 has about 5 outstanding issues of concern
  • Some partners are waiting for FAPI2 final before making a decision.
  • Some public expectation for FAPI2 final would be helpful
  • There is a 60 day review period for final
  • Should target the end of the year, but the implementers draft was passed not that long ago and more feedback/review would be better, especially for the attacker model.
  • Can fix the remaining issues by the end of the summer and aim for final before Christmas
  • Need text to update charter and website

6.   PRs (Nat)

  • PR #417 - ciba refactor to support FAPI2
    • Need to make an update
  • PR #411 - attempt at clarifying request-response binding
    • Will be merged
  • PR # 421 - fixes #601 - Title 8.1 is redundant
    • Looks good
  • PR # 422 - fixes #613 - FAPI1A - Remove 5.2.4 and 5.2.5
    • Looks good
  • PR # 423 - fixes #468 - Normative references to drafts in FAPI 1.0 Advanced
    • Looks good
  • PR # 424 - addresses #405 - Inconsistent usage of http and https in references - for FAPI1 specs
    • Looks good
  • PR # 425 - fixes #409 - MTLS References should be updated
    • Looks good
  • PR # 426 - fixes #600 - Errata to remove "Financial-grade" references from FAPI1
    • Looks good
  • PR # 427 - fixes #494 - FAPI1Adv: Apparent inconsistency in RP requirements
    • Looks good
  • PR # 428 - fixes #428 - Baseline: Clause 7.4.1 Talks about security issues with authorization requests and responses but incorrectly refers to encrypting authorization 'responses' not requests.
    • Probably need an update
    • Needs better wording

7.   Issues (Nat)

Dealt with the following issues

  • #428 - Baseline: Clause 7.4.1 Talks about security issues with authorization requests and responses but incorrectly refers to encrypting authorization 'responses' not requests.
    • 1st sentence is regarding request and 2nd sentence is regarding response.
    • There is some confusion that encrypting ID token solves authorization response leakage
    • ID token is not the full response, so the response itself could leak information
    • Encrypting ID token does not solve replay attacks
    • If talking about PII leakage, then we only need to talk about ID Token encryption. PII leakage is privacy consideration so maybe it doesn’t apply in security consideration section
    • Could also affect token/resource request/response
    • ID Token information leakage can be mitigated by encrypting the ID Token.
    • If the entire authorization response is concerned, then encrypt entire response via JARM
    • Change text :
      • The leakage of information from the ID token can be mitigated by encrypting the ID token. If the leakage of any other information in the authorization response is of concern then consider using JARM with encryption
  • #603 - Require servers to allow for clock skew
    • Borrow some text from DPoP and allow skew of seconds to a minute.
    • There are conformance testing implications also.
    • Can fix by changing text to a few minutes.
    • Testing will require 10 - 20 seconds for realistic testing.
    • Mark’s proposal is for order of seconds but not more than 60 seconds.
    • Testing will require a minimum value also.
    • Defining a min and max value will increase interoperability.
    • This is a profile so we can define more stringent requirements.
    • Should not put normative requirements in the tests.
    • WG has agreed to a min of 10 seconds and max of 60 seconds clock skew

8.   AOB (Nat)

  • none

The meeting adjourned at 14:55.

Updated