Skip to content

FAPI_Meeting_Notes_2023 09 06_Atlantic

Nat Sakimura edited this page Jul 10, 2026 · 1 revision

FAPI WG Agenda & Meeting Notes (2023-09-06)

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

  • Attendees: Nat, Joseph, George, Aaron, Bjorn, Brian, Craig, Daniel, Dave, Dima, Justin, Kosuke, Mark
  • Regrets:
  • Adopted as is.

OIDF planning workshop prior to IIW on Oct 9 at Cisco in Mountain View, California. Need to register 1 week before the workshop.

Link: https://openid.net/registration-workshop-october-9-2023/

  • Coming up with FAPI CIBA Profile.

TAB recordings are available if you sign up to their discord.

  • #596 Make clear that requests and responses to resource servers don't have to be bound
    • Make it clear to only sign the request signature and request signature input if applicable (i.e. if present) also add to the note to explain further
    • Created #613 in relation to this issue.
  • #610 Review FAPI1 security considerations for clarity
    • Make sure that not all security considerations need to be implemented.
  • #495 Certification: Requirements for alg support in RPs/OPs
    • concluded not to make the jws algorithm part of the profile matrix at all, same as it wasn’t part of the matrix in FAPI1.
    • This is more for vendor product certification - if folks have ideas, it will be welcome but this ticket is being closed.
  • #607 Authentication property of FAPI 2.0
    • Daniel suggests that it would be a functional property.
    • It might be good to point it out in the implementation guidance.
    • Nat to come back to it after refreshing memory.
  • #605 Security issue in the JWT Response for OAuth Token Introspection specification
    • No discussion
  • #606 Certification/conformance: Strictness of checking error responses
    • 40x response checking in particular from PAR endpoint.
    • A screenshot in the certification request would suffice.
    • To be closed.
  • #590 "Client" is misleading in the context of signed introspection responses
  • #457 Create JSON Schema for Grant Management Specification
    • Grant management did not get adopted by AU so it has no time pressure.
    • To be kept in our backlog.
  • #591 Require servers to allow for clock skew
    • At least 10 sec, but not more that 60 sec.
    • George: How does a client know it failed due to clock skew? Being specific may limit the applicability.
    • Joseph: Lower bound was introduced to testable.
    • George: Would it not be better to make it a conformance testing requirement and not normative?
    • Joseph: That would confuse people.
    • George: Depending on the risk environment and functional protocols, we may want to further lockdown or relax.
    • Joseph: Lowerbound as "shall" and upperbound as "should"?
    • George: With a security consideration, pointing out the possibility of changing the bounds, OK.
    • Brian: For time-syncing, we can use nonce in DPOP.
  • n/a

The meeting adjourned at 15:00.

Clone this wiki locally