Habilitar la especificación de la banca abierta en el Reino Unido

Una guía técnica de soluciones de ForgeRock

El negocio de la banca está experimentando un cambio importante, ya que los usuarios exigen un mayor acceso a la cuenta y el intercambio de información de la cuenta. Para proteger a los consumidores, se ha redactado una normativa que ordena cómo se pueden crear, acceder y compartir los datos financieros.

En este documento, analizamos a nivel técnico cómo ForgeRock permite la Especificación de banca abierta del Reino Unido a través de ForgeRock Identity Platform™ y la facilitación tanto del banco de referencia como de la nueva área de prueba del directorio de ForgeRock. Este documento se centra principalmente en el perfil de seguridad y en el ForgeRock Open Banking Directory.

A lo largo de este documento hemos proporcionado enlaces a la documentación de ForgeRock para obtener más información sobre la funcionalidad de la banca abierta de la que se está hablando.

Tres requisitos clave para la banca abierta

La banca abierta se trata de que los usuarios compartan sus datos bancarios a través de API. Por supuesto, cuanto más acceso de terceros, mayor será el riesgo.

Hay tres requisitos clave que se aplican para proteger cualquier arquitectura de ecosistema de banca abierta.

  1. Consentimiento: los bancos necesitan una manera de confirmar que un usuario ha otorgado su consentimiento para que se compartan datos, lo que al mismo tiempo significa que necesitan una forma de:

    1. Permita a los usuarios autorizar a un tercero a acceder a sus datos.

    2. Autenticar que el tercero es quien dice ser.

  2. Incorporación: los bancos necesitan una forma de incorporar y verificar que los terceros confíen en los datos personales de la cuenta.

  3. Acceso: los terceros necesitan una forma de acceder a los datos de la cuenta de usuario, y los bancos necesitan una manera de proteger esos datos y hacer cumplir que solo se acceda a ellos con nuestro consentimiento.

En esencia, estos requisitos son un medio para establecer tanto el consentimiento como la confianza. Todos deben cumplirse para que cualquier ecosistema de banca abierta (o API abierta) tenga éxito. Comprender el ecosistema de la banca abierta puede ser complejo. Los dos diagramas a continuación ofrecen una visión de alto nivel de cómo funciona el ecosistema general de la banca abierta del Reino Unido y las interacciones clave entre todos los participantes.

Diagrama 1: Ecosistema de banca abierta del Reino Unido
Diagrama 1: Ecosistema de banca abierta del Reino Unido
Diagrama 2: Establecer consentimiento y confianza en la banca abierta del Reino Unido
Diagrama 2: Establecer consentimiento y confianza en la banca abierta del Reino Unido

 Dentro del ecosistema de banca abierta del Reino Unido, ForgeRock potencia dos componentes con lo siguiente:

  • ForgeRock Model Bank: un banco modelo totalmente compatible que proporciona una aplicación de banco de referencia, utilizada por bancos líderes y terceros para construir sus propias aplicaciones de acuerdo con los estándares de banca abierta. (Ver anuncio aquí).

  • ForgeRock Open Banking Directory: una nueva versión totalmente compatible del UK Open Banking Directory que sustenta el área de pruebas e integración. A diferencia del directorio dinámico de banca abierta, el ForgeRock Open Banking Directory no requiere que los participantes estén aprobados por la FCA, lo que reduce una importante barrera de entrada.

Compatibilidad con los tres requisitos y las especificaciones de banca abierta del Reino Unido

El Reino Unido ha publicado las Especificaciones de lectura/escritura de banca abierta. Las especificaciones definen los siguientes componentes importantes que son integrales para el consentimiento, la incorporación y el acceso:

  • API de cuenta y transacción: los puntos finales, las solicitudes y las respuestas para solicitudes de cuenta.

  • API de inicio de pagos: las solicitudes de punto final y las respuestas para las solicitudes de pago.

  • Perfil de seguridad: los estándares de seguridad que sustentan las API.

  • Open Banking Directory: el marco de confianza para los participantes en el ecosistema de banca abierta.

Las especificaciones son extremadamente detalladas y es muy recomendable que las use para ayudarle a comprender cómo funciona la banca abierta del Reino Unido.

Sin embargo, la intención de este documento es destacar lo que en ForgeRock creemos que son los elementos clave de las especificaciones y explicar cómo estos y ForgeRock responden a los tres requisitos mencionados anteriormente.

De nuevo, nos enfocamos principalmente en el Perfil de seguridad y en el Open Banking Directory en este documento. El consentimiento es el primer requisito clave que cubriremos, ya que la incorporación es un resultado directo de cómo se recopila y aplica el consentimiento.

El consentimiento es un concepto complejo. Solicitar, capturar y hacer valer que el propietario de los datos de la cuenta bancaria ha dado permiso al banco para compartir esos datos son mecanismos fundamentales. Estos mecanismos dependen de la autorización y autenticación.

Autorización

OAuth

OAuth 2.0 es el principal estándar de seguridad para la autorización delegada y la banca abierta del Reino Unido ha determinado que es la solución adecuada para la banca abierta. OAuth resuelve el problema de permitir que un usuario autorice que un tercero actúe en su nombre.

OAuth se usa comúnmente para permitir que los sitios web compartan datos entre sí, como permitir que Twitter publique en Facebook. En lugar de compartir nombres de usuario y contraseñas, se emite un token de acceso OAuth que el tercero puede presentar para acceder a los datos de un usuario.

OAuth define cuatro roles clave:

  • Propietario del recurso: el actor que posee el recurso al que se accede

  • Servidor de recursos: el servidor que protege el recurso

  • Cliente: la aplicación que quiere acceder al recurso

  • Servidor de autorización: el servidor que emite tokens de acceso al cliente

Tenga en cuenta que el cliente debe estar registrado con el servidor de autorización antes de iniciar el flujo; cubriremos esto más adelante en la incorporación.

Diagrama 3: Flujo de código de autorización de OAuth
Diagrama 3: Flujo de código de autorización de OAuth

OAuth utiliza alcances para modelar los permisos solicitados por el servidor de recursos, el token de acceso emitido se vincula a estos alcances.

Los alcances son relativamente aproximados. Los ejemplos típicos de alcances podrían ser: perfil, imagen, publicación. No son detallados y, por lo general, un conjunto de alcances está preconfigurado en el servidor de autorización.

OAuth es solo un marco y la banca abierta no define muchos aspectos de cómo debería de implementarse OAuth de forma segura. Además, el uso de alcances de OAuth presenta un problema para la banca abierta.

Diagrama 4: Uso de alcances
Diagrama 4: Uso de alcances

Como se desprende de lo anterior, debido a que los alcances tienen que estar preconfigurados, no es apropiado modelar los pagos utilizándolos. Abordaremos esto con OpenID Connect.

OAuth: https://tools.ietf.org/html/rfc6749

ForgeRock Docs: https://backstage.forgerock.com/docs/am/6/oauth2-guide/index.html

OpenID Connect

OpenID Connect (OIDC) es un estándar construido sobre OAuth para la autenticación delegada. En OIDC, hay tres roles clave:

  • Parte que confía: la parte que está delegando la autenticación a un proveedor de OpenID

  • Proveedor de OpenID: la parte responsable para la autenticación del usuario final

  • Usuario final: el propio usuario

OpenID Connect permite que una parte que confía se dirija a un proveedor de identidad para autenticar usuarios, como iniciar sesión con Facebook. La parte que confía no tiene que preocuparse por la administración de los nombres de usuario y las contraseñas, sino que confía en que el proveedor de identidad lo hará. El proveedor de identidad devuelve entonces un token de identificación que la parte que confía puede utilizar para afirmar la identidad del usuario.

Tenga en cuenta que, como antes, el cliente debe registrarse con el servidor de autorización antes de iniciar el flujo. Cubriremos esto en la incorporación más adelante.

Open ID Connect: http://openid.net/specs/openid-connect-core-1_0-final.html

Documentos de ForgeRock: https://backstage.forgerock.com/docs/am/6/oidc1-guide/index.html

Diagrama 5: Flujo de código de autorización de OpenID Connect
Diagrama 5: Flujo de código de autorización de OpenID Connect

La especificación OpenID Connect (OIDC) define un elemento llamado parámetro de solicitud de notificaciones. El parámetro se puede utilizar para solicitar que se devuelvan reclamaciones específicas en el token de ID. De manera crucial, la especificación OIDC también permite que la solicitud especifique las propiedades de las reclamaciones que se solicitan. Esto nos permite resolver el problema de alcance discutido anteriormente porque ahora podemos usar el parámetro de solicitud de reclamaciones OIDC con el fin de solicitar autorización para propiedades específicas. El parámetro de solicitudes también nos permite firmar la solicitud, lo que asegura que podamos detectar si ha sido manipulada.

A continuación, se muestra cómo se ve el parámetro de reclamaciones en el flujo de banca abierta del Reino Unido:

{
    "alg": "RS256",
    "kid": "GxlIiwianVqsDuushgjE0OTUxOTk"
}
.
{
   "aud": "https://api.alphanbank.com",
   "iss": "s6BhdRkqt3",
   "response_type": "code id_token",
   "client_id": "s6BhdRkqt3",
   "redirect_uri": "https://api.mytpp.com/cb",
   "scope": "openid payments accounts",
   "state": "af0ifjsldkj",
   "nonce": "n-0S6_WzA2Mj",
   "max_age": 86400,
   "claims":
    {
     "userinfo":
      {
       "openbanking_intent_id": {"value": "urn:alphabank-intent-58923", "essential": true}
      },
     "id_token":
      {
       "openbanking_intent_id": {"value": "urn-alphabank-intent-58923", "essential": true},
       "acr": {"essential": true,
                "values": ["urn:openbanking:psd2:sca",
                     "urn:openbanking:psd2:ca"]}}
      }
    }
}

La parte importante del parámetro de reclamación es openbanking_intent_id. Así es como resolvemos el problema del alcance.

Diagrama 6: Uso del parámetro de solicitud de reclamaciones
Diagrama 6: Uso del parámetro de solicitud de reclamaciones

Ya hemos mencionado que la OIDC se ocupa de la autenticación delegada, pero ese no es el problema que intentamos resolver con la banca abierta. En el contexto de la banca abierta, no dependemos del token de identificación para autenticar a un usuario. En su lugar, estamos utilizando el token como una firma separada para la respuesta de autorización según la especificación FAPI (API financiera). Esta es una solución elegante a nuestro problema anterior con los alcances y nos permite alinearnos con el modelo FAPI para la seguridad API financiera, que hace un uso extensivo de OIDC.

La ForgeRock Identity Platform ofrece soporte completo para OAuth y OIDC, incluido el parámetro de solicitud, OOTB.

FAPI: http://openid.net/wg/fapi/

Firma separada: http://openid.net/specs/openid-financial-api-part-2-wd-02.html

Parámetro de reclamaciones: http://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter

ForgeRock Docs: https://backstage.forgerock.com/docs/am/6/oidc1-guide/index.html#global-oauth-oidc-advanced-openid-connect

Especificación de API financiera

La especificación de API financiera (FAPI) es un estándar preliminar para configurar soluciones de seguridad de API financiera. Define los flujos recomendados, los parámetros de configuración y los algoritmos de firma y cifrado para las implementaciones de OAuth y OIDC a fin de mejorar la seguridad y mitigar los riesgos y ataques conocidos. También agrega controles de seguridad adicionales en torno a todas las solicitudes y respuestas de la banca abierta.

FAPI Headers: https://openid.net/specs/openid-financial-api-part-1.html

Solicitud de dos etapas

La banca abierta utiliza un mecanismo de solicitud de dos fases, en el que una solicitud de pago o de cuenta se realiza primero antes de ser autorizada.

Diagrama 7: Solicitud de dos etapas
Diagrama 7: Solicitud de dos etapas

El tercero envía una intención de pago o de cuenta que representa la solicitud a la que se pedirá el consentimiento del usuario en el siguiente paso de autorización. El banco puede presentar esta información al usuario en el momento del consentimiento para que comprenda con claridad qué es lo que acepta.

TLS de autenticación mutua

El punto final de OAuth utilizado para emitir tokens de acceso a terceros está protegido por TLS de autenticación mutua (MATLS). Los terceros deberán utilizar el certificado de transporte que les expida el directorio para intercambiar un código de autorización por un token de acceso. El banco también se asegurará de que el certificado TLS que se utiliza coincida con el del cliente OAuth.

Autenticación

Cuando el banco recibe una solicitud de OAuth/OIDC para autorizar un pago, primero debe identificar al usuario y verificar que es quien dice ser. La especificación de banca abierta del Reino Unido no establece cómo se debe lograr esto. Sin embargo, PSD2 espera una autenticación sólida del cliente. Aunque hemos desactivado esta opción en nuestro entorno de referencia para simplificar la experiencia del desarrollador, en realidad necesitará un enfoque sólido y confiable para autenticar a los clientes usando al menos dos de los tres elementos de conocimiento: posesión e inherencia.

La autenticación inteligente en la ForgeRock Identity Platform satisface este requisito y le permite ir más allá y tener en cuenta una serie de factores contextuales, conductuales y basados en riesgos durante el proceso de autenticación.

ForgeRock Intelligent Authentication Flow
ForgeRock Intelligent Authentication Flow

ForgeRock Docs:: https://backstage.forgerock.com/docs/am/6/authentication-guide/#sec-configure-authentication-trees

Consentimiento

Finalmente, se debe solicitar que el usuario dé su consentimiento. El banco debe tener claro lo que el usuario está consintiendo y ofrecerle la opción de aprobar o denegar el consentimiento. Esta información debe ser clara y concisa.

Servicio de consentimiento remoto

La plataforma OOTB de ForgeRock Identity ofrece una pantalla de consentimiento estándar OAuth. Estando activamente comprometido con los bancos para ofrecer soluciones de banca abierta, ForgeRock se dio cuenta de que esta pantalla básica no sería suficiente. Como resultado, introdujimos el concepto de un Servicio de Consentimiento Remoto (RCS) en la ForgeRock Identity Platform. El RCS permite que la plataforma se dirija a otro servicio para presentar una solicitud de consentimiento y recopilar el resultado, lo que permite una interfaz de consentimiento más enriquecedora que, por ejemplo, puede permitir que un cliente elija qué cuenta bancaria utilizar para un pago.

Al obtener el consentimiento, el RCS devuelve el resultado a la ForgeRock Identity Platform, que emite un código de autorización según el flujo de OAuth.

Documentation: https://backstage.forgerock.com/docs/am/6/oauth2-guide/#oauth2-implement-remote-consent

incorporación

Ahora que tenemos un mecanismo para obtener el consentimiento, lo que necesitamos es una forma segura de incorporar y verificar a los terceros que desean acceder a los datos de la cuenta. Aquí es en donde entra en juego el directorio.

El directorio

El Open Banking Directory sirve como plataforma central para verificar cuáles son los bancos y los terceros que están aprobados para participar en el ecosistema de banca abierta del Reino Unido. El registro en la versión dinámica del Open Banking Directory depende de la aprobación de la Autoridad de Comportamiento Financiero (FCA). Sin embargo, la nueva área de prueba del directorio que proporciona ForgeRock no tiene tales restricciones y es una solución totalmente compatible.

El Open Banking Directory cumple varias funciones clave para el ecosistema de banca abierta, tales como las siguientes:

  • Permitir que terceros y los bancos registren sus datos y parámetros OAuth, como redirect_url's y puntos finales bien conocidos

  • Emitir claves de firma, cifrado y transporte para uso de terceros al incorporarse a bancos, realizar solicitudes de autorización y acceder a los datos

  • Issuing Software Statement Assertions (SSAs), the items of proof that third parties will present to banks to onboard as verified participants

  • Alojamiento de los puntos finales de JSON Web Key (JWK) utilizados para verificar las firmas web JSON (JWS)

  • Descarga de claves en varios formatos: JWK, PEM o .key

Diagrama 8: El Open Banking Directory
Diagrama 8: El Open Banking Directory

 

Certificados

El directorio emite tres tipos diferentes de certificados:

  1. Firma: los certificados de firma se utilizan para crear JWS con el objetivo de firmar cargas útiles de JSON Web Token (JWT) durante los procesos de incorporación y autorización.
     

  2. Cifrado: los certificados de cifrado se utilizan para cifrar las cargas útiles de JWT y para el cifrado de tokens de identificación. Por ejemplo, si desea recibir un token de identificación cifrado, el banco utilizará su certificado de cifrado para cifrar el JWS.


// JOSEHeader: JSON Object Signing and Encryption Header 
// json: The Content of the JWT to sign and encrypt 
// privateKey: The private key


payload = base64Encode ( JOSEHeader ) + “.” +base64Encode(json) 
signedAndEncodedPayload = base64Encode (encrypt(privateKey, payload)) 
JSW = payload + “.” + signedAndEncodedPayload

Proceso de creación de JWS
  1. Transporte: el TLS mutuo se utiliza para cifrar las solicitudes y respuestas entre terceros y los bancos mediante certificados de transporte emitidos por el directorio.

Declaraciones de software y registro dinámico de clientes

Las afirmaciones de software (SSA) forman parte del protocolo de registro dinámico de clientes de OAuth 2.0. El registro dinámico de clientes es un mecanismo que permite que los clientes de OAuth se registren y creen de forma automática al recibir un elemento de prueba (SSA). Esto permite a terceros incorporarse rápidamente con los bancos y recibir un ID de cliente que pueden utilizar más tarde.

Este es el aspecto de una SSA cuando se descodifica:

JWT Header
{
  "kid": "e0f8da35-05c4-42a5-96ee-bf48a4924fa2",
  "alg": "RS256"
}
JWT Claims
{
  "org_jwks_endpoint": "TODO",
  "software_mode": "TEST",
  "software_redirect_uris": [
    "http://example.com/redirect"
  ],
  "org_status": "Active",
  "software_client_id": "5b11771fdecdcd0648d063e3",
  "iss": "ForgeRock",
  "software_tos_uri": "http://example.com/terms.html",
  "software_client_description": "Third Party Description",
  "software_jwks_endpoint": "https://service.directory.integ-ob.forgerock.financial/directory-services/api/software-statement/5b11771fdecdcd0648d063e3/application/jwk_uri",
  "software_policy_uri": "http://example.com/policy.html",
  "software_id": "5b11771fdecdcd0648d063e3",
  "org_contacts": [],
  "ob_registry_tos": "https://directory.integ-ob.forgerock.financial/tos/",
  "org_id": "5b117707decdcd0648d063e2",
  "software_logo_uri": "http://example.com/logo.jpg",
  "software_jwks_revoked_endpoint": "TODO",
  "software_roles": [
    "AISP",
    "PISP"
  ],
  "exp": 1528476229,
  "org_name": "[email protected]",
  "org_jwks_revoked_endpoint": "TODO",
  "iat": 1527871429,
  "jti": "24a4f5f6-e85d-4654-b288-e3eaa132587f"
}
Ejemplo de una SSA decodificada

 

Creación de una SSA mediante el uso del ForgeRock Open Banking Directory
Creación de una SSA mediante el uso del ForgeRock Open Banking Directory

Crear una SSA es un paso necesario para interactuar con el ecosistema de la banca abierta. Si desea crear una usted mismo, puede usar el nuevo ForgeRock Open Banking Directory para hacer exactamente eso: https://directory.ob.forgerock.financial/

Registro dinámico de clientes: https://tools.ietf.org/html/rfc7591

Registro de un TPP: https://backstage.forgerock.com/knowledge/openbanking/article/a39093356

ForgeRock Docs: https://backstage.forgerock.com/docs/am/6/oauth2-guide/#register-oauth2-client-dynamic

Por lo general, para iniciar un flujo de OAuth u OIDC, el tercero debe tener un conjunto de credenciales. Normalmente, con los clientes OAuth, se emite un ID de cliente y un secreto para el tercero. Sin embargo, este es uno de los varios mecanismos de autenticación que están disponibles en la especificación OIDC. En nuestra implementación bancaria de referencia hemos elegido el método de autenticación private_key_jwt.

Con private_key_jwt, en lugar de usar un ID de cliente explícito y un secreto, la clave con la que firma su JWT realmente sirve como su credencial. Después de una integración exitosa con una SSA, el servidor de autorización vinculará su URI de JWK con el nuevo cliente de OIDC. Cuando se reciben futuras solicitudes de OIDC, el servidor de autorización verifica que la firma del JWT coincide con la afirmación de "sujeto" de su solicitud.

Clave web Json

Json Web Key (JWK) es el formato utilizado en OIDC para publicar sus claves públicas en un tercero. Al publicar las claves como JWK, el formato utilizado para compartir varias claves se llama jwk_uri. Un buen ejemplo de este formato es el directorio jwk_uri. Como cualquier aplicación, el directorio también publica sus claves como un jwk_uri: https://service.directory.ob.forgerock.financial/directory-services/api/directory/keys/jwk_uri

Es necesario publicar sus claves públicas en un formato jwk_uri, ya que un tercero deberá verificar las JWT que haya firmado o usar sus claves públicas para cifrar JWT que solo usted pueda leer. En este momento, el directorio gestiona esto en nombre de los TPP.

TLS de autenticación mutua

Los puntos finales de los bancos están protegidos por MATLS. Esto significa que si necesita usar una API que requiera un cierto nivel de permisos, deberá asegurarse de haber configurado su certificado de transporte en consecuencia.

MATLS es el mismo mecanismo que hemos elegido implementar para proteger nuestra API REST de directorio y API REST de JWKMS (JWK Management Service).

El ASPSP realizará más comprobaciones de seguridad cuando se deba, con su certificado de transporte. Por ejemplo, cuando usted registra su solicitud con una SSA, la RS verificará que el certificado de transporte coincida con las reclamaciones de la SSA.

ForgeRock Open Banking Directory: el directorio es un componente clave del ecosistema de la banca abierta; sin embargo, el directorio dinámico requiere que el tercero se registre y trabaje a través de la aprobación de la Autoridad de Comportamiento Financiero (FCA), que puede tardar varias semanas y presenta una barrera significativa para la entrada de terceros que desean desarrollar servicios de banca abierta.

El ForgeRock Open Banking Directory se desarrolló para resolver este problema. Es un directorio totalmente compatible con la misma funcionalidad que el directorio dinámico, sin embargo, cualquier persona que desee acceder a él lo puede hacer de forma inmediata. Además, hemos aumentado el directorio con una serie de servicios útiles para ayudar a los desarrolladores a probar sus integraciones, como los JWKms.

JWKms: JWKms es un servicio adyacente al directorio. Utilizar las claves generadas por el directorio le permite manipular los JWT en su nombre y proporciona la siguiente funcionalidad:

  • Pruebe su configuración de MATLS

  • Proporcione las claves en formato JWK_URI

  • Firme reclamaciones como un JWS

  • Firmar y luego cifrar las reclamaciones como JWE (JWS)

  • Descifre un JWE

  • Validar un JWT

  • Rote las claves

  • Restablezca las claves

Además de lo anterior, JWKms también implementa un mecanismo de rotación de claves que se requiere para cualquier configuración de OIDC que haga uso de claves asimétricas.

Toda la funcionalidad anterior de JWKms se ha expuesto a través de las API y, como resultado de esta funcionalidad, podemos ofrecer a los desarrolladores una experiencia completamente libre de códigos a medida que aprenden como operar con las API de banca abierta.

Acceso

Ahora contamos con un mecanismo seguro y basado en estándares para autorizar el consentimiento y la incorporación de terceros a un nivel muy alto de garantía. La pieza final del rompecabezas es proporcionar un medio por el cual los terceros pueden acceder a las API de pagos y cuentas. Por lo general, esto lo proporciona una puerta de enlace de API que validará el token de acceso emitido en el flujo de solicitud de autorización.

Las puertas de enlace tienen dos formas de validar los tokens de acceso según la arquitectura del token. La especificación no es prescriptiva aquí:

  • Con estado: si se utilizan tokens de acceso con estado, la puerta de enlace de la API deberá invocar un punto de enlace en el servidor de autorización para validar el token.

  • Sin estado: si se usa un token de acceso sin estado, la puerta de enlace de la API usaría el JWK_URI para verificar la firma del token.

TLS de autenticación mutua

El TLS de autenticación mutua (MATLS) se utiliza de nuevo cuando un tercero accede a la API. La puerta de enlace de la API también debe verificar que los detalles del tercero incluidos en el certificado de transporte utilizado para acceder a los puntos finales de la API coincidan con los detalles del tercero en el certificado utilizado para firmar el token de acceso.

FAPI

Las recomendaciones de FAPI se aplican al realizar solicitudes a la API. FAPI define una serie de encabezados adicionales que deben establecerse y ayudan a proporcionar un identificador consistente en toda la interacción, al tiempo que captura datos adicionales, como la dirección IP desde la que el cliente está iniciando sesión y la última vez que inició sesión, lo cual cobra importancia desde una perspectiva de seguridad y auditoría.

Resumen

En este documento, hemos abordado las características clave de seguridad de ForgeRock que permiten el consentimiento y la confianza en la especificación de banca abierta del Reino Unido. La ForgeRock Identity Platform, que incluye el ForgeRock Model Bank y el ForgeRock Open Banking Directory, permite a terceros y a los bancos probar e integrarse en el ecosistema de banca abierta. Con una comprensión de alto nivel de cómo funciona el ecosistema, puede crear un tercero, incorporarse en el directorio y probar los flujos de banca abierta en el área de prueba del directorio de ForgeRock.

Obtenga más información sobre la banca abierta de ForgeRock para su organización

ForgeRock es el líder en identidad digital y confianza, diseñado para admitir la banca abierta, asegurar la empresa, crear confianza y lealtad de los clientes y aumentar las oportunidades de negocio y los ingresos hoy y en el futuro.

Contáctenos para obtener más información sobre cómo ForgeRock puede ayudar a su organización a admitir la banca abierta.

ForgeRock® es la empresa de gestión de identidades digitales que está transformando la forma en la que las organizaciones interactúan de forma segura con los clientes, los empleados, los dispositivos y las cosas. Las organizaciones adoptan ForgeRock Identity Platform™ como su sistema de identidad digital de registro para monetizar las relaciones con los clientes, abordar regulaciones estrictas para la privacidad y el consentimiento (GDPR, HIPAA, privacidad de la FCC, etc.) y aprovechar el Internet de las cosas. ForgeRock sirve a cientos de marcas, incluidas Morningstar, Vodafone, GEICO, Toyota, TomTom y Pearson, así como a gobiernos, por ejemplo, los de Noruega, Canadá y Bélgica, asegurando miles de millones de identidades en todo el mundo. ForgeRock tiene oficinas en Europa, Estados Unidos y Asia.

Glosario

AISP - Account Information Service Provider

ASPSP - Account Servicing Payment Service Providers, e.g. banks

API - Application Programming Interface

FAPI - Financial API Working Group

FCA - Financial Conduct Authority

JWE - JSON Web Encryption

JWK - JSON Web Key

JWKMS - JWK Management Service

JWS - JSON Web Signature

JWT - JSON Web Token

MATLS - Mutual Authentication TLS

OB - Open Banking

OIDC - OpenID Connect

PISP - Payment Initiation Service Provider

PSD2 - Payment Services Directive 2

REST - Representational State Transfer

RS - Resource Server

SSA - Software Statement Assertion

TLS - Transport Layer Security

TPP - Third Party Provider