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

Wiki

Clone wiki

fapi / FAPI_Meeting_Notes_2023-07_26_Atlantic

View History

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

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

1.   Roll Call (Nat)

  • Attendees: Peter, nat, Arnaud, Dima, Takahiko, Kosuke, Brian, Robert, Daniel, Lukasz, Joseph, Mark, Chris, Victor, Bjorn, Craig
  • Regrets:

4.   Liaison/Ext Org (Mike)

4.1.   Brazil

Open Finance Brazil looking into alternative flow for payments using FIDO authenticators, but without redirects.

FIDO authenticators need to be registered with accounting packages rather than banks/AS.

John Bradley gave them update on FIDO.

Discussing whether putting trust in accounting software to register a FIDO key trusted by banks is acceptable or not.

Open Finance confuse by recent changes to FIDO implementations in iOS/Android and other OSes

Previously, platform authenticators created keys that were bound to the device.

Now keys are bound to users by iCloud, Google, etc.

Keys can even be managed by third party authenticators, like One Password, LastPass

Another meeting is scheduled

If solutions solves some real world problems and other ecosystems have such problems, FAPI WG should standardize it rather than Brazil doing it themselves.

Trying to determine whether using a third party to link credentials and users provides enough certainty

Chris suggested using redirect to setup initial trust and then delegate to the device afterwards but there is no way to do it with FIDO currently

FIDO is preferred over CIBA for this use case

Authentication is no just a single factor, usually involves

  • Device binding
  • Behavioral metrics
  • Fraud
  • Risk assessment
  • Etc.

Third parties would not be able to replicate them, so can’t be delegated to RPs or TPPs

Using long lived consent with step up for high risk transactions make more sense

Need to find out uses cases details and goals to customize solution

Single solution might not work for all use cases

More and stronger signals, gives banks flexibility in deciding to step up authentication

Biggest risk is Push payments to fraudulent accounts. This is more of a KYC on recipient account problem.

Need to set up a meeting with knowledgeable people regarding use case and details

Preliminary details involves scheduling payments from account software packages

Using Variable Recurring Payments might suit this use case.

Can also use batch/bulk payments along with redirects to provide better assurance

Will try to setup call with to better to understand use case and explore solutions

4.2.   SAMA

Major version update of the standard will be published by the end of October

Will include Payments initiation, API specs

5.   PRs (Nat)

  • PR #430 - fixes #458 - FAPI1 Part1: not clear as to which auth flows are supported
    • FAPI1 not clear on which flows are supported
    • Requires the response_type values code, code id_token, code token, or code id_token token
    • There is conformance test for Advanced profile to make sure “code” response_type fails
    • Part 2 is more restrictive
    • There is some interactions with JARM
  • PR #429 - fixes #527 - Create security note/consideration on B. Access Token Injection with ID Token Replay (FAPI 1.0 Advanced)
    • Reads like there is a requirement for ID Token to include access token hash, but there is not such requirement
    • Changing from “is mitigated” to “can be mitigated” might be better
    • 8.3.5 mentions misconfigured token endpoints also, so it might be covered already.
    • 8.3.5 is about phishing for access tokens and 8.3.6 is on how to replay access tokens.
    • Access tokens may be leaked by logs files which is not phishing
    • Both sections mention access tokens and injection with ID Token replay
    • Added text 8.3.6 does not seem to be necessary
    • Generally rely on server metadata to avoid misconfigured endpoint attacks.
    • Discussed a year ago to check if all attacks are covered and concluded that they were all covered, but it was about FAPI2 and now we’re retrofitting it back to FAPI1
    • There is no new requirement only just informing/clarifying of mitigations or informing that there are such risks remaining
    • Added the comment that generally we rely on several metadata that avoid this kind of misconfigured endpoint attacks.
    • Need to double check other attacks and continue discussion
  • PR #411 - attempt at clarifying request-response binding
    • Not ready

6.   Issues (Nat)

  • #618 - Certification/conformance: Strictness of checking error responses
    • PAR getting more usage with FAPI in conformance tests and the certification team is getting pushback about strictness of HTTP 400 or 401 error codes when using misconfigured clients.
    • Asking for WG input on whether relaxing these error codes and put in a warning instead of a failure or stick with normative text.
    • There may be differences whether it’s a product or ecosystem.
    • Products should follow specs to interoperate but ecosystems may not be able to support all such situations. * * But the conformance suite will not differentiate to maintain value and differentiating is difficult..
    • Misconfigured clients usually happen during setup time and should not happen in production
    • WG may have some leeway on whether certain situations can be relaxed
    • Relaxing stringent error codes is OK for things that may not have much interoperability/security value but exceptions can get out of control
    • May depend on mission of OIDF, whether to is solely security and interoperability or also driving adoption through frictionless user experience
    • In this case, 401 is returned instead of 400, but client can only stop at this point
    • Joseph will put text proposal

Will discuss #617 - Security issue in the JWT Response for OAuth Token Introspection specification next call

7.   AOB (Nat)

The meeting adjourned at 14:55.

Updated