x-jws-signature

Para garantizar la integridad de los datos de los payloads de solicitud y respuesta, las APIs de Redeban han adoptado el estándar de Open Banking de Reino Unido para firmas separadas utilizando el encabezado x-jws-signature.

Consulte el siguiente enlace para más detalles:

https://openbankinguk.github.io/read-write-api-site3/v3.1.2/profiles/read-write-data-api-profile.html#process-for-signing-a-payload

Firma de mensajes

Descripción General

En esta sección se proporciona una descripción general de cómo se implementa la firma de mensajes para las API de lectura/escritura de Open Banking. Las API requieren autenticación mutua TLS 1.2 y esto se puede utilizar como medio de no repudio. Sin embargo, sería difícil mantener los registros digitales y las pruebas de no repudio si la API solo se basara en TLS 1.2.Una solución para el no repudio que no se base en TLS, se lograría proporcionando un JWS con contenido separado (como se define en RFC 7515 - Apéndice F) en el encabezado HTTP de cada solicitud de API.El cuerpo HTTP formaría un payload sin codificar como se define en RFC 7797.El JWS se firmaría utilizando un algoritmo que admite claves asimétricas.La solicitud estaría firmada por la clave privada de un TPP, y la respuesta estaría firmada por la clave privada del ASPSP. No todas las solicitudes y respuestas de la API están firmadas. El hecho de que la firma de mensajes sea obligatoria, admitida o no admitida se documenta junto con cada API.

Almacenes de Claves

Un mecanismo de confianza en la que confían los ASPSP y los TPP es responsable de proporcionar un almacén de claves públicas para cada una de las partes. El mecanismo de confianza podría ser un directorio centralizado (como el Open Banking Directory) que aloja la parte pública de un par de claves generado por cualquiera de las partes. Alternativamente, el mecanismo de confianza podría ser una CA (o un conjunto de CA) que proporciona certificados digitales. El mecanismo de confianza debe proporcionar un medio para que cualquiera de las partes recupere las claves públicas para verificar los mensajes.

Especificación

El TPP debe firmar el cuerpo HTTP de cada solicitud de API que requiera la firma de mensajes. El ASPSP debe firmar el cuerpo HTTP de cada respuesta de API que requiera la firma de mensajes. La ASPSP debe verificar la firma de las solicitudes de API que recibe antes de llevar a cabo la solicitud. Si la firma falla la validación, el ASPSP debe responder con un 400 (Solicitud incorrecta). El ASPSP debe rechazar cualquier solicitud de API que deba estar firmada pero que no contenga una firma en el encabezado HTTP con un error 400 (solicitud incorrecta). El TPP debe verificar la firma de las respuestas de la API que recibe.El firmante debe firmar el mensaje con PS256.

Proceso para firmar el cuerpo del mensaje

Paso 1: Identifique la clave privada y el certificado de firma correspondiente que se utilizará para firmar

El firmante debe usar una clave privada que corresponda al certificado público emitido por el directorio de participantes. La clave utilizada para la firma debe ser válida en el momento de generar el JWS (JSON Web Signature).

Paso 2: Elaborar el encabezado JOSE

El encabezado JOSE de la firma debe contener los siguientes campos:

{
  "http://openbanking.org.uk/iat": 1758714406, [Epoch timestamp in seconds]
  "http://openbanking.org.uk/tan": "openbanking.org.uk", [constant]
  "crit": [
    "http://openbanking.org.uk/iat",
    "http://openbanking.org.uk/tan",
    "http://openbanking.org.uk/iss"
  ], [constant]
  "kid": "lheqH9DX9zbGwlP4heocNbd7o98", [kid of the signing key]
  "cty": "application/json", [constant]
  "typ": "JOSE", [constant]
  "http://openbanking.org.uk/iss": "0015800000jfQ9aAAE/wWrpsowUcH3HKKJzHjwNuZ", [Issuer should be in the format: org_id/client_id]
  "alg": "PS256" [the signing algorithm]
}

Paso 3: Calcular el JWS

El firmante debe calcular la firma como un JWS separado como se define en RFC 7515, Apéndice F. "Una forma de hacer esto es crear un JWS de la manera normal usando una representación del contenido como el cuerpo del mensaje, pero luego eliminar la representación de. cuerpo del mensaje en el JWS y enviar este objeto modificado al destinatario en lugar del JWS". Tenga en cuenta que este método no necesita soporte de las bibliotecas JWS, ya que las aplicaciones pueden utilizar este método modificando las entradas y salidas de las bibliotecas JWS estándar.

Paso 4: Agregue el JWS como encabezado HTTP

El firmante debe incluir un encabezado HTTP denominado x-jws-signature con su valor establecido en la firma calculada en el paso 3.

Ejemplo, x-jws-signature:

eyJodHRwOlwvXC9vcGVuYmFua2luZy5vcmcudWtcL2lhdCI6MTc1MDg1NzU3MiwiaHR0cDpcL1wvb3BlbmJhbmtpbmcub3JnLnVrXC90YW4iOiJvcGVuYmFua2luZy5vcmcudWsiLCJjcml0IjpbImh0dHA6XC9cL29wZW5iYW5raW5nLm9yZy51a1wvaWF0IiwiaHR0cDpcL1wvb3BlbmJhbmtpbmcub3JnLnVrXC90YW4iLCJodHRwOlwvXC9vcGVuYmFua2luZy5vcmcudWtcL2lzcyJdLCJraWQiOiI3NjhLUkViVGp0Y3JIdmQ3cXJ4N1Y2bFlOWEk9IiwiY3R5IjoiYXBwbGljYXRpb25cL2pzb24iLCJ0eXAiOiJKT1NFIiwiaHR0cDpcL1wvb3BlbmJhbmtpbmcub3JnLnVrXC9pc3MiOiJPQi1lNWY1OGFjZS0wOTYxLTRlNDQtYWYzYy0zNTI2NWVkOGI3YzlcL1NDLTE1ZTU1YmY4LWJlNDktNGUzMS1hMTJkLTY1YWNkMzk2YzMzNyIsImFsZyI6IlBTMjU2In0..M502E4oRnE25tgKbgiYrEJSEU4TMrudaND6Pe5zV23VTyD4uVxewBUlM0fd6QN8M-jVN0J9twm00HxidssQykPKarWUd89a5WrMhZ0BQybL_qq7CQ5mpQV26YykPw2aHxY-CbKVHI04V1C1FI8K5s4BRdpN-9TeMsbgKef05qP-M35QfjFVjuB4HUATE-XwP41jNkmanDQeErN7akCWRCCrvMW9Cj4cYaTiCE_GI2aaBno89o07Be_U_lDN2ht0iH-yzMNkJZyai-44IlOIEVePuaOUXTMJ-7BQDxiZJkT5NNQwGARxpN-m4yqmhdudTBQ_iqsCAO6pMylQh1eKfNQ