Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-8388

Financial-grade API (FAPI) compliance

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 2.11.2 GA
    • Gateway
    • Financial-grade API (FAPI) compliance
    • False
    • None
    • False
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • 60% To Do, 0% In Progress, 40% Done
    • RHOAM Sprint 56, RHOAM Sprint 57, RHOAM Sprint 58, RHOAM Sprint 59, RHOAM Sprint 60, RHOAM Sprint 61, RHOAM Sprint 62, RHOAM Sprint 63, RHOAM Sprint 64, RHOAM Sprint 65

      Please consider making 3scale FAPI compliant.
      The requirements are 6.2.1 of FAPI Security Profile 1.0 - Part 1: Baseline and 6.2.1 of FAPI Security Profile 1.0 - Part 2: Advanced.

      Developer notes

      FAPI (Financial-grade API) is a standard defined within the OpenID foundation. It's aimed at standardising financial APIs that want to be under the umberella of Open Banking and therefore fits within that initiative and the regulations such as PSD2 that set out the specification. Supporting this standard seems to be going in the same direction we have targeted with our OpenID Connect & OAuth 2.0 support and looks like a beneficial addition to the product.

      FAPI part 1 support (Baseline security profile)

      APIcast acts as the Resource server and it should accept an OAuth 2.0 Bearer token via HTTP header only and authenticate/authorize the confidential client via JWT verification (expiration, scope, identity & revoaction status) as detailed in the specification
      It should support the HTTP header x-fapi-interaction-id and if this doesn't exist then add the header to the request AND response with a randomly generated uuid
      All traffic MUST be over TLS
      TLS 1.2 is the minimum accepted version and a server certificate check should be performed

      FAPI part 2 support (Advanced security profile)

      OAuth 2.0 Bearer tokens must be verified via MTLS (OAuth 2.0 MTLS policy?)
      When TLS <1.3 is used a restricted list of cipher suites only are permitted as described
      PS256 & ES256 algorithms are the only supported options. (this might be irrelevant given part 1 support states the token should be checked for revocation status)

       

      /// mostly documentation, possibly extend header modification policy to support the HTTP header x-fapi-interaction-id and if this doesn't exist then add the header to the request AND response with a randomly generated uuid

              Unassigned Unassigned
              rhn-support-tkonishi Takayuki Konishi
              An Tran An Tran
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated: