Skip to content

FAPI_Meeting_Notes_2017 02 21

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

FAPI WG Meeting Notes (2017-02-21)

Date & Time: 2017-02-21 23:00 UTC
(15:00 PDT, 23:00 UK, 00:00 Denmark, 08:00+1 JST)

Location: GoToMeeting https://global.gotomeeting.com/join/321819862

The meeting was called to order at 15:10 UTC.

1.   Roll Call

  • Present: John, Nat, Sascha, Anoop, Edmund, Henrik
  • Regrets: Dave
  • Guest:

2.   Adoption of the Agenda (Nat)

  • Adopted

3.   Implementer's draft (Nat)

3.1.   Part 1: Read Only API Security Profile (Nat)

4.   Working Drafts

4.1.   Part 2: Read & Write API Security Profile (Nat & Edmund)

4.1.1.   What shall we token bind?

The WG group discussed what needs to be token bound. If the server and the client supports token binding, then it should token bind refresh token and access token.

Question: Shall we token bind code as well?

Nat asked John to provide an example of token binding messages, which are not in the token binding specs. John agreed.

4.1.2.   Would there be other options?

Yes. We will still have mutual TLS auth available. Token Binding may take longer time to get implemented. Sascha expressed that something that can be completely application layer is easier to implement. Nat expressed that he needs something that API GW vendors can support. Sascha agreed to look into the matter and report back on the token binding support and alternatives.

4.1.3.   Authentication Requirement

WG discussed what format shall be used to express the authentication requirement. John pointed out that iGov is coming up with vectors of trust expression. Nat pointed out that it would be best to align and asked John to make a presentation on iGov decision next week. John agreed.

4.1.4.   Always Request Object?

There can be two types of interactions with the user.

  • type 1: The client makes the "write" request (e.g., initiate payment) in the authorization request to get user authorization. This is a typical case in many of the payment schemes.
  • type 2: The client makes the "write" request to a specialized API so that the API can send the user notification and get authorization. This is something Modrna is working on.

In type 1 case, authorization request should be signature protected: i.e, has to be a request object, otherwise it may be tampered in browser.

In type 2 case, there is no authorization request involved but some other API calls (Editors note: which again may be needed to be signature protected for the recording purposes etc.)

Nat asked John to make the presentation on Modrna user questioning API next week. John agreed.

4.2.   Part 3: Open Data API

  • Skipped

4.3.   Part 4: Protected Data API and Schema - Read only (Sascha)

  • Skipped

4.4.   Part 5: Protected Data API and Schema - Read and Write

  • Skipped

5.   External Orgs

5.1.   FS-ISAC DDA (Anoop)

  • Still waiting for the meeting to get started.
  • OFX has OAuth enabled version.

5.2.   DK Banking Association(s) (Henrik)

  • No news.

5.3.   JP Banking Association (Nat)

  • (Off the record)

5.4.   Others

  • UK OBS (Dave)
  • FS-ISAC DDA (Anoop)
  • OFX (Anoop)
  • ISO/TC68
  • Figo

6.   AOB

6.1.   Next Call (Atlantic)

  • Next call is Atlantic shift and is in next week. Please consult the WG calendar for the date and time.

The meeting adjourned at 00:02 UTC.

Clone this wiki locally