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

Financial-grade API (FAPI) compliance

    XMLWordPrintable

Details

    • Epic
    • Resolution: Unresolved
    • 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
    • 66
    • 66% 66%
    • RHOAM Sprint 56, RHOAM Sprint 57

    Description

      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

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated: