El PSR (DSP3) para auditoría y pentest

Por dónde empezar

Las cinco obligaciones que más cambian para este rol.

• OB-IF-017PSR 36(2)(a)Cubierto

  Identificación del TPP ante el ASPSP

  La interfaz permite a los AISP y a los PISP identificarse ante el ASPSP, y lo hacen en cada iniciación de pago en el caso del PISP y en cada sesión en el del AISP.

  STET 1.6.3 STET identifica al TPP con un certificado eIDAS QWAC en mTLS y comprueba que el client_id corresponde al número de autorización del certificado. El PSR no dice por qué medio se identifica el TPP.

• OB-IF-009PSR 36(2)(b)Cubierto

  Autenticación iniciada por el TPP, sesión protegida

  La interfaz permite al TPP pedir al ASPSP que inicie la autenticación sobre la base del consentimiento del usuario, mantiene la sesión entre las partes durante toda la autenticación y protege la integridad y la confidencialidad de las credenciales y de los códigos de autenticación.

  STET 1.6.3 En redirección o en desacoplado, el TPP desencadena la autenticación en el banco, mediante la autorización OAuth2 en el caso del AISP y mediante la solicitud de pago en el del PISP, sobre una conexión TLS con autenticación mutua.

• OB-AIS-007PSR 47(1)(d)Cubierto

  El AISP solo accede a las cuentas designadas

  El AISP solo accede a la información de las cuentas designadas y de sus operaciones, con mecanismos que impiden cualquier otro acceso, conforme al consentimiento del usuario.

  STET 1.6.3 PUT /consents enumera, por tipo de dato, las cuentas que el usuario ha designado, y el banco lo usa para limitar el acceso.

• OB-SCA-002PSR 86(3)A revisar

  SCA del ASPSP solo en el primer acceso del AISP

  Para un AISP concreto, el ASPSP solo aplica la SCA en el primer acceso a los datos de la cuenta y no después, salvo motivos razonables para sospechar fraude.

  STET 1.6.3 El Framework hace revocar el refresh token del AISP cuando vence el plazo reglamentario entre dos SCA, lo que devuelve al usuario a una SCA en el banco. Tras el primer acceso, el banco ya no puede imponerla, y renovar la SCA corresponde al AISP (OB-SCA-003).

• OB-DB-006PSR 43(2b)Fuera de la spec

  Tras una retirada, el TPP se detiene y borra

  Tras una retirada, el TPP deja de acceder a los datos y de usarlos, y luego los borra sin demora indebida pero no antes de 48 horas, salvo que el usuario elija expresamente que los conserve.

  STET 1.6.3 El TPP solo puede aplicar esta regla si se entera de la retirada, algo que STET solo le comunica de forma indirecta (OB-DB-008).

Páginas del manual STET 1.6.3 que conviene leer

Las páginas que citan estas obligaciones, de la más citada a la menos citada.

• 3. Requisitos previos y detalles técnicosCitada por OB-IF-009, OB-IF-017, OB-OBS-001, OB-OBS-008, OB-OBS-009, OB-OBS-011, OB-SCA-002, OB-SCA-003
• 6.1. Recuperación del contexto del PSUCitada por OB-IF-009, OB-SCA-002, OB-SCA-003
• POST /payment-requestsCitada por OB-IF-009, OB-OBS-002
• AuthenticationApproachCitada por OB-OBS-001, OB-OBS-009
• PUT /consentsCitada por OB-AIS-007
• 6.2. Reenvío del consentimientoCitada por OB-AIS-007
• PaymentRequestResourceCitada por OB-OBS-002
• POST /payment-requests/{paymentRequestResourceId}/confirmationCitada por OB-OBS-012
• 8.2. Solicitud de pago con múltiples instrucciones que tienen diferentes beneficiariosCitada por OB-OBS-012

Fichas del glosario

• SCA
• mTLS
• QWAC
• OAuth2
• FAPI
• DORA