3. Requisitos previos y detalles técnicos

3.1. Registro de los actores

Los actores PSD2 deben ser registrados por una autoridad de registro. La información recopilada debe ser accesible para los demás actores con el fin de aportar confianza e interoperabilidad.

Un actor no registrado no puede interactuar con otro actor.

Cada actor debe disponer de al menos un certificado eIDAS (QWAC), para TLS 1.2, emitido por un prestador de servicios de confianza cualificado (QTSP) registrado.

La lista de QTSP de la Comisión Europea puede consultarse en la siguiente URL:

https://esignature.ec.europa.eu/efda/tl-browser/#/screen/home

3.2. Autenticación cruzada y cifrado de datos

La API STET PSD2 se basa en el protocolo TLS 1.2 para obtener una autenticación cruzada entre actores. Además, este protocolo también garantiza la confidencialidad de los datos durante su transporte por la red.

Cada vez que un TPP se conecta como cliente a un servicio de API de un ASPSP, comprueba el certificado de servidor del ASPSP (QWAC) y presenta su propio certificado eIDAS (QWAC) respetando la especificación técnica ETSI/TS119495.

La identificación de la organización (Organizational Identification) dentro del Subject Distinguished Name del certificado debe considerarse en realidad como un número de autorización (Authorization Number) que respetará las siguientes reglas de formato:

«PSD» como referencia de tipo de identidad de persona jurídica de 3 caracteres;
código de país ISO 3166 [7] de 2 caracteres que representa el país de la NCA;
guion «-» (0x2D (ASCII), U+002D (UTF-8)); y
identificador de NCA de 2 a 8 caracteres (A-Z solo mayúsculas, sin separador);
guion «-» (0x2D (ASCII), U+002D (UTF-8)); y
identificador del PSP (número de autorización tal como lo especifica la NCA).

En caso de fallo de autenticación, en un lado o en el otro, la conexión debe cerrarse.

No se requiere ninguna función adicional de cifrado o autenticación.

3.3. Enfoques de autenticación del cliente

Un TPP puede utilizar tres enfoques distintos para permitir la autenticación del PSU por parte del ASPSP. Estos enfoques se basan en una identificación del PSU que debe ser pertinente para el ASPSP (identificador nacional o identificador de cliente del banco).

Estos enfoques se implementan de distintas maneras, según el caso de uso correspondiente:

bien durante el proceso de autorización (cf. §3.4.2), principalmente para los casos de uso AISP y CBPII,
bien durante el proceso de confirmación del consentimiento, por ejemplo en el caso de un PISP que envía una solicitud de pago (cf. § 3.4.2).

3.3.1. Enfoque por redirección (Redirect)

Con el enfoque por redirección, el proceso de autenticación del PSU es tratado íntegramente por el ASPSP.

Para ello, el TPP debe redirigir al PSU al servicio de autenticación del ASPSP, lo que significa que el PSU abandonará temporalmente la interfaz del TPP para autenticarse en la interfaz del ASPSP.

El TPP puede haber capturado ya un identificador de PSU que el ASPSP pueda utilizar para reconocer inequívocamente al PSU. En ese caso, este identificador puede transmitirse mediante la redirección, cuando el protocolo de redirección permite la transmisión de este identificador.

Tras la finalización de la autenticación, el ASPSP redirige al PSU de vuelta a la interfaz del TPP.

3.3.2. Enfoque desacoplado (Decoupled)

Con el enfoque desacoplado, el proceso de autenticación del PSU es tratado íntegramente por el ASPSP.

Para ello, el TPP debe capturar un identificador de PSU que el ASPSP pueda utilizar para reconocer inequívocamente al PSU, y transmitir este identificador al ASPSP.

Sobre la base de este identificador, el ASPSP activará una autenticación a través de un dispositivo o una aplicación desacoplados, lo que significa que el PSU no abandonará la interfaz del TPP durante el proceso de autenticación.

3.3.3. Exenciones a la autenticación reforzada del cliente

Las exenciones a la autenticación reforzada del cliente están especificadas por las RTS de la EBA sobre SCA, en particular para los servicios de iniciación de pagos.

En este contexto, la API permite al PISP transmitir al ASPSP cualquier información útil.

Además, el PISP también puede sugerir al ASPSP si la solicitud de pago correspondiente podría o no acogerse a una exención.

En última instancia, el ASPSP conserva la decisión final de aplicar o no esta exención.

3.4. Autorización

3.4.1. Niveles de autorización

Los siguientes niveles de autorización pueden comprobarse y combinarse para calcular los derechos efectivos concedidos al TPP:

NIVEL DE AUTORIZACIÓN	DESCRIPCIÓN
Autorización por rol del TPP	Una vez que el TPP ha sido registrado para un rol determinado, puede invocar cualquier funcionalidad PSD2 proporcionada por un ASPSP a través de la API STET PSD2 para ese rol.
Autorización por acuerdo TPP-ASPSP	El TPP puede invocar cualquier funcionalidad adicional (no PSD2) proporcionada por un ASPSP a través de la API STET PSD2, siempre que exista un acuerdo bilateral para utilizar estas funcionalidades.
Autorización por acuerdo TPP-PSU	Si el PSU ha contratado con un TPP, debe - dar una lista de los ASPSP a los que autoriza el acceso del TPP - realizar una autenticación ante cada uno de esos ASPSP correspondientes, lo que permitirá después al TPP acceder a los datos del PSU.
Autorización por contexto PSU	El PSU puede especificar su contexto PSU detallando, para cada una de sus cuentas correspondientes: - si esta cuenta será accesible o no por el TPP - qué funcionalidades puede utilizar el TPP El PSU puede modificar en todo momento su contexto PSU.

3.4.2. Bases técnicas

El TPP está autorizado a acceder a la API del ASPSP a través de un token de acceso (access token) que puede

obtenerse a través del marco de autorización OAuth2 (https://tools.ietf.org/html/rfc6749).

Pueden utilizarse distintas concesiones de autorización (grants), según el rol del TPP y el caso de uso que deba aplicarse.

El TPP puede necesitar gestionar varios tokens OAuth2 proporcionados por un ASPSP determinado por cuenta de un PSU determinado. En efecto, la solicitud de un nuevo token OAuth2 no debe implicar la revocación de uno anterior.

3.4.2.1. Correspondencia de identidad del TPP

El protocolo OAuth2 se refuerza comprobando la identidad del TPP durante los procedimientos OAuth2 mediante el certificado eIDAS del TPP, basándose en MTLS (https://datatracker.ietf.org/doc/rfc8705/).

Este refuerzo se obtiene mediante el suministro obligatorio, por parte del TPP, de un campo [client_id] en todas las solicitudes OAuth2. Este [client_id] debe corresponder, directa o indirectamente, con el número de autorización situado en el certificado eIDAS del TPP, y esta correspondencia debe comprobarla el ASPSP en cada solicitud OAuth2.

Como se utiliza MTLS, el uso del [client_secret] no es muy útil, pero algunos servidores de autorización pueden exigirlo. Toda implementación que exija el uso de un [client_secret] debe actualizar su documentación sobre este tema.

Correspondencia directa

La correspondencia puede ser obviamente directa cuando el [client_id] es igual al número de autorización.

En este caso, el API MANAGER del ASPSP puede ser capaz de comprobar y aceptar «al vuelo» la solicitud OAuth2.

Correspondencia indirecta

No obstante, en algunos casos, en particular cuando el API MANAGER no puede tratar un registro «al vuelo», debe producirse una configuración técnica OAuth2 antes de cualquier solicitud de token OAuth2. Esta configuración dará como resultado el suministro de un valor de [client_id] por parte del ASPSP al TPP.

El suministro de varios valores de [client_id] que el TPP podría utilizar para distintos casos de uso es posible repitiendo la configuración.
Además, la configuración permite el intercambio de datos operativos entre el TPP y el ASPSP para uso posterior: logotipos, números de teléfono, direcciones de correo electrónico, certificados…

Con el tiempo, esta configuración puede automatizarse.

3.4.2.2. Configuración técnica OAuth2 automatizada

Principios

Aunque la mayoría de los API managers proporcionan una interfaz de configuración en línea, esta configuración también puede automatizarse.

La RFC 7591 especifica un protocolo dinámico interactivo que permite a un cliente suministrar ciertos metadatos de contexto y obtener un valor de [client_id]. No existe ninguna restricción para proporcionar varios valores de [client_id] para los mismos metadatos de cliente y de contexto. No obstante, el número de [client_id] solicitados por un mismo cliente debe seguir siendo razonable y estar motivado por una necesidad real. Como complemento, la RFC 7592 especifica cómo recuperar, modificar o eliminar un contexto previamente publicado.

Si se necesitan varios contextos de uso para un cliente de API determinado, este cliente deberá reiterar el proceso completo para obtener tantos valores de [client_id] como sean necesarios.

En efecto, algunos TPP pueden ser cliente de una API por cuenta de un agente (Artículo 4-38 de la PSD2). Cada agente debe considerarse como un contexto de uso específico.

Como este protocolo no es obligatorio, cada implementación de API deberá precisar si está o no implementado.

Metadatos de contexto

Los elementos de metadatos pertinentes que deben proporcionarse se enumeran a continuación:

NOMBRE DEL METADATO DE CLIENTE	DESCRIPCIÓN DEL METADATO	REQUISITO	CONTROLADOR DEL CAMBIO	REFERENCIA
redirect_uris	Array de URIs de redirección para usar en flujos basados en redirección	Obligatorio	IESG	[RFC7591]
software_statement	JSON Web Token (JWT) que asevera valores de metadatos sobre el software cliente como un paquete	Opcional	IETF	[RFC7591]
token_endpoint_auth_method	Método de autenticación solicitado para el token endpoint.	Obligatorio Según la RFC8705 (cf. § 2.1.1), el valor que se utilizará será «tls_client_auth» en cuanto el draft sea promovido a RFC.	IESG IETF	[RFC7591] [RFC8705]

NOMBRE DEL METADATO DE CLIENTE	DESCRIPCIÓN DEL METADATO	REQUISITO	CONTROLADOR DEL CAMBIO	REFERENCIA
tls_client_auth_subject_dn	Indica el valor del subject del certificado que el servidor de autorización debe esperar al autenticar al cliente correspondiente.	Obligatorio Una representación en forma de cadena [RFC4514] del subject distinguished name esperado del certificado, que el cliente OAuth utilizará en la autenticación mutual-TLS.	IETF	[RFC8705]
grant_types	Array de grant types OAuth 2.0 que el cliente puede utilizar	Obligatorio Los valores permitidos son: - «authorization_code» - «ciba» - «client_credentials» - «refresh_token»	IESG	[RFC7591]
response_types	Array de los response types OAuth 2.0 que el cliente puede utilizar	Opcional «code» es el único valor permitido	IESG	[RFC7591]
client_name	Nombre legible por humanos del cliente que se presentará al usuario	Obligatorio Debe especificar el nombre del agente o por defecto el nombre del TPP.	IESG	[RFC7591]
client_uri	URL de una página web que proporciona información sobre el cliente	Opcional	IESG	[RFC7591]
logo_uri	URL que referencia un logotipo para el cliente	Opcional	IESG	[RFC7591]
scope	Lista separada por espacios de valores de scope OAuth 2.0	Opcional	IESG	[RFC7591]
contacts	Array de cadenas que representan formas de contactar a las personas responsables de este cliente, normalmente direcciones de correo electrónico	Obligatorio Debe proporcionarse al menos un contacto.	IESG	[RFC7591]
tos_uri	URL que apunta a un documento de condiciones de servicio legible por humanos para el cliente	Opcional	IESG	[RFC7591]
policy_uri	URL que apunta a un documento de política legible por humanos para el cliente	Opcional	IESG	[RFC7591]
provider_legal_id	Número de autorización del TPP según la especificación ETSI sobre certificados eIDAS para PSD2	Obligatorio	STET (por registrar)

NOMBRE DEL METADATO DE CLIENTE	DESCRIPCIÓN DEL METADATO	REQUISITO	CONTROLADOR DEL CAMBIO	REFERENCIA
client_legal_id	Número de autorización del agente (véase más abajo)	Obligatorio en caso de un agente distinto del TPP	STET (por registrar)
logo	valor codificado en base64 del logotipo	Opcional	STET (por registrar)
jwks	Valor del documento JSON Web Key Set [RFC7517] del cliente, que contiene las claves públicas del cliente.	Opcional El valor de este campo DEBE ser un objeto JSON que contenga un JWK Set válido. Estas claves pueden utilizarse por protocolos de nivel superior que usan firma o cifrado.	IESG	[RFC7591]

De manera similar a la especificación ETSI sobre el número de autorización de los TPP, el número

de autorización del agente debe respetar el siguiente formato:

«AGT» como referencia de tipo de identidad de persona jurídica de 3 caracteres;
código de país ISO 3166 de 2 caracteres que representa el país de la NCA;
- guion «-» (0x2D (ASCII), U+002D (UTF-8)); y
identificador de NCA de 2 a 8 caracteres (A-Z solo mayúsculas, sin separador);
guion «-» (0x2D (ASCII), U+002D (UTF-8)); y
identificador del agente (número de registro tal como lo especifica la NCA).
Interacciones

El TPP envía sus metadatos de contexto mediante un

POST /register

En respuesta, obtiene estos metadatos de contexto completados con

el [client_id] correspondiente
un [client_secret] opcional que no es realmente útil, ya que la autenticación del cliente ya se realiza mediante MTLS.
el [registration_client_uri] como endpoint de configuración del cliente
el [registration_access_token] que debe utilizarse para acceder a la configuración del cliente.
su marca de tiempo de emisión.

La RFC7591 permite al servidor actualizar algunos de los metadatos de contexto si es necesario.

En cualquier momento, el TPP puede recuperar los metadatos de contexto mediante un

GET /register/{client_id}

La actualización de los metadatos de contexto puede realizarse mediante un

PUT /register/{client_id}

Y la eliminación de los metadatos de contexto es posible mediante un

DELETE /register/{client_id}

3.4.2.3. OAuth2 Authorization Code Grant

El proceso de autorización puede basarse en una secuencia OAuth2 para obtener un token Authorization Code Grant (cf. https://tools.ietf.org/html/rfc6749#section-4.1) e implementa el enfoque por REDIRECCIÓN.

Este tipo de token, según la implementación del ASPSP:

puede utilizarse para todos los casos de uso AISP;
puede utilizarse para el caso de uso CBPII;
puede utilizarse para el caso de uso de confirmación PISP.

El proceso puede resumirse en los siguientes pasos.

En primer lugar, el PSU debe especificar al TPP la identidad de uno de sus ASPSP.

Code verifier y challenge opcionales

Algunos servidores de autorización pueden solicitar la implementación de la RFC7636 (PKCE: Proof Key for Code Exchange) para reforzar el OAuth2 Authorization Code grant.

Por tanto, el cliente debe, como primer paso, crear un code verifier y un code challenge.

Authorization Request

El TPP inicia la secuencia OAuth2 redirigiendo al PSU a la infraestructura de autorización del ASPSP correspondiente, mediante el patrón de URL y los parámetros siguientes

Como esto se hace mediante una redirección del PSU, el certificado eIDAS del TPP no puede presentarse en esta etapa.

GET /authorize?response_type=code&client_id=&redirect_uri=&scope=[&state=]

NOMBRE		DATO	TIPO Y RESTRICCIONES
response_type	[1..1]	Tipo de token esperado	String[10] Debe valorarse con «code»
client_id	[1..1]	Identificación del TPP	String[36] debe ser igual o estar vinculado al OrganizationIdentifi er del Distinguished Name del certificado eIDAS, según la especificación ETSI
redirect_uri	[0..1]	URL de call-back del TPP	String[140]
scope	[0..1]	Especifica las acreditaciones genéricas acordadas por el PSU y el TPP: - Para AISP `o` aisp `o` extended_transaction_history - para CBPII `o` cbpii - para PISP `o` pisp	String[140] Lista de roles separada por espacios. Obligatorio
state	[0..1]	Estado interno que el TPP puede utilizar para la gestión de contexto.	String[1024] Recomendado
code_challenge	[0..1]	Code challenge calculado por el TPP según la RFC 7636	String[140] Requerido si la implementación de la RFC7636 es impuesta por el servidor de autorización
code_challenge_meth od	[0..1]	Método de code challenge utilizado por el TPP para calcular el code challenge	«S256» o «plain» El valor por defecto es «plain»

Nota: la RFC 6749 no especifica que el Authorization Code Grant admita la transmisión del nombre de usuario del Resource Owner (PSU) ni de sus preferencias de idioma.

No obstante, algunas funcionalidades de OpenID Connect pueden utilizarse con estos fines, aunque la especificación OpenID Connect no se aplique íntegramente (cf. § 3.4.2.4).

Además, esta especificación sugiere una implementación de Token Introspection (cf. § 3.4.2.7) cuyos parámetros podrían ser útiles para determinar la identidad y el contexto de uso del PSU.

Estos parámetros adicionales se resumen en la siguiente tabla.

NOMBRE	DATO	TIPO Y RESTRICCIONES
login_hint_token	Un token que contiene información que identifica al usuario final para el que se emitió el token. Esta información también puede incluir el contexto de uso específico si es necesario. Los detalles particulares y los requisitos de seguridad de este elemento, así como la forma en que el usuario final se identifica por su contenido, son específicos de cada ASPSP que implemente esta funcionalidad. Este token se habría recuperado mediante una solicitud de token introspection (cf.§ 3.4.2.7)	String [2048]
ui_locales	Idiomas y scripts preferidos del usuario final para la interfaz de usuario.	String [140] Idiomas y scripts preferidos del usuario final para la interfaz de usuario, representados como una lista separada por espacios [RFC 5646]
login_hint	Pista para el servidor de autorización sobre el identificador de inicio de sesión que el usuario final podría utilizar para conectarse (si es necesario).	String[36]

El ASPSP

Identifica y autentica al PSU
Calcula las comprobaciones pertinentes sobre el TPP (roles, validez, no revocación…)
Comprueba el [redirect_uri] frente a los que se hayan podido declarar durante la configuración técnica OAuth2 automatizada (cf. § 3.4.2.2). El [redirect_uri] proporcionado debe coincidir exactamente con uno de los que se han registrado.
Registra los [code_challenge] y [code_challenge_method] con la solicitud de código cuando se impone la implementación de la RFC 7636.

Authorization Response

A continuación, el ASPSP redirige al PSU al TPP, utilizando la URL de call-back proporcionada previamente (redirect_uri) y los parámetros siguientes:

NOMBRE		DATO		TIPO Y RESTRICCIONES
code	[1..1]	Código de corta duración que se utilizará para obtener el token de acceso	String[36]
state	[0..1]	Estado interno si lo proporcionó el TPP	String[1024] Recomendado

La duración de vida recomendada del código de autorización tal como la especifica la RFC 6749 es de 10 minutos, pero corresponde al servidor de autorización fijar su propio valor de duración de vida.

Access Token Request

Para obtener el token de acceso, el TPP puede ahora invocar, mediante una solicitud POST, la infraestructura de autorización del ASPSP con los parámetros siguientes.

POST /token HTTP/1.1 Host: server.example.com grant_type=authorization_code &code= &redirect_uri= &client_id=

NOMBRE		DATO
grant_type	[1..1]	Tipo de autorización solicitado	String[36] Debe valorarse con «authorization_code»
code	[1..1]	Código de corta duración proporcionado previamente por el ASPSP	String[36]
redirect_uri	[0..1]	URL de call-back del TPP	String[140] Debe ser igual al proporcionado durante la solicitud de código de autorización
client_id	[1..1]	Identificación del TPP.	String[36] debe ser igual o estar vinculado al OrganizationIdentifier del Distinguished Name del certificado eIDAS, según la especificación ETSI
client_secret	[0..1]	El secreto de cliente	Como la autenticación del TPP cliente se proporciona mediante MTLS, este parámetro no es muy útil.
code_verifier	[0..1]	Code verifier RFC7636 fijado inicialmente por el TPP	Requerido cuando se impone la implementación de la RFC7636 por el servidor de autorización

El ASPSP
- Identifica y autentica al TPP mediante el certificado eIDAS presentado (QWAC)
- Comprueba la correspondencia directa o indirecta entre el número de autorización del certificado eIDAS y el valor de [client_id].
- Calcula las comprobaciones pertinentes sobre el TPP (roles, validez, no revocación…)
- Verifica el valor del [code_verifier] recalculando el [code_challenge].

Access Token Response

El ASPSP responde mediante una respuesta HTTP200 (OK) que incluye los datos siguientes.

NOMBRE		DATO	TIPO Y RESTRICCIONES
access_token	[1..1]	Token de acceso proporcionado por el ASPSP al TPP.	String[140]
token_type	[1..1]	Tipo del token de acceso proporcionado («Bearer» o «MAC»)	String[10] Debe valorarse con «Bearer»
expires_in	[0..1]	Duración de vida del token, en segundos. El token puede utilizarse varias veces mientras no esté expirado.	Numeric
refresh_token	[0..1]	Refresh token que puede utilizarse para una futura solicitud de renovación de token.	String[140]

3.4.2.4. Extensión OpenID Connect del OAuth2 Authorization Code Grant

«Como funcionalidad opcional, un servidor de autorización puede implementar la especificación OpenID Connect Core 1.0» sobre el flujo OAuth2 «Authorization Code».

El protocolo OpenID Connect permite al cliente de la API (TPP) obtener del servidor de la API (ASPSP) un IdToken que certificará la identidad del PSU, una vez que este PSU haya sido autenticado por el ASPSP.

Solicitud de autenticación simple

La Open Id Connect Authentication Request se basa en la OAuth2 «Authorization Code» Authorization Request con algunos parámetros adicionales, marcados en negrita en el siguiente diagrama.

NOMBRE		DATO	TIPO Y RESTRICCIONES
response_type	[1..1]	Tipo de token esperado	String[10] Debe valorarse con «code»
client_id	[1..1]	Identificación del TPP	String[36] debe ser igual o estar vinculado al OrganizationIdentifier del Distinguished Name del certificado eIDAS, según la especificación ETSI
redirect_uri	[0..1]	URL de call-back del TPP	String[140]
Scope	[0..1]	Especifica las acreditaciones genéricas acordadas por el PSU y el TPP: - Para AISP `o` aisp `o` extended_transaction_history - para CBPII `o` cbpii. - En cualquier caso `o` openid `o` offline_access	String[140] Lista de roles separada por espacios. se requieren scopes adicionales -openid para especificar el uso de OpenID Connect -offline_access para permitir la recuperación de un refresh token dentro del contexto OpenID.
State	[0..1]	Estado interno que el TPP puede utilizar para la gestión de contexto.	String[1024]
Nonce	[0..1]	Asociación de una sesión de cliente con un Id token utilizada para mitigar ataques de repetición	String[36]
max-age	[0..1]	Edad máxima de autenticación (en segundos)	String[15]

NOMBRE		DATO	TIPO Y RESTRICCIONES
ui_locales	[1..1]	Idiomas y scripts preferidos del usuario final para la interfaz de usuario.	String [140] Idiomas y scripts preferidos del usuario final para la interfaz de usuario, representados como una lista separada por espacios [RFC 5646] Requerido por la API
id_token_hint	[0..1]	último IdToken conocido para el usuario final (PSU), si lo hay.	String [2048]
login_hint	[0..1]	Pista para el servidor de autorización sobre el identificador de inicio de sesión que el usuario final podría utilizar para conectarse (si es necesario).	String[36]
Login_hint_token	[0..1]	Un token que contiene información que identifica al usuario final para el que se emitió el token. Esta información también puede incluir el contexto de uso específico si es necesario. Los detalles particulares y los requisitos de seguridad de este elemento, así como la forma en que el usuario final se identifica por su contenido, son específicos de cada ASPSP que implemente esta funcionalidad. Este token se habría recuperado mediante una solicitud de token introspection (cf.§ 3.4.2.7)	String [2048]

El parámetro [id_token_hint] es muy útil para facilitar la renovación de una solicitud de autenticación del PSU transmitiendo su identificación ya conocida. Para una primera solicitud de autenticación, el parámetro [login_hint] puede ser utilizado por el TPP para transmitir la identificación del PSU, tal como la conoce el ASPSP.

Como la OpenID Connect Authentication Request se basa en la OAuth2 Authorization Request, esta última se enriquece de la siguiente manera:

GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &scope= openid%20%offline_access%20% aisp & nonce=n-0S6_WzA2Mj & state=af0ifjsldkj HTTP/1.1 Host: server.example.com

Solicitud de autenticación firmada

La OpenID Connect Authentication Request también puede pasarse como un Signed Request Object si el servidor de autorización lo permite.

La estructura de este Signed Request Object es un Json Web Token (JWT) cuyos datos incluyen:

los parámetros de solicitud habituales tal como se especifican anteriormente
algunos parámetros adicionales relativos a la firma (véase https://openid.net/specs/openid-connect-core-1_0.html#RequestObject para más detalles)

Cabe señalar que, aunque el Signed Request Object prevalece sobre los parámetros de solicitud habituales, estos últimos también pueden pasarse en paralelo.

Authentication Response

En caso de procesamiento correcto de la solicitud, el servidor devolverá un código de autorización mediante la redirección del PSU hacia el TPP.

HTTP/1.1 302 Found Location: https://client.example.org/cb ? code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj

Token request

El TPP solicita el intercambio del código de autorización por un token OAuth2.

POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

NB: la cabecera «Authorization» es inútil, ya que la autenticación se proporciona mediante MTLS, sobre la base del certificado eIDAS del TPP (https://datatracker.ietf.org/doc/rfc8705/).

Token response

El servidor de autorización responde con:

un token de acceso OAuth2
un refresh token OAuth2
un IdToken

HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store

Pragma: no-cache

{ "access_token": "SlAV32hkKG", "token_type": "Bearer", "refresh_token": "8xLOxBtZp8", "expires_in": 3600, "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5 NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4 XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg" }

Estructura del IdToken

La estructura del IdToken es un Json Web Token (JWT).

En el ejemplo anterior, se incluyen los siguientes datos:

{ alg: "RS256", kid: "1e9gdk7" }. { iss: " "http://server.example.com" ", sub: "248289761001", aud: "s6BhdRkqt3", nonce: "n-0S6_WzA2Mj", exp: 1311281970, iat: 1311280970 }. [signature]

Los posibles elementos de datos se describen en la siguiente tabla:

FIELD	REQUISITO	DESCRIPCIÓN
iss	Obligatorio	Identificador del proveedor del token
sub	Obligatorio	Identificador del sujeto del token
aud	Obligatorio	Destinatario del token [client_id]
nonce	Condicional	Recuperación obligatoria del parámetro [nonce] si está presente en la Authentication Request inicial
exp	Obligatorio	Fecha de expiración del IdToken [RFC3339]
iat	Obligatorio	Fecha de creación del IdToken [RFC3339]
auth_time	Condicional	Fecha y hora de autenticación del usuario final (PSU) ["https://tools.ietf.org/html/rfc3339"] cuando el parámetro [max_age] está presente en la Authentication Request inicial

3.4.2.5. Client Initiated Backchannel Authentication Grant

Este proceso de registro se basa en el flujo OpenID FAPI Connect CIBA e implementa el enfoque DESACOPLADO. (https://openid.net/specs/openid-client-initiated-backchannelauthentication-core-1_0.html)

No obstante, para evitar cualquier paso de prerregistro, se supone que esta concesión utiliza el modo polling como único medio para obtener el token solicitado.

Este tipo de token, según la implementación del ASPSP:

puede utilizarse para todos los casos de uso AISP;
puede utilizarse para el caso de uso CBPII;

Authorization Request

Para obtener el token de acceso, el TPP invoca, mediante una solicitud POST, la infraestructura

de autorización del ASPSP con los parámetros siguientes.

POST /bc_authorize HTTP/1.1 Host: as.example.com client_id= &scope= &login_hint_token= &id_token_hint= &login_hint= &binding_message= &ui_locales=

NOMBRE		DATO	TIPO Y RESTRICCIONES
client_id	[1..1]	Identificación del TPP	String[36] debe ser igual o estar vinculado al OrganizationIdentifier del Distinguished Name del certificado eIDAS, según la especificación ETSI
scope	[1..1]	Especifica las acreditaciones genéricas acordadas por el PSU y el TPP: - Para AISP `o` aisp `o` extended_transaction_history - para CBPII `o` cbpii	String[140] Lista de roles separada por espacios. Obligatorio
login_hint_token	[0..1]	Un token que contiene información que identifica al usuario final para el que se emitió el token. Esta información también puede incluir el contexto de uso específico si es necesario. Los detalles particulares y los requisitos de seguridad de este elemento, así como la forma en que el usuario final se identifica por su contenido, son específicos de cada ASPSP que implemente esta funcionalidad. Este token se habría recuperado mediante una solicitud de token introspection (cf.§ 3.4.2.7)	String [2048]
id_token_hint	[0..1]	Un ID token emitido previamente al cliente en caso de que el ASPSP haya implementado la extensión OpenID connect a OAuth2.	String[36]
login_hint	[0..1]	Pista para el servidor de autorización sobre el identificador de inicio de sesión que el usuario final podría utilizar para conectarse (si es necesario).	String[36]
binding_message	[0..1]	Un identificador o mensaje legible por humanos destinado a mostrarse al usuario final.	String [140]
ui_locales	[0..1]	Idiomas y scripts preferidos del usuario final para la interfaz de usuario.	String [140] Idiomas y scripts preferidos del usuario final para la interfaz de usuario, representados como una lista separada por espacios [RFC 5646]

El ASPSP

Identifica y autentica al TPP mediante el certificado eIDAS presentado (QWAC)
- Comprueba la correspondencia directa o indirecta entre el número de autorización del certificado eIDAS y el valor de [client_id] proporcionado por el JWT
Calcula las comprobaciones pertinentes sobre el TPP (roles, validez, no revocación…)
Identifica al PSU y comprueba si puede utilizarse un canal desacoplado

Authorization Response

En caso de validación correcta de la solicitud, el ASPSP responde al TPP mediante una respuesta HTTP200 (OK) que incluye los datos siguientes.

NOMBRE		DATO
auth_req_id	[1..1]	Identificador único de la solicitud de autorización.	String[36]
expires_in	[1..1]	Tiempo de expiración en segundos del identificador de la solicitud de autorización	Number
interval	[0..1]	Tiempo mínimo en segundos que el TPP debe esperar entre solicitudes de polling.	Number

Mientras tanto, el ASPSP contacta con el PSU por el canal desacoplado correspondiente, muestra el contenido de la solicitud de autorización y pide una confirmación mediante una autenticación.

Access Token Request

El TPP puede entonces consultar (poll) el token endpoint con el intervalo proporcionado por la authorization response.

POST /token HTTP/1.1 Host: as.example.com client_id= &grant_type= &auth_req_id=

NOMBRE		DATO	TIPO Y RESTRICCIONES
client_id	[1..1]	Identificación del TPP	String[36] debe ser igual o estar vinculado a OrganizationIdentifier del Distinguished Name del certificado eIDAS, según la especificación ETSI
client_secret	[0..1]	El secreto de cliente	Como la autenticación del TPP cliente se proporciona mediante MTLS, este parámetro no es muy útil.
grant_type	[1..1]	Tipo de grant	Debe ser igual a «urn:openid:params:grant-type:ciba»
auth_req_id	[1..1]	Identificador único de la solicitud de autorización tal como se proporciona en la Authorization response	String [36]

Respuesta de token correcta

El ASPSP responde mediante una respuesta HTTP200 (OK) que incluye los datos siguientes.

NOMBRE		DATO	TIPO Y RESTRICCIONES
access_token	[1..1]	Token de acceso proporcionado por el ASPSP al TPP.	String[140]
token_type	[1..1]	Tipo del token de acceso proporcionado («Bearer» o «MAC»)	String[10] Debe valorarse con «Bearer»

NOMBRE		DATO	TIPO Y RESTRICCIONES
expires_in	[0..1]	Duración de vida del token, en segundos. El token puede utilizarse varias veces mientras no esté expirado.	Numeric
refresh_token	[0..1]	Refresh token que puede utilizarse para una futura solicitud de renovación de token.	String[140]

Respuesta de token con error

Además de los códigos de error ya especificados por la RFC6749, los valores siguientes también pueden utilizarse en el contexto de una respuesta HTTP400.

CÓDIGO DE ERROR	DESCRIPCIÓN
authorization_pending	La solicitud de autorización sigue pendiente, ya que el usuario final (PSU) aún no ha sido autenticado. Respetando el intervalo de polling especificado, el TPP deberá repetir la solicitud de token.
slow_down	La solicitud de autorización sigue pendiente, ya que el usuario final (PSU) aún no ha sido autenticado y el TPP deberá repetir la solicitud de token. No obstante, el intervalo de polling debe aumentarse al menos 5 segundos para esta próxima solicitud y todas las siguientes.
expired_token	El identificador de la solicitud de autorización ha expirado. El TPP deberá realizar una nueva solicitud de autorización
access_denied	el usuario final (PSU) denegó la solicitud de autorización

3.4.2.6. OAuth2 Client Credentials Flow

El registro del TPP por parte del ASPSP se basa en una secuencia OAuth2 para obtener un token Client Credential grant (cf. https://tools.ietf.org/html/rfc6749#section-4.4).

Este tipo de token, según la implementación del ASPSP:

puede utilizarse para el caso de uso CBPII;
puede utilizarse para el caso de uso de confirmación PISP (enfoque REDIRECT básico);
- debe utilizarse para todos los demás casos de uso PISP.

Este procedimiento puede resumirse en los siguientes pasos.

Access Token Request

El TPP envía directamente, mediante una solicitud POST, su solicitud de token de acceso a la infraestructura de autorización del ASPSP con el patrón de URL y los parámetros siguientes

POST /token Host: authorization-server.com grant_type=client_credentials &scope= &client_id=

NOMBRE		DATO	DATO	TIPO Y RESTRICCIONES
grant_type	[1..1]	Tipo de autorización solicitado		String[36] Debe valorarse con «client_credentials»
scope	[0..1]	Especifica las acreditaciones genéricas acordadas por el PSU y el TPP: PISP.	String[140] Lista de roles separada por espacios. El valor por defecto es «pisp»
client_id	[1..1]	Identificación del TPP	String[36] debe ser igual o estar vinculado al OrganizationIdentifier del Distinguished Name del certificado eIDAS, según la especificación ETSI
client_secret	[0..1]	El secreto de cliente	Como la autenticación del TPP cliente se proporciona mediante MTLS, este parámetro no es muy útil.

El ASPSP

Identifica y autentica al TPP mediante el certificado eIDAS presentado (QWAC)
Comprueba la correspondencia, directa o indirecta, entre el número de autorización del certificado eIDAS y el valor de [client_id].
Calcula las comprobaciones pertinentes sobre el TPP (roles, validez, no revocación…)

Access Token Response

El ASPSP responde mediante una respuesta HTTP200 (OK) que incluye los datos siguientes.

NOMBRE		DATO
access_token	[1..1]	Token de acceso proporcionado por el ASPSP al TPP.	String[140]
token_type	[1..1]	Tipo del token de acceso proporcionado («Bearer» o «MAC»)	String[10] Debe valorarse con «Bearer»
expires_in	[0..1]	Duración de vida del token, en segundos. El token puede utilizarse varias veces mientras no esté expirado.	Numeric

3.4.2.7. OAuth2 Token introspection

La RFC 7662 (cf. https://tools.ietf.org/html/rfc7662) especifica cómo proporcionar metainformación sobre un token determinado.

Corresponde a cada ASPSP implementar esta funcionalidad si es necesario.

Introspection Request

Para obtener la metainformación sobre un token determinado, el TPP invocará, mediante una solicitud POST utilizando su certificado eIDAS, la infraestructura de autorización del ASPSP con los parámetros siguientes.

POST /introspect HTTP/1.1 Host: server.example.com token= &token_type_hint=

NOMBRE		DATO	TIPO Y RESTRICCIONES
Token	[1..1]	Valor de cadena del token	String[144]
token_type_hint	[0..1]	Tipo del token tal como se define	Debe valorarse con «refresh_token» o con «access_token»
client_id	[1..1]	Identificación del TPP	String[36] debe ser igual o estar vinculado a OrganizationIdentifier del Distinguished Name del certificado eIDAS, según la especificación ETSI
client_secret	[0..1]	El secreto de cliente	Como la autenticación del cliente TPP se proporciona mediante MTLS, este parámetro no es muy útil.

El ASPSP
- Identifica y autentica al TPP mediante el certificado eIDAS presentado (QWAC)

Comprueba la correspondencia directa o indirecta del valor de [token] con el número de autorización situado en el certificado eIDAS del TPP (QWAC).
obtiene el token correspondiente y su metainformación para construir la respuesta.

Introspection Response

El ASPSP responde con un objeto JSON con los elementos siguientes sugeridos tal como los especifica la RFC:

NOMBRE		DATO	TIPO Y RESTRICCIONES
Active	[1..1]	Indicador booleano de si el token presentado está actualmente activo o no.	«true» o «false»
Scope	[0..1]	Lista separada por espacios de los scopes asociados a este token	String[140] Lista de roles separada por espacios.
client_id	[0..1]	Identificador de cliente del cliente OAuth 2.0 que solicitó este token.	String[36] debe ser igual o estar vinculado al OrganizationIdentifier del Distinguished Name del certificado eIDAS, según la especificación ETSI
token_type	[0..1]	Tipo del token de acceso proporcionado («Bearer» o «MAC»)	String[10] Debe valorarse con «Bearer» para los tokens de acceso. El valor es irrelevante para los refresh tokens.
Exp	[0..1]	Timestamp entero, medido en número de segundos desde el 1 de enero de 1970 UTC, que indica cuándo expirará este token.	Integer Este campo DEBE proporcionarse
Iat	[0..1]	Timestamp entero, medido en número de segundos desde el 1 de enero de 1970 UTC, que indica cuándo se emitió originalmente este token	Integer Este campo puede proporcionarse

La especificación de la API STET sugiere proporcionar otro elemento específico definido de la siguiente manera:

NOMBRE	DATO	TIPO Y RESTRICCIONES
login_hint_token	Un token que contiene información que identifica al usuario final para el que el token fue emitido. Esta información también puede incluir el contexto de uso específico si es necesario. Los detalles particulares y los requisitos de seguridad de este elemento, así como la forma en que el usuario final se identifica por su contenido, son específicos de cada ASPSP que implemente esta funcionalidad.	String [2048]

El [login_hint_token] puede utilizarse después por el TPP para volver a dar una pista sobre la identidad y el contexto de uso del PSU, en particular:

durante un nuevo OAuth2 Authorisation Code Grant (cf. § 3.4.2.3) o su equivalente OpenID connect (cf. § 3.4.2.4)
durante una nueva Client Initiated Backchannel Authentication (cf. § 3.4.2.5)
durante el envío de una solicitud de pago (a través de los datos suplementarios del payload).

3.4.2.8. Uso del token de acceso

El token de acceso debe utilizarse en cada solicitud dentro de la cabecera «Authorization», precedido por el tipo de token «Bearer».

El [client_id] vinculado al token de acceso debe corresponder directa o indirectamente con el

número de autorización situado en el certificado eIDAS del TPP (QWAC).

Si el token de acceso ha expirado, la solicitud se rechazará con un HTTP401 y un error igual a

«invalid_token» y la solicitud podrá repetirse una vez refrescado el token de acceso.

Si el scope del token de acceso no puede cubrir la solicitud (caso de una solicitud de historial de transacciones extendido, por ejemplo):

la solicitud se rechazará con un HTTP403 y un error igual a «insufficient_scope»
el refresh token será revocado para que la solicitud pueda repetirse una vez que se haya solicitado y proporcionado un nuevo token con el scope adecuado.

3.4.2.9. Refresco del token de acceso

El refresco del token de acceso solo es posible cuando el token de acceso se concedió a través de un OAuth2 «Authorization Code», OpenID Connect o «Client Initiated Backchannel Authentication» Grants.

Según la RFC 6749 (cf. https://tools.ietf.org/html/rfc6749#section-6), el Refresh Token puede ser utilizado por el TPP para obtener un token de acceso refrescado mediante la siguiente solicitud.

POST /token HTTP/1.1

Host: server.example.com grant_type=refresh_token &client_id= &refresh_token=tGzv3JOkF0XG5Qx2TlKWIA &scope=

NOMBRE		DATO	TIPO Y RESTRICCIONES
grant_type	[1..1]		Debe valorarse con «refresh_token»
refresh_token	[1..1]	Valor del refresh token proporcionado
client_id	[1..1]	Identificación del TPP	String[36] debe ser igual o estar vinculado a OrganizationIdentifier del Distinguished Name del certificado eIDAS, según la especificación ETSI
client_secret	[0..1]	El secreto de cliente	Como la autenticación del cliente TPP se proporciona mediante MTLS, este parámetro no es muy útil.
scope	[0..1]	Especifica las acreditaciones genéricas acordadas por el PSU y el TPP: «aisp» o «cbpii». «extended_transaction_history» no está permitido en este caso.	String[140] Lista de roles separada por espacios.

El ASPSP
- Identifica y autentica al TPP mediante el certificado eIDAS presentado (QWAC)
- Comprueba la correspondencia directa o indirecta entre el número de autorización del certificado eIDAS y el valor de [client_id].
El ASPSP responde mediante una respuesta HTTP200 (OK) que incluye los datos siguientes.

NOMBRE		DATO
access_token	[1..1]	Token de acceso proporcionado por el ASPSP al TPP.	String[140]
token_type	[1..1]	Tipo del token de acceso proporcionado («Bearer» o «MAC»)	String[10] Debe valorarse con «Bearer»
expires_in	[0..1]	Duración de vida del token, en segundos. El token puede utilizarse varias veces mientras no esté expirado.	Numeric
refresh_token	[0..1]	Refresh token que puede reemplazar el refresh token anterior.	String[140]

Si el refresh token ha sido revocado, la solicitud se rechazará con un HTTP400 y un error igual a «invalid grant».

3.4.2.10. Revocación del refresh token

El refresh token proporcionado a un AISP queda de facto revocado por el ASPSP

Tras la expiración del plazo legal especificado entre dos SCA.
Tras la expiración del plazo especificado por el ASPSP sobre la base de reglas internas, si las hubiera.
Tras el rechazo de una solicitud por scope insuficiente, para permitir al AISP solicitar otro token con el scope deseado.
A petición de un PSU que desee revocar el acceso del TPP a los datos de su cuenta.

El TPP también puede solicitar la revocación del refresh token, según la RFC 7009 (cf.

https://tools.ietf.org/html/rfc7009) mediante la siguiente solicitud.

POST /revoke HTTP/1.1 Host: server.example.com token=45ghiukldjahdnhzdauz &token_type_hint=refresh_token &client_id=

NOMBRE		DATO	TIPO Y RESTRICCIONES
token	[1..1]	Token que debe revocar el ASPSP.	String[140]
token_type_hint	[0..1]	Información sobre el tipo de token que se debe revocar	Debe valorarse con «refresh_token»
client_id	[1..1]	Identificación del TPP	String[36] debe ser igual o estar vinculado a OrganizationIdentifier del Distinguished Name del certificado eIDAS, según la especificación ETSI
client_secret	[0..1]	El secreto de cliente	Como la autenticación del cliente TPP se proporciona mediante MTLS, este parámetro no es muy útil.

El ASPSP
- Identifica y autentica al TPP mediante el certificado eIDAS presentado (QWAC)
- Comprueba la correspondencia directa o indirecta del valor de [client_id] con el número de autorización situado en el certificado eIDAS del TPP (QWAC).
- Revoca el refresh token

3.4.2.11. OAuth2 para aplicaciones nativas

La RFC 8252 (https://tools.ietf.org/html/rfc8252) amplía el uso de la OAuth Authorization request a las aplicaciones instaladas en un dispositivo determinado (p. ej. un smartphone).

Sobre la base de esta RFC, podría considerarse un proceso de autorización directo (straight through) utilizando

Universal Link (dispositivos iOS)
App Link (dispositivos Android)

No obstante, la especificación de la API no impone este mecanismo.

3.4.3. Niveles de autorización AISP

Como un TPP actúa por cuenta de un PSU que es un PAO, los casos de uso PSD2 ligados al rol AISP requieren los siguientes niveles de autorización:

Autorización por rol
Autorización por acuerdo TPP-PSU
Autorización por contexto PSU

3.4.3.1. Lista de los ASPSP correspondientes

Cuando contrata con un TPP, el PSU proporcionará una lista de los ASPSP a los que autoriza el acceso del TPP.

Esta lista puede no ser exhaustiva y, por tanto, no incluir algunos de los ASPSP del PSU.

3.4.3.2. Registro del acuerdo TPP-PSU por cada ASPSP

Este registro tiene como fin permitir el acceso posterior del TPP a los datos del PSU alojados por un ASPSP determinado, proporcionando al TPP un token de acceso OAuth2.

El token de acceso puede obtenerse mediante uno de los siguientes Grants:

OAuth2 Authorization Code grant (enfoque REDIRECT)
- Este grant puede enriquecerse con los siguientes parámetros adicionales tomados de OpenID Connect:
  - [login_hint]
  - [ui_locales]
OpenID Connect Grant (enfoque REDIRECT)
Client Initiated Backchannel Authentication Grant (enfoque DESACOPLADO)

Cada ASPSP deberá documentar su propia elección sobre este tema.

3.4.3.3. Scopes OAuth2 AISP

Se solicita que los roles AISP, CBPII o PISP no se mezclen dentro de una misma definición de scope en una solicitud de token de acceso OAuth2.

El scope OAuth2 solicitado por un AISP puede ser uno de los siguientes valores:

«aisp»
«aisp extended_transaction_history»

El primer valor de scope permite al AISP acceder a todas las cuentas accesibles y datos autorizados por el PSU hasta la expiración del plazo legal especificado entre dos SCA. No obstante, este valor no permite solicitar un historial de transacciones extendido, es decir, un historial que incluya transacciones de más de 90 días.

El segundo valor de scope permite al AISP acceder a todas las cuentas accesibles y datos autorizados por el PSU hasta la expiración del plazo legal especificado entre dos SCA. También permite solicitar un historial de transacciones extendido.

No obstante, este scope «aisp extended_transaction_history» será restringido a «aisp» por el ASPSP durante el primer refresco de token. Así:

El AISP podrá solicitar un historial de transacciones extendido con el primer token de acceso obtenido tras una solicitud de token. Así, en este caso, se requerirá y utilizará una única SCA para obtener el token y solicitar un historial de transacciones extendido.
Cualquier solicitud posterior de historial de transacciones extendido se considerará fuera de scope (cf. §3.4.2)

3.4.3.4. Consentimiento detallado del PSU

El consentimiento detallado del PSU especificará qué cuenta o qué funcionalidad será accesible para el AISP. Puede verse como un conjunto de acreditaciones individuales.

Este conjunto es específico de un PSU determinado, un TPP determinado y un ASPSP determinado.

Cada acreditación individual se basa en una cuenta específica que pertenece al PSU y es mantenida por el ASPSP. Especifica qué datos (transacciones, saldos) está autorizado el TPP a tratar sobre esta cuenta.

El PSU gestiona este contexto con el AISP, que es responsable de:

‒ La captura de las decisiones del PSU:

El PSU especifica al AISP a qué cuenta y funcionalidad debe accederse o no.
La ejecución de las decisiones del PSU:
- El AISP tiene la responsabilidad de respetar las decisiones del PSU y de no acceder a ninguna funcionalidad para la que no haya sido habilitado.

En cualquier momento, el PSU puede modificar sus decisiones de consentimiento, pero esto solo puede hacerse con el AISP.

Además, el consentimiento del PSU puede o no ser transmitido por el AISP al ASPSP, según uno de los dos modelos de gestión del consentimiento siguientes.

Modelo Full-AISP (A1)

En este modelo, el ASPSP no exige ser informado de los detalles del consentimiento del PSU.

Sea cual sea la solicitud del AISP, el ASPSP responderá, sin poder comprobar la conformidad de la solicitud con las decisiones del PSU.

En efecto, cuando obtiene el contexto PSU del ASPSP (mediante la llamada [get /accounts]), el AISP obtendrá todos los enlaces HAL e identificadores de recurso pertinentes para cada cuenta elegible.

Estos enlaces HAL ayudarán al AISP a solicitar las funcionalidades necesarias sobre esas cuentas: saldos y/o transacciones.

Modelo mixto (A2)

En este modelo, el ASPSP exige ser informado de los detalles del consentimiento del PSU. Por tanto, el ASPSP ha implementado un punto de entrada de API ad-hoc que puede ser invocado por el AISP para transmitir las decisiones del PSU.

En efecto, cuando obtiene el contexto PSU del ASPSP (mediante la llamada [get /accounts]), el AISP obtendrá todas las cuentas elegibles, pero los enlaces HAL e identificadores de recurso solo se proporcionarán para las cuentas sobre las que el PSU dio su consentimiento.

Estos enlaces HAL ayudarán al AISP a solicitar las funcionalidades necesarias sobre esas cuentas: saldos y/o transacciones.

Elección del modelo

Corresponde al ASPSP implementar o no el modelo mixto (A2). No obstante, si este modelo ha sido implementado por el ASPSP, corresponde al AISP transmitir los detalles del consentimiento del PSU al ASPSP cada vez que el PSU da o modifica este consentimiento.

Una vez que los detalles del consentimiento del PSU han sido recibidos y guardados por el ASPSP, el AISP, cuando obtiene el contexto PSU del ASPSP (mediante la llamada [get /accounts]), solo obtendrá enlaces HAL para las cuentas y funcionalidades autorizadas.

3.4.4. Niveles de autorización CBPII

Como un CBPII actúa por cuenta de un PSU que es un PAO, los casos de uso PSD2 ligados a los roles AISP y CBPII requieren los siguientes niveles de autorización:

Autorización por rol
Autorización por acuerdo TPP-PSU
Autorización por contexto PSU

No obstante, en algunos casos, el CBPII puede haber sido inscrito previamente por el PSU ante el ASPSP correspondiente (cf. §3.4.4.3).

3.4.4.1. Lista de los ASPSP correspondientes

Cuando contrata con un TPP, el PSU proporcionará una lista de los ASPSP a los que autoriza el acceso del TPP. Esta lista puede no ser exhaustiva y, por tanto, no incluir algunos de los ASPSP del PSU.

3.4.4.2. Registro del acuerdo TPP-PSU por cada ASPSP

Este registro tiene como fin permitir el acceso posterior del TPP a los datos del PSU alojados por un ASPSP determinado, proporcionando al TPP un token de acceso OAuth2.

El token de acceso puede obtenerse:

Bien mediante un flujo OAuth2 Authorization Code (enfoque REDIRECT)
OpenID Connect Grant (enfoque REDIRECT)
Client Initiated Backchannel Authentication Grant (enfoque DESACOPLADO)

3.4.4.3. Nivel de autorización CBPII preinscrito

Cuando el PSU ha inscrito previamente al CBPII ante su ASPSP correspondiente, este último puede preferir aplicar un esquema de autorización más simple.

El token de acceso puede obtenerse entonces mediante un flujo OAuth2 Client Credentials, ya que la autenticación del PSU es innecesaria puesto que el consentimiento del PSU ya fue capturado.

3.4.4.4. Scope CBPII

Se solicita que los roles AISP y CBPII no se mezclen dentro de una misma definición de scope en una solicitud de token de acceso OAuth2.

El scope OAuth2 solicitado por un CBPII solo puede ser «cbpii».

3.4.5. Niveles de autorización PISP y gestión del fraude

3.4.5.1. Casos de uso

Publicar y obtener una solicitud de pago/transferencia

Para publicar u obtener una solicitud de pago por cuenta de un Comercio, o una solicitud de transferencia por cuenta de un Ordenante, el PISP puede utilizar un token de acceso que puede obtenerse del ASPSP mediante un flujo OAuth2 Client Credentials.

No obstante, la ejecución de la solicitud de pago requiere una confirmación:

por parte del PSU mediante una autenticación adecuada
por parte del propio PISP tras completar su análisis de riesgo de fraude.

En esta perspectiva, durante la publicación de la solicitud de pago, el PISP deberá sugerir

los enfoques de autenticación que admite. El ASPSP responderá entonces con el enfoque de autenticación elegido completado y la URL que debe utilizarse para iniciar la autenticación del PSU.

Confirmación de una solicitud de pago

Esta autenticación debe ser reforzada, salvo casos de exención, y puede realizarse mediante un enfoque ENFORCED REDIRECT o DESACOPLADO (cf. infra).

Una vez que el PSU ha confirmado la solicitud de pago al ASPSP mediante esta autenticación, el PISP obtendrá un token de acceso. El PISP debe utilizar este token de acceso para su propia confirmación de la solicitud de pago después de haber comprobado, por ejemplo, la ausencia de un posible fallo de seguridad.

Cancelación de una solicitud de pago

En caso de que el PISP deba cancelar una solicitud de pago, el token de acceso que debe utilizarse puede obtenerse del ASPSP mediante un flujo OAuth2 Client Credentials.

No obstante, el ASPSP puede exigir una confirmación mediante una autenticación del PSU. Esta autenticación puede realizarse mediante un enfoque SIMPLE REDIRECT o DESACOPLADO (cf. infra).

En esta perspectiva, durante la solicitud de cancelación, el PISP deberá sugerir los enfoques de autenticación que admite. El ASPSP responderá entonces:

bien con la decisión de no tratar la autenticación del PSU; la cancelación es entonces efectiva
bien con el enfoque de autenticación elegido completado con la URL que debe utilizarse para iniciar la autenticación del PSU; la cancelación será efectiva tras esta autenticación del PSU.

3.4.5.2. Enfoque SIMPLE REDIRECT

Este enfoque solo puede utilizarse para una cancelación de solicitud de pago.

La autenticación del PSU se trata entonces mediante una simple redirección del PSU al servidor de autenticación del ASPSP utilizando la URL inicialmente proporcionada por el ASPSP.

El ASPSP autentica al PSU y luego redirige a este último utilizando una de las URL de call-back proporcionadas por el PISP.

3.4.5.3. Enfoque ENFORCED REDIRECT

Este enfoque es obligatorio para una confirmación de solicitud de pago en enfoque REDIRECT.

Se utilizará un token Authorization Code para la confirmación. La autenticación del PSU se trata mediante el flujo Authorization Code con el servidor de autenticación del ASPSP.

Objetivo y análisis de riesgo

La iniciación de pago puede, en efecto, enfrentarse a ciertos problemas de seguridad en el enfoque REDIRECT.

Un primer ataque (fijación de sesión) podría producirse, basándose en el hecho de que un PSU determinado transmitirá la solicitud de redirección a otro PSU que podría estar en condiciones de autenticarse y pagar la compra realizada por el primer PSU.

Además, aunque el primer ataque se mitigue, el atacante también podría intentar simular la redirección (falsa redirección) hacia el TPP para inducir la confirmación de la solicitud de pago ante el ASPSP.

Protección contra la fijación de sesión

Para evitar el ataque por fijación de sesión, el PISP debe asegurarse de que no haya «PSU-switch» durante la redirección. Esto puede hacerse gestionando un nonce que

se almacenará en la sesión del user agent del PSU antes de la redirección al ASPSP y
- se recuperará del user agent del PSU después de la redirección.

En caso de fallo de la recuperación, hay muchas probabilidades de que se haya producido tal ataque. El PISP debería entonces cancelar la solicitud de pago por motivo de fraude.

De lo contrario, en caso de recuperación correcta del nonce, el PISP puede confirmar la solicitud de pago al ASPSP, que está entonces en condiciones de activar las transferencias correspondientes.

Protección contra la falsa redirección

Para publicar la confirmación, el PISP debe solicitar un token Authorization Code al ASPSP.

En respuesta a la solicitud de pago, el ASPSP ha proporcionado al PISP el URI del

servidor de autorización. Algunos parámetros OAuth2 deben haber sido pre-valorados:

[response_type] valorado con «code»
[scope] valorado con «pisp»
[context] valorado con una pista hacia la solicitud de pago

El PISP completará esta URL con sus propios parámetros OAuth2

[client_id]
[state] si es necesario
[redirect_uri] como URL de call-back.

El OAuth2 Authorization Code grant puede entonces completarse (cf. §3.4.2.3).

Tras la recuperación del Authorization Code mediante la redirección del PSU de vuelta al PISP, este último debe entonces asegurarse, mediante el mecanismo de comprobación del nonce, de que no haya habido «PSU-switch» durante la redirección, como se explicó anteriormente.

El PISP puede entonces intercambiar el Authorization Code por el token de acceso.

la duración de vida del token de acceso es especificada por el servidor de autorización para limitar el período de usabilidad.
no debe proporcionarse ningún refresh token.

La confirmación se publica entonces, utilizando este token de acceso.

En caso de ataque por falsa redirección, el token de acceso no habría podido ser recuperado por el PISP. Incluso en el intento de confirmación, el ASPSP puede detectar la ausencia del token y rechazará entonces la solicitud de pago por motivo de FRAUDE.

De lo contrario, la confirmación enviada por el PISP conducirá a la activación normal de las transferencias correspondientes.

3.4.5.4. Enfoque OAuth2 DESACOPLADO

En este enfoque, el token Client Credential puede utilizarse para todos los casos de uso PISP:

Publicar una solicitud de pago
Obtener la solicitud de pago publicada previamente
Modificar para cancelación la solicitud de pago
Confirmar la solicitud de pago

La autenticación del PSU se trata mediante un canal desacoplado iniciado por el ASPSP.

Tras la autenticación del PSU, el PISP es informado mediante una llamada directa del ASPSP. El PISP puede entonces confirmar la solicitud de pago, lo que conducirá a la activación normal de las transferencias correspondientes.

3.4.5.5. Tabla recapitulativa

	SIMPLE REDIRECT	ENFORCED REDIRECT	DECOUPLED
Protección por mecanismo de nonce aplicada por el PISP	El nonce debe ser calculado por el PISP y almacenado en el user-agent del PSU siempre que el PISP acepte los enfoques Simple REDIRECT o Enforced REDIRECT al publicar o cancelar una solicitud de pago.

	SIMPLE REDIRECT	ENFORCED REDIRECT	DECOUPLED
Successful y Unsuccessful Report Uri proporcionados por el PISP	Para ser utilizados por el ASPSP mediante la redirección del PSU		Para ser utilizados directamente por el ASPSP tras la autenticación del PSU
Enfoque de autenticación aceptado fijado por el PISP	Debe incluir «REDIRECT»		Debe incluir «DECOUPLED»
Enfoque de autenticación aplicado fijado por el ASPSP	«REDIRECT»		«DECOUPLED»
Autenticación del PSU	Para la confirmación de una cancelación	Para la confirmación de una solicitud de pago

3.5. Autenticación aplicativa

Cada solicitud enviada por el TPP debe firmarse y el ASPSP también puede firmar sus respuestas.

Si el ASPSP constata que la firma está ausente o es inválida para una solicitud determinada, debe rechazar esta solicitud con un HTTP400.

Si el TPP constata que la firma es inválida para una respuesta determinada, debe advertir al ASPSP correspondiente.

3.5.1. Mecanismo Http-Signature

El mecanismo http-signature está especificado por el siguiente draft IETF:

https://datatracker.ietf.org/doc/draft cavage http signatures/

Cabe señalar que este draft IETF ha sido reemplazado ahora por un nuevo draft:

https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/

No obstante, dado que OpenBankingEurope y ETSI, junto con varias iniciativas de API PSD2 incluida STET, publicaron un nuevo estándar de firma, se aconseja encarecidamente considerar reemplazar http-signature por este nuevo estándar de firma (cf. 3.5.2).

3.5.1.1. Cálculo de la firma

La forma en que debería implementarse es la siguiente

Calcular un digest SHA256 del cuerpo HTTP y añadir este digest como cabecera HTTP adicional.

Utilizar un certificado cualificado específico (QSealC), respetando la especificación técnica ETSI/TS119495, para aplicar una firma RSA-SHA256 sobre
- todas las siguientes cabeceras presentes en la solicitud HTTP enviada por el TPP, incluido el digest calculado previamente
  - Date (si está disponible)
  - Content-Type (cuando hay un payload)
  - Content-Length (cuando hay un payload)
  - X-Request-Id
  - Todas las cabeceras con prefijo «PSU» disponibles (cf. § 3.5.2)
  - el pseudo-encabezado específico «(request-target)» especificado por el draft IETF
- todas las siguientes cabeceras presentes en la respuesta HTTP proporcionada por el ASPSP, incluido el digest calculado previamente
  - Date (si está disponible)
  - Content-Type (cuando hay un payload)
  - Content-Length (si está disponible)
  - X-Request-Id
Añadir esta firma en una cabecera HTTP adicional que incluye
- El identificador de clave, que debe especificar la forma de obtener el certificado cualificado correspondiente (véase más abajo)
- El algoritmo que se ha utilizado
- La lista de cabeceras que se han firmado
- La firma propiamente dicha.

Desde la versión #11 del draft, se han introducido dos nuevos pseudo-encabezados para

reforzar la firma: (created) y (expires). No obstante, el trabajo sobre este tema sigue en curso y el uso de estos dos campos aún no se recomienda.

CABECERA HTTP ADICIONAL	DATO	COMENTARIO
Digest	Digest del cuerpo
Signature	http-signature de la solicitud (cf. https://datatracker.ietf.org/doc/draft-cavage-http- signatures/)

3.5.1.2. Valor del identificador de clave

Se solicita que este identificador se valore con:

Bien el keyId que ha sido asignado por el servidor de autorización durante la configuración técnica OAuth2 (cf. § 3.4.2.2).
Bien una URL destinada a proporcionar el certificado cualificado correspondiente.
- Para asegurar una fácil discriminación del certificado entre otros, se solicita que la última parte de la URL al certificado se sufije con un guion bajo seguido de la huella SHA-256 del certificado.
  - P. ej.: https://path.to/myQsealCertificate_714f8154ec259ac40b8a9786c9908 488b2582b68b17e865fede4636d726b709f
- Esta URL podría haberse proporcionado durante la configuración técnica OAuth2 dentro del campo «5xu» del JKS proporcionado por el TPP (cf. RFC7517).

3.5.2. JSON Web Signature Profile for Open Banking

Este mecanismo de firma está especificado por el siguiente documento:

https://www.openbankingeurope.eu/media/2095/obe-json-web-signature-profile-foropen-banking.pdf

Se basa en el uso de una Json Web Signature (JWS tal como la especifica la RFC7515).

La forma en que debería implementarse es la siguiente

Elegir un certificado cualificado (QSealC), respetando la especificación técnica ETSI/TS119495 y perteneciente al emisor de la solicitud o de la respuesta como certificado de firma.
Elegir un algoritmo de firma entre los enumerados tanto en la RFC7518 como en la ETSI TS 119 312, aunque se recomienda encarecidamente una revisión periódica de las posibles debilidades de estos algoritmos.
Calcular un digest SHA256 del cuerpo HTTP y añadir este digest como cabecera HTTP adicional.
Construir un JWS protected header cuyo
- campo [sigD/pars] enumerará todos los campos de cabecera HTTP en minúsculas que deben firmarse (véase más abajo) y codificarlo en Base64url.
- campo [x5t#S256] se valorará con el hash codificado en Base64url del certificado de firma elegido previamente
- campo [alg] se valorará con el nombre del algoritmo de firma
- Construir la cadena de cabeceras HTTP como la lista de todas las cabeceras/valores que deben firmarse.
o todas las siguientes cabeceras presentes en la solicitud HTTP enviada por el TPP, incluido el digest calculado previamente
- Date (si está disponible)
- Content-Type (cuando hay un payload)

Content-Length (cuando hay un payload)
X-Request-Id
Todas las cabeceras con prefijo «PSU» disponibles (cf. § 3.5.2)
el pseudo-encabezado específico «(request-target)» especificado por el draft IETF
todas las siguientes cabeceras presentes en la respuesta HTTP proporcionada por el ASPSP, incluido el digest calculado previamente
- Date (si está disponible)
- Content-Type (cuando hay un payload)
- Content-Length (si está disponible)
- X-Request-Id
Concatenar el JWS protected header codificado en Base64url y la cadena de cabeceras HTTP con un punto («.») como separador.
Calcular la firma, utilizando el certificado y el algoritmo elegidos, sobre el resultado de la concatenación anterior.
Concatenar el JWS protected header codificado en Base64url y la firma resultante con un doble punto («..») como separador

Añadir el resultado de la concatenación anterior como cabecera HTTP adicional «x-jws-signature»

3.6. Información orientada a la detección de fraude

Las siguientes cabeceras HTTP adicionales deben utilizarse en la solicitud HTTP enviada por el TPP, siempre que los datos correspondientes estén disponibles en la conexión entre el PSU y el TPP. Esta transmisión permite al ASPSP integrar esta información en su propio proceso de detección de fraude.

Además, estas cabeceras pueden considerarse como prueba de la conexión del PSU.

CABECERA HTTP ADICIONAL	DATO	COMENTARIO
PSU-IP-Address	Dirección IP del terminal del PSU al conectarse al TPP	Conforme a las reglas del RGPD, esto debe estar sujeto al consentimiento del PSU
PSU-IP-Port	Puerto IP del terminal del PSU al conectarse al TPP
PSU-HTTP-Method	Método HTTP utilizado para la solicitud más relevante del terminal del PSU al TPP
PSU-Date	Marca de tiempo de la solicitud más relevante del terminal del PSU al TPP
PSU-User-Agent	Campo de cabecera «User-Agent» enviado por el terminal del PSU al conectarse al TPP
PSU-Referer	Campo de cabecera «Referer» enviado por el terminal del PSU al conectarse al TPP
PSU-Accept	Campo de cabecera «Accept» enviado por el terminal del PSU al conectarse al TPP
PSU-Accept-Charset	Campo de cabecera «Accept-Charset» enviado por el terminal del PSU al conectarse al TPP
PSU-Accept-Encoding	Campo de cabecera «Accept-Encoding» enviado por el terminal del PSU al conectarse al TPP
PSU-Accept-Language	Campo de cabecera «Accept-Language» enviado por el terminal del PSU al conectarse al TPP
PSU-GEO-Location	La geolocalización transmitida de la solicitud HTTP correspondiente entre PSU y TPP si está disponible.	Conforme a las reglas del RGPD, esto debe estar sujeto al consentimiento del PSU
`PSU-Device-ID`	UUID (Universally Unique Identifier) de un dispositivo utilizado por el PSU, si está disponible. El UUID identifica un dispositivo o una instalación de aplicación dependiente de un dispositivo. En caso de identificación de instalación, este ID debe permanecer inalterado hasta la eliminación del dispositivo.	Conforme a las reglas del RGPD, esto debe estar sujeto al consentimiento del PSU

3.7. Otras cabeceras HTTP específicas que deben utilizarse

CABECERA HTTP ADICIONAL	DATO		COMENTARIO
X-Request-ID	Cabecera de correlación que debe fijarse en una solicitud y recuperarse en la respuesta correspondiente.
Idempotency-Key	Clave de idempotencia que debe añadir el cliente de la API para garantizar que una solicitud determinada, cuando se reintenta dos o más veces, solo se ejecute una vez por el servidor de la API. Esto se aplica especialmente a las solicitudes POST.		Las reglas de unicidad, validez y expiración deben fijarse según: https://datatracker.ietf.org/doc/draft-ietf-httpapi- idempotency-key-header/

3.8. Códigos y mensajes de retorno HTTP específicos que deben utilizarse

MENSAJE	CÓDIGO HTTP	SIGNIFICADO
FORMAT_ERROR	400	El formato de ciertos campos de la solicitud no cumple los requisitos XS2A. Puede añadirse un path explícito al campo correspondiente en el mensaje de retorno.
RESOURCE_UNKNOWN	404	Si resourceId en el path
PERIOD_INVALID	400	Período de tiempo solicitado fuera de límites.

MENSAJE	CÓDIGO HTTP	SIGNIFICADO
ACCESS_EXCEEDED	429	El acceso a la cuenta ha superado la multiplicidad consentida por día.
REQUESTED_FORMATS _INVALID	406	Los formatos solicitados en la cabecera Accept no coinciden con los formatos ofrecidos por el ASPSP.

3.9. Resumen técnico de la API STET PSD2

TEMA	ELECCIÓN		COMENTARIO
Red de acceso	Internet
Protocolo de red	HTTP 1.1 (Mínimo)
Cifrado de datos Autenticación cruzada	TLS 1.2		Podría reforzarse mediante STS y/o PFS
Protocolo de autorización			Conforme a las RFC 6749, 7009 Uno de los siguientes modos de token - Authorization Code Grant (AISP, CBPII y PISP) para el enfoque REDIRECT - Client credential (PISP, CBPII) Sobre la base de MTLS, la identidad del TPP es proporcionada por su certificado eIDAS durante los procedimientos OAuth2. https://datatracker.ietf.org/doc/rfc8705/ La extensión OpenId Connect también puede utilizarse en lugar del Authorization Code Grant El Client Initiated Backchannel Authorization Grant puede utilizarse para implementar un enfoque DESACOPLADO



		OAuth2

Protocolo aplicativo	REST		Conforme al Richardson Maturity Model, en el nivel tres para proporcionar enlaces HYPERMEDIA.
Autenticación aplicativa	http-signature		Nótese que se trata en realidad de un
Enfoques de autenticación reforzada del cliente (PSU)	REDIRECT, DECOUPLED
Formato de datos	JSON/UTF8		Con uso de estructuras de datos basadas en ISO20022
Documentación técnica	SWAGGER 2.0		El formato Fecha/Hora debe respetar ISO8601 y RFC3339 conforme a las especificaciones OpenApi. El creador de una Fecha/Hora debe elegir - Cualquier formato de zona horaria, aunque se recomienda el formato UTC. - Cualquier formato de fracción de segundo, incluida la ausencia de fracción de segundo. Una fecha simple puede especificarse como una fecha/hora UTC con una parte de hora igual a «00:00:00Z». El destinatario de una Fecha/Hora debe poder interpretar su valor siempre que sea conforme a ISO8601 y RFC3339.