3. Pré-requisitos e detalhes técnicos

3.1. Registro dos atores

Os atores PSD2 devem ser registrados por uma autoridade de registro. As informações coletadas devem ser acessíveis aos demais atores a fim de proporcionar confiança e interoperabilidade.

Um ator não registrado não pode interagir com outro ator.

Cada ator deve dispor de pelo menos um certificado eIDAS (QWAC), para TLS 1.2, emitido por um prestador de serviços de confiança qualificado (QTSP) registrado.

A lista de QTSP da Comissão Europeia pode ser consultada na seguinte URL:

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

3.2. Autenticação cruzada e criptografia de dados

A API STET PSD2 baseia-se no protocolo TLS 1.2 para obter uma autenticação cruzada entre atores. Além disso, esse protocolo também garante a confidencialidade dos dados durante seu transporte na rede.

Sempre que um TPP se conecta como cliente a um serviço de API de um ASPSP, ele verifica o certificado de servidor do ASPSP (QWAC) e apresenta seu próprio certificado eIDAS (QWAC) respeitando a especificação técnica ETSI/TS119495.

A identificação da organização (Organizational Identification) dentro do Subject Distinguished Name do certificado deve, na verdade, ser considerada como um número de autorização (Authorization Number) que respeitará as seguintes regras de formato:

«PSD» como referência de tipo de identidade de pessoa jurídica de 3 caracteres;
código de país ISO 3166 [7] de 2 caracteres que representa o país da NCA;
hífen «-» (0x2D (ASCII), U+002D (UTF-8)); e
identificador de NCA de 2 a 8 caracteres (A-Z apenas maiúsculas, sem separador);
hífen «-» (0x2D (ASCII), U+002D (UTF-8)); e
identificador do PSP (número de autorização conforme especificado pela NCA).

Em caso de falha de autenticação, de um lado ou de outro, a conexão deve ser encerrada.

Nenhuma função adicional de criptografia ou autenticação é necessária.

3.3. Abordagens de autenticação do cliente

Três abordagens diferentes podem ser utilizadas por um TPP para permitir a autenticação do PSU pelo ASPSP. Essas abordagens baseiam-se em uma identificação do PSU que deve ser pertinente para o ASPSP (identificador nacional ou identificador de cliente do banco).

Essas abordagens são implementadas de diferentes maneiras, conforme o caso de uso correspondente:

seja durante o processo de autorização (cf. §3.4.2), principalmente para os casos de uso AISP e CBPII,
seja durante o processo de confirmação do consentimento, por exemplo no caso de um PISP que envia uma solicitação de pagamento (cf. § 3.4.2).

3.3.1. Abordagem por redirecionamento (Redirect)

Com a abordagem por redirecionamento, o processo de autenticação do PSU é totalmente tratado pelo ASPSP.

Para isso, o TPP deve redirecionar o PSU ao serviço de autenticação do ASPSP, o que significa que o PSU deixará temporariamente a interface do TPP para se autenticar na interface do ASPSP.

O TPP pode já ter capturado um identificador de PSU que o ASPSP possa utilizar para reconhecer inequivocamente o PSU. Nesse caso, esse identificador pode ser transmitido por meio do redirecionamento, quando o protocolo de redirecionamento permite a transmissão desse identificador.

Após a finalização da autenticação, o ASPSP redireciona o PSU de volta à interface do TPP.

3.3.2. Abordagem desacoplada (Decoupled)

Com a abordagem desacoplada, o processo de autenticação do PSU é totalmente tratado pelo ASPSP.

Para isso, o TPP deve capturar um identificador de PSU que o ASPSP possa utilizar para reconhecer inequivocamente o PSU, e transmitir esse identificador ao ASPSP.

Com base nesse identificador, o ASPSP acionará uma autenticação por meio de um dispositivo ou de um aplicativo desacoplado, o que significa que o PSU não deixará a interface do TPP durante o processo de autenticação.

3.3.3. Isenções à autenticação forte do cliente

As isenções à autenticação forte do cliente são especificadas pelas RTS da EBA sobre SCA, em particular para os serviços de iniciação de pagamento.

Nesse contexto, a API permite ao PISP transmitir ao ASPSP qualquer informação útil.

Além disso, o PISP também pode sugerir ao ASPSP se a solicitação de pagamento correspondente poderia ou não ser objeto de uma isenção.

Em última instância, o ASPSP mantém a decisão final de aplicar ou não essa isenção.

3.4. Autorização

3.4.1. Níveis de autorização

Os seguintes níveis de autorização podem ser verificados e combinados para calcular os direitos efetivos concedidos ao TPP:

NÍVEL DE AUTORIZAÇÃO	DESCRIÇÃO
Autorização por papel do TPP	Uma vez que o TPP tenha sido registrado para um determinado papel, ele pode invocar qualquer funcionalidade PSD2 fornecida por um ASPSP por meio da API STET PSD2 para esse papel.
Autorização por acordo TPP-ASPSP	O TPP pode invocar qualquer funcionalidade adicional (não PSD2) fornecida por um ASPSP por meio da API STET PSD2, desde que exista um acordo bilateral para utilizar essas funcionalidades.
Autorização por acordo TPP-PSU	Se o PSU contratou um TPP, ele deve - dar uma lista dos ASPSP aos quais autoriza o acesso do TPP - realizar uma autenticação junto a cada um desses ASPSP correspondentes, o que permitirá em seguida ao TPP acessar os dados do PSU.
Autorização por contexto PSU	O PSU pode especificar seu contexto PSU detalhando, para cada uma de suas contas correspondentes: - se essa conta será acessível ou não pelo TPP - quais funcionalidades podem ser utilizadas pelo TPP O PSU pode modificar a qualquer momento seu contexto PSU.

3.4.2. Bases técnicas

O TPP está autorizado a acessar a API do ASPSP por meio de um token de acesso (access token) que pode ser

obtido por meio do framework de autorização OAuth2 (https://tools.ietf.org/html/rfc6749).

Diferentes concessões de autorização (grants) podem ser utilizadas, conforme o papel do TPP e o caso de uso a ser aplicado.

O TPP pode precisar gerenciar vários tokens OAuth2 fornecidos por um determinado ASPSP em nome de um determinado PSU. De fato, a solicitação de um novo token OAuth2 não deve implicar a revogação de um anterior.

3.4.2.1. Correspondência de identidade do TPP

O protocolo OAuth2 é reforçado verificando a identidade do TPP durante os procedimentos OAuth2 por meio do certificado eIDAS do TPP, com base em MTLS (https://datatracker.ietf.org/doc/rfc8705/).

Esse reforço é obtido pelo fornecimento obrigatório, pelo TPP, de um campo [client_id] em todas as solicitações OAuth2. Esse [client_id] deve corresponder, direta ou indiretamente, ao número de autorização situado no certificado eIDAS do TPP, e essa correspondência deve ser verificada pelo ASPSP em cada solicitação OAuth2.

Como o MTLS é utilizado, o uso do [client_secret] não é muito útil, mas pode, ainda assim, ser exigido por alguns servidores de autorização. Toda implementação que exija o uso de um [client_secret] deve atualizar sua documentação sobre esse tema.

Correspondência direta

A correspondência pode obviamente ser direta quando o [client_id] é igual ao número de autorização.

Nesse caso, o API MANAGER do ASPSP pode ser capaz de verificar e aceitar «em tempo real» a solicitação OAuth2.

Correspondência indireta

No entanto, em alguns casos, em particular quando o API MANAGER não consegue tratar um registro «em tempo real», uma configuração técnica OAuth2 deve ocorrer antes de qualquer solicitação de token OAuth2. Essa configuração resultará no fornecimento de um valor de [client_id] pelo ASPSP ao TPP.

O fornecimento de vários valores de [client_id] que o TPP poderia utilizar para diferentes casos de uso é possível repetindo a configuração.
Além disso, a configuração permite a troca de dados operacionais entre o TPP e o ASPSP para uso posterior: logotipos, números de telefone, endereços de e-mail, certificados…

Com o tempo, essa configuração pode ser automatizada.

3.4.2.2. Configuração técnica OAuth2 automatizada

Princípios

Embora a maioria dos API managers forneça uma interface de configuração on-line, essa configuração também pode ser automatizada.

A RFC 7591 especifica um protocolo dinâmico interativo que permite a um cliente fornecer certos metadados de contexto e obter um valor de [client_id]. Não há nenhuma restrição para fornecer vários valores de [client_id] para os mesmos metadados de cliente e de contexto. No entanto, o número de [client_id] solicitados por um mesmo cliente deve permanecer razoável e motivado por uma necessidade real. Como complemento, a RFC 7592 especifica como recuperar, modificar ou excluir um contexto previamente postado.

Se forem necessários vários contextos de uso para um determinado cliente de API, esse cliente deverá reiterar o processo completo para obter tantos valores de [client_id] quantos forem necessários.

De fato, alguns TPP podem ser cliente de uma API em nome de um agente (Artigo 4-38 da PSD2). Cada agente deve ser considerado como um contexto de uso específico.

Como esse protocolo não é obrigatório, cada implementação de API deverá precisar se ele está ou não implementado.

Metadados de contexto

Os elementos de metadados pertinentes a fornecer estão listados a seguir:

NOME DO METADADO DE CLIENTE	DESCRIÇÃO DO METADADO	REQUISITO	CONTROLADOR DA MUDANÇA	REFERÊNCIA
redirect_uris	Array de URIs de redirecionamento para uso em fluxos baseados em redirecionamento	Obrigatório	IESG	[RFC7591]
software_statement	JSON Web Token (JWT) que assevera valores de metadados sobre o software cliente como um pacote	Opcional	IETF	[RFC7591]
token_endpoint_auth_method	Método de autenticação solicitado para o token endpoint.	Obrigatório Segundo a RFC8705 (cf. § 2.1.1), o valor a ser utilizado será «tls_client_auth» assim que o draft for promovido a RFC.	IESG IETF	[RFC7591] [RFC8705]

NOME DO METADADO DE CLIENTE	DESCRIÇÃO DO METADADO	REQUISITO	CONTROLADOR DA MUDANÇA	REFERÊNCIA
tls_client_auth_subject_dn	Indica o valor do subject do certificado que o servidor de autorização deve esperar ao autenticar o cliente correspondente.	Obrigatório Uma representação em forma de string [RFC4514] do subject distinguished name esperado do certificado, que o cliente OAuth utilizará na autenticação mutual-TLS.	IETF	[RFC8705]
grant_types	Array de grant types OAuth 2.0 que o cliente pode utilizar	Obrigatório Os valores permitidos são: - «authorization_code» - «ciba» - «client_credentials» - «refresh_token»	IESG	[RFC7591]
response_types	Array dos response types OAuth 2.0 que o cliente pode utilizar	Opcional «code» é o único valor permitido	IESG	[RFC7591]
client_name	Nome legível por humanos do cliente a ser apresentado ao usuário	Obrigatório Deve especificar o nome do agente ou, por padrão, o nome do TPP.	IESG	[RFC7591]
client_uri	URL de uma página web que fornece informações sobre o cliente	Opcional	IESG	[RFC7591]
logo_uri	URL que referencia um logotipo para o cliente	Opcional	IESG	[RFC7591]
scope	Lista separada por espaços de valores de scope OAuth 2.0	Opcional	IESG	[RFC7591]
contacts	Array de strings que representam formas de contatar as pessoas responsáveis por este cliente, normalmente endereços de e-mail	Obrigatório Pelo menos um contato deve ser fornecido.	IESG	[RFC7591]
tos_uri	URL que aponta para um documento de termos de serviço legível por humanos para o cliente	Opcional	IESG	[RFC7591]
policy_uri	URL que aponta para um documento de política legível por humanos para o cliente	Opcional	IESG	[RFC7591]
provider_legal_id	Número de autorização do TPP segundo a especificação ETSI sobre certificados eIDAS para PSD2	Obrigatório	STET (a registrar)

NOME DO METADADO DE CLIENTE	DESCRIÇÃO DO METADADO	REQUISITO	CONTROLADOR DA MUDANÇA	REFERÊNCIA
client_legal_id	Número de autorização do agente (ver abaixo)	Obrigatório em caso de um agente distinto do TPP	STET (a registrar)
logo	valor codificado em base64 do logotipo	Opcional	STET (a registrar)
jwks	Valor do documento JSON Web Key Set [RFC7517] do cliente, que contém as chaves públicas do cliente.	Opcional O valor deste campo DEVE ser um objeto JSON contendo um JWK Set válido. Essas chaves podem ser utilizadas por protocolos de nível superior que usam assinatura ou criptografia.	IESG	[RFC7591]

De maneira semelhante à especificação ETSI sobre o número de autorização dos TPP, o número

de autorização do agente deve respeitar o seguinte formato:

«AGT» como referência de tipo de identidade de pessoa jurídica de 3 caracteres;
código de país ISO 3166 de 2 caracteres que representa o país da NCA;
- hífen «-» (0x2D (ASCII), U+002D (UTF-8)); e
identificador de NCA de 2 a 8 caracteres (A-Z apenas maiúsculas, sem separador);
hífen «-» (0x2D (ASCII), U+002D (UTF-8)); e
identificador do agente (número de registro conforme especificado pela NCA).
Interações

O TPP envia seus metadados de contexto por meio de um

POST /register

Em resposta, ele obtém esses metadados de contexto completados por

o [client_id] correspondente
um [client_secret] opcional que não é realmente útil, já que a autenticação do cliente já é feita por meio de MTLS.
o [registration_client_uri] como endpoint de configuração do cliente
o [registration_access_token] a ser utilizado para acessar a configuração do cliente.
seu timestamp de emissão.

A RFC7591 permite ao servidor atualizar alguns dos metadados de contexto se necessário.

A qualquer momento, o TPP pode recuperar os metadados de contexto por meio de um

GET /register/{client_id}

A atualização dos metadados de contexto pode ser feita por meio de um

PUT /register/{client_id}

E a exclusão dos metadados de contexto é possível por meio de um

DELETE /register/{client_id}

3.4.2.3. OAuth2 Authorization Code Grant

O processo de autorização pode basear-se em uma sequência OAuth2 para obter um token Authorization Code Grant (cf. https://tools.ietf.org/html/rfc6749#section-4.1) e implementa a abordagem por REDIRECIONAMENTO.

Esse tipo de token, conforme a implementação do ASPSP:

pode ser utilizado para todos os casos de uso AISP;
pode ser utilizado para o caso de uso CBPII;
pode ser utilizado para o caso de uso de confirmação PISP.

O processo pode ser resumido pelas seguintes etapas.

Em primeiro lugar, o PSU deve especificar ao TPP a identidade de um de seus ASPSP.

Code verifier e challenge opcionais

Alguns servidores de autorização podem solicitar a implementação da RFC7636 (PKCE: Proof Key for Code Exchange) para reforçar o OAuth2 Authorization Code grant.

Portanto, o cliente deve, como primeira etapa, criar um code verifier e um code challenge.

Authorization Request

O TPP inicia a sequência OAuth2 redirecionando o PSU para a infraestrutura de autorização do ASPSP correspondente, por meio do padrão de URL e dos parâmetros a seguir

Como isso é feito por um redirecionamento do PSU, o certificado eIDAS do TPP não pode ser apresentado nesta etapa.

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

NOME		DADO	TIPO E RESTRIÇÕES
response_type	[1..1]	Tipo de token esperado	String[10] Deve ser valorado com «code»
client_id	[1..1]	Identificação do TPP	String[36] deve ser igual ou estar vinculado ao OrganizationIdentifi er do Distinguished Name do certificado eIDAS, segundo a especificação ETSI
redirect_uri	[0..1]	URL de call-back do TPP	String[140]
scope	[0..1]	Especifica as acreditações genéricas acordadas pelo PSU e pelo TPP: - Para AISP `o` aisp `o` extended_transaction_history - para CBPII `o` cbpii - para PISP `o` pisp	String[140] Lista de papéis separada por espaços. Obrigatório
state	[0..1]	Estado interno que pode ser utilizado pelo TPP para a gestão de contexto.	String[1024] Recomendado
code_challenge	[0..1]	Code challenge calculado pelo TPP segundo a RFC 7636	String[140] Obrigatório se a implementação da RFC7636 for imposta pelo servidor de autorização
code_challenge_meth od	[0..1]	Método de code challenge utilizado pelo TPP para calcular o code challenge	«S256» ou «plain» O valor padrão é «plain»

Observação: a RFC 6749 não especifica que o Authorization Code Grant suporte a transmissão do nome de usuário do Resource Owner (PSU) ou de suas preferências de idioma.

No entanto, algumas funcionalidades do OpenID Connect podem ser utilizadas para esses fins, mesmo que a especificação OpenID Connect não seja totalmente aplicada (cf. § 3.4.2.4).

Além disso, esta especificação sugere uma implementação de Token Introspection (cf. § 3.4.2.7) cujos parâmetros poderiam ser úteis para determinar a identidade e o contexto de uso do PSU.

Esses parâmetros adicionais estão resumidos na tabela a seguir.

NOME	DADO	TIPO E RESTRIÇÕES
login_hint_token	Um token contendo informações que identificam o usuário final para o qual o token foi emitido. Essas informações também podem incluir o contexto de uso específico se necessário. Os detalhes particulares e os requisitos de segurança deste elemento, bem como a forma como o usuário final é identificado por seu conteúdo, são específicos de cada ASPSP que implemente esta funcionalidade. Esse token teria sido recuperado por meio de uma solicitação de token introspection (cf.§ 3.4.2.7)	String [2048]
ui_locales	Idiomas e scripts preferidos do usuário final para a interface de usuário.	String [140] Idiomas e scripts preferidos do usuário final para a interface de usuário, representados como uma lista separada por espaços [RFC 5646]
login_hint	Dica para o servidor de autorização sobre o identificador de login que o usuário final poderia utilizar para se conectar (se necessário).	String[36]

O ASPSP

Identifica e autentica o PSU
Calcula as verificações pertinentes sobre o TPP (papéis, validade, não revogação…)
Verifica o [redirect_uri] em relação aos que possam ter sido declarados durante a configuração técnica OAuth2 automatizada (cf. § 3.4.2.2). O [redirect_uri] fornecido deve corresponder exatamente a um dos que foram registrados.
Registra os [code_challenge] e [code_challenge_method] com a solicitação de código quando a implementação da RFC 7636 é imposta.

Authorization Response

Em seguida, o ASPSP redireciona o PSU para o TPP, utilizando a URL de call-back fornecida anteriormente (redirect_uri) e os parâmetros a seguir:

NOME		DADO		TIPO E RESTRIÇÕES
code	[1..1]	Código de curta duração a ser utilizado para obter o token de acesso	String[36]
state	[0..1]	Estado interno se fornecido pelo TPP	String[1024] Recomendado

A duração de vida recomendada do código de autorização conforme especificada pela RFC 6749 é de 10 minutos, mas cabe ao servidor de autorização fixar seu próprio valor de duração de vida.

Access Token Request

Para obter o token de acesso, o TPP pode agora invocar, por meio de uma solicitação POST, a infraestrutura de autorização do ASPSP com os parâmetros a seguir.

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

NOME		DADO
grant_type	[1..1]	Tipo de autorização solicitado	String[36] Deve ser valorado com «authorization_code»
code	[1..1]	Código de curta duração fornecido anteriormente pelo ASPSP	String[36]
redirect_uri	[0..1]	URL de call-back do TPP	String[140] Deve ser igual ao fornecido durante a solicitação de código de autorização
client_id	[1..1]	Identificação do TPP.	String[36] deve ser igual ou estar vinculado ao OrganizationIdentifier do Distinguished Name do certificado eIDAS, segundo a especificação ETSI
client_secret	[0..1]	O segredo de cliente	Como a autenticação do TPP cliente é fornecida por meio de MTLS, este parâmetro não é muito útil.
code_verifier	[0..1]	Code verifier RFC7636 inicialmente definido pelo TPP	Obrigatório quando a implementação da RFC7636 é imposta pelo servidor de autorização

O ASPSP
- Identifica e autentica o TPP por meio do certificado eIDAS apresentado (QWAC)
- Verifica a correspondência direta ou indireta entre o número de autorização do certificado eIDAS e o valor de [client_id].
- Calcula as verificações pertinentes sobre o TPP (papéis, validade, não revogação…)
- Verifica o valor do [code_verifier] recalculando o [code_challenge].

Access Token Response

O ASPSP responde por meio de uma resposta HTTP200 (OK) que incorpora os dados a seguir.

NOME		DADO	TIPO E RESTRIÇÕES
access_token	[1..1]	Token de acesso fornecido pelo ASPSP ao TPP.	String[140]
token_type	[1..1]	Tipo do token de acesso fornecido («Bearer» ou «MAC»)	String[10] Deve ser valorado com «Bearer»
expires_in	[0..1]	Duração de vida do token, em segundos. O token pode ser utilizado várias vezes enquanto não estiver expirado.	Numeric
refresh_token	[0..1]	Refresh token que pode ser utilizado para uma futura solicitação de renovação de token.	String[140]

3.4.2.4. Extensão OpenID Connect do OAuth2 Authorization Code Grant

«Como funcionalidade opcional, um servidor de autorização pode implementar a especificação OpenID Connect Core 1.0» sobre o fluxo OAuth2 «Authorization Code».

O protocolo OpenID Connect permite ao cliente da API (TPP) obter do servidor da API (ASPSP) um IdToken que certificará a identidade do PSU, uma vez que esse PSU tenha sido autenticado pelo ASPSP.

Solicitação de autenticação simples

A Open Id Connect Authentication Request baseia-se na OAuth2 «Authorization Code» Authorization Request com alguns parâmetros adicionais, marcados em negrito no diagrama a seguir.

NOME		DADO	TIPO E RESTRIÇÕES
response_type	[1..1]	Tipo de token esperado	String[10] Deve ser valorado com «code»
client_id	[1..1]	Identificação do TPP	String[36] deve ser igual ou estar vinculado ao OrganizationIdentifier do Distinguished Name do certificado eIDAS, segundo a especificação ETSI
redirect_uri	[0..1]	URL de call-back do TPP	String[140]
Scope	[0..1]	Especifica as acreditações genéricas acordadas pelo PSU e pelo TPP: - Para AISP `o` aisp `o` extended_transaction_history - para CBPII `o` cbpii. - Em qualquer caso `o` openid `o` offline_access	String[140] Lista de papéis separada por espaços. scopes adicionais são necessários -openid para especificar o uso do OpenID Connect -offline_access para permitir a recuperação de um refresh token dentro do contexto OpenID.
State	[0..1]	Estado interno que pode ser utilizado pelo TPP para a gestão de contexto.	String[1024]
Nonce	[0..1]	Associação de uma sessão de cliente a um Id token utilizada para mitigar ataques de repetição	String[36]
max-age	[0..1]	Idade máxima de autenticação (em segundos)	String[15]

NOME		DADO	TIPO E RESTRIÇÕES
ui_locales	[1..1]	Idiomas e scripts preferidos do usuário final para a interface de usuário.	String [140] Idiomas e scripts preferidos do usuário final para a interface de usuário, representados como uma lista separada por espaços [RFC 5646] Obrigatório pela API
id_token_hint	[0..1]	último IdToken conhecido para o usuário final (PSU), se houver.	String [2048]
login_hint	[0..1]	Dica para o servidor de autorização sobre o identificador de login que o usuário final poderia utilizar para se conectar (se necessário).	String[36]
Login_hint_token	[0..1]	Um token contendo informações que identificam o usuário final para o qual o token foi emitido. Essas informações também podem incluir o contexto de uso específico se necessário. Os detalhes particulares e os requisitos de segurança deste elemento, bem como a forma como o usuário final é identificado por seu conteúdo, são específicos de cada ASPSP que implemente esta funcionalidade. Esse token teria sido recuperado por meio de uma solicitação de token introspection (cf.§ 3.4.2.7)	String [2048]

O parâmetro [id_token_hint] é muito útil para facilitar a renovação de uma solicitação de autenticação do PSU transmitindo sua identificação já conhecida. Para uma primeira solicitação de autenticação, o parâmetro [login_hint] pode ser utilizado pelo TPP para transmitir a identificação do PSU, tal como conhecida pelo ASPSP.

Como a OpenID Connect Authentication Request baseia-se na OAuth2 Authorization Request, esta última é enriquecida da seguinte maneira:

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

Solicitação de autenticação assinada

A OpenID Connect Authentication Request também pode ser passada como um Signed Request Object se o servidor de autorização o permitir.

A estrutura desse Signed Request Object é um Json Web Token (JWT) cujos dados incluem:

os parâmetros de solicitação habituais conforme especificados acima
alguns parâmetros adicionais relativos à assinatura (ver https://openid.net/specs/openid-connect-core-1_0.html#RequestObject para mais detalhes)

Cabe notar que, embora o Signed Request Object prevaleça sobre os parâmetros de solicitação habituais, estes últimos também podem ser passados em paralelo.

Authentication Response

Em caso de processamento bem-sucedido da solicitação, o servidor retornará um código de autorização por meio do redirecionamento do PSU para o TPP.

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

Token request

O TPP solicita a troca do código de autorização por um 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: o cabeçalho «Authorization» é inútil, já que a autenticação é fornecida por meio de MTLS, com base no certificado eIDAS do TPP (https://datatracker.ietf.org/doc/rfc8705/).

Token response

O servidor de autorização responde com:

um token de acesso OAuth2
um refresh token OAuth2
um 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" }

Estrutura do IdToken

A estrutura do IdToken é um Json Web Token (JWT).

No exemplo anterior, os seguintes dados estão incluídos:

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

Os possíveis elementos de dados são descritos na tabela a seguir:

FIELD	REQUISITO	DESCRIÇÃO
iss	Obrigatório	Identificador do provedor do token
sub	Obrigatório	Identificador do sujeito do token
aud	Obrigatório	Destinatário do token [client_id]
nonce	Condicional	Recuperação obrigatória do parâmetro [nonce] se estiver presente na Authentication Request inicial
exp	Obrigatório	Data de expiração do IdToken [RFC3339]
iat	Obrigatório	Data de criação do IdToken [RFC3339]
auth_time	Condicional	Data e hora de autenticação do usuário final (PSU) ["https://tools.ietf.org/html/rfc3339"] quando o parâmetro [max_age] está presente na Authentication Request inicial

3.4.2.5. Client Initiated Backchannel Authentication Grant

Esse processo de registro baseia-se no fluxo OpenID FAPI Connect CIBA e implementa a abordagem DESACOPLADA. (https://openid.net/specs/openid-client-initiated-backchannelauthentication-core-1_0.html)

No entanto, para evitar qualquer etapa de pré-registro, supõe-se que essa concessão utilize o modo polling como único meio de obter o token solicitado.

Esse tipo de token, conforme a implementação do ASPSP:

pode ser utilizado para todos os casos de uso AISP;
pode ser utilizado para o caso de uso CBPII;

Authorization Request

Para obter o token de acesso, o TPP invoca, por meio de uma solicitação POST, a infraestrutura

de autorização do ASPSP com os parâmetros a seguir.

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=

NOME		DADO	TIPO E RESTRIÇÕES
client_id	[1..1]	Identificação do TPP	String[36] deve ser igual ou estar vinculado ao OrganizationIdentifier do Distinguished Name do certificado eIDAS, segundo a especificação ETSI
scope	[1..1]	Especifica as acreditações genéricas acordadas pelo PSU e pelo TPP: - Para AISP `o` aisp `o` extended_transaction_history - para CBPII `o` cbpii	String[140] Lista de papéis separada por espaços. Obrigatório
login_hint_token	[0..1]	Um token contendo informações que identificam o usuário final para o qual o token foi emitido. Essas informações também podem incluir o contexto de uso específico se necessário. Os detalhes particulares e os requisitos de segurança deste elemento, bem como a forma como o usuário final é identificado por seu conteúdo, são específicos de cada ASPSP que implemente esta funcionalidade. Esse token teria sido recuperado por meio de uma solicitação de token introspection (cf.§ 3.4.2.7)	String [2048]
id_token_hint	[0..1]	Um ID token emitido anteriormente ao cliente caso o ASPSP tenha implementado a extensão OpenID connect ao OAuth2.	String[36]
login_hint	[0..1]	Dica para o servidor de autorização sobre o identificador de login que o usuário final poderia utilizar para se conectar (se necessário).	String[36]
binding_message	[0..1]	Um identificador ou mensagem legível por humanos destinado a ser exibido ao usuário final.	String [140]
ui_locales	[0..1]	Idiomas e scripts preferidos do usuário final para a interface de usuário.	String [140] Idiomas e scripts preferidos do usuário final para a interface de usuário, representados como uma lista separada por espaços [RFC 5646]

O ASPSP

Identifica e autentica o TPP por meio do certificado eIDAS apresentado (QWAC)
- Verifica a correspondência direta ou indireta entre o número de autorização do certificado eIDAS e o valor de [client_id] fornecido pelo JWT
Calcula as verificações pertinentes sobre o TPP (papéis, validade, não revogação…)
Identifica o PSU e verifica se um canal desacoplado pode ser utilizado

Authorization Response

Em caso de validação bem-sucedida da solicitação, o ASPSP responde ao TPP por meio de uma resposta HTTP200 (OK) que incorpora os dados a seguir.

NOME		DADO
auth_req_id	[1..1]	Identificador único da solicitação de autorização.	String[36]
expires_in	[1..1]	Tempo de expiração em segundos do identificador da solicitação de autorização	Number
interval	[0..1]	Tempo mínimo em segundos que o TPP deve aguardar entre solicitações de polling.	Number

Enquanto isso, o ASPSP contata o PSU pelo canal desacoplado correspondente, exibe o conteúdo da solicitação de autorização e pede uma confirmação por meio de uma autenticação.

Access Token Request

O TPP pode então consultar (poll) o token endpoint com o intervalo fornecido pela authorization response.

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

NOME		DADO	TIPO E RESTRIÇÕES
client_id	[1..1]	Identificação do TPP	String[36] deve ser igual ou estar vinculado a OrganizationIdentifier do Distinguished Name do certificado eIDAS, segundo a especificação ETSI
client_secret	[0..1]	O segredo de cliente	Como a autenticação do TPP cliente é fornecida por meio de MTLS, este parâmetro não é muito útil.
grant_type	[1..1]	Tipo de grant	Deve ser igual a «urn:openid:params:grant-type:ciba»
auth_req_id	[1..1]	Identificador único da solicitação de autorização conforme fornecido na Authorization response	String [36]

Resposta de token bem-sucedida

O ASPSP responde por meio de uma resposta HTTP200 (OK) que incorpora os dados a seguir.

NOME		DADO	TIPO E RESTRIÇÕES
access_token	[1..1]	Token de acesso fornecido pelo ASPSP ao TPP.	String[140]
token_type	[1..1]	Tipo do token de acesso fornecido («Bearer» ou «MAC»)	String[10] Deve ser valorado com «Bearer»

NOME		DADO	TIPO E RESTRIÇÕES
expires_in	[0..1]	Duração de vida do token, em segundos. O token pode ser utilizado várias vezes enquanto não estiver expirado.	Numeric
refresh_token	[0..1]	Refresh token que pode ser utilizado para uma futura solicitação de renovação de token.	String[140]

Resposta de token com erro

Além dos códigos de erro já especificados pela RFC6749, os valores a seguir também podem ser utilizados no contexto de uma resposta HTTP400.

CÓDIGO DE ERRO	DESCRIÇÃO
authorization_pending	A solicitação de autorização ainda está pendente, pois o usuário final (PSU) ainda não foi autenticado. Respeitando o intervalo de polling especificado, o TPP deverá repetir a solicitação de token.
slow_down	A solicitação de autorização ainda está pendente, pois o usuário final (PSU) ainda não foi autenticado e o TPP deverá repetir a solicitação de token. No entanto, o intervalo de polling deve ser aumentado em pelo menos 5 segundos para esta próxima solicitação e todas as seguintes.
expired_token	O identificador da solicitação de autorização expirou. O TPP deverá fazer uma nova solicitação de autorização
access_denied	o usuário final (PSU) negou a solicitação de autorização

3.4.2.6. OAuth2 Client Credentials Flow

O registro do TPP pelo ASPSP baseia-se em uma sequência OAuth2 para obter um token Client Credential grant (cf. https://tools.ietf.org/html/rfc6749#section-4.4).

Esse tipo de token, conforme a implementação do ASPSP:

pode ser utilizado para o caso de uso CBPII;
pode ser utilizado para o caso de uso de confirmação PISP (abordagem REDIRECT básica);
- deve ser utilizado para todos os demais casos de uso PISP.

Esse procedimento pode ser resumido pelas seguintes etapas.

Access Token Request

O TPP envia diretamente, por meio de uma solicitação POST, sua solicitação de token de acesso à infraestrutura de autorização do ASPSP com o padrão de URL e os parâmetros a seguir

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

NOME		DADO	DADO	TIPO E RESTRIÇÕES
grant_type	[1..1]	Tipo de autorização solicitado		String[36] Deve ser valorado com «client_credentials»
scope	[0..1]	Especifica as acreditações genéricas acordadas pelo PSU e pelo TPP: PISP.	String[140] Lista de papéis separada por espaços. O valor padrão é «pisp»
client_id	[1..1]	Identificação do TPP	String[36] deve ser igual ou estar vinculado ao OrganizationIdentifier do Distinguished Name do certificado eIDAS, segundo a especificação ETSI
client_secret	[0..1]	O segredo de cliente	Como a autenticação do TPP cliente é fornecida por meio de MTLS, este parâmetro não é muito útil.

O ASPSP

Identifica e autentica o TPP por meio do certificado eIDAS apresentado (QWAC)
Verifica a correspondência, direta ou indireta, entre o número de autorização do certificado eIDAS e o valor de [client_id].
Calcula as verificações pertinentes sobre o TPP (papéis, validade, não revogação…)

Access Token Response

O ASPSP responde por meio de uma resposta HTTP200 (OK) que incorpora os dados a seguir.

NOME		DADO
access_token	[1..1]	Token de acesso fornecido pelo ASPSP ao TPP.	String[140]
token_type	[1..1]	Tipo do token de acesso fornecido («Bearer» ou «MAC»)	String[10] Deve ser valorado com «Bearer»
expires_in	[0..1]	Duração de vida do token, em segundos. O token pode ser utilizado várias vezes enquanto não estiver expirado.	Numeric

3.4.2.7. OAuth2 Token introspection

A RFC 7662 (cf. https://tools.ietf.org/html/rfc7662) especifica como fornecer metainformações sobre um determinado token.

Cabe a cada ASPSP implementar essa funcionalidade se necessário.

Introspection Request

Para obter as metainformações sobre um determinado token, o TPP invocará, por meio de uma solicitação POST utilizando seu certificado eIDAS, a infraestrutura de autorização do ASPSP com os parâmetros a seguir.

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

NOME		DADO	TIPO E RESTRIÇÕES
Token	[1..1]	Valor de string do token	String[144]
token_type_hint	[0..1]	Tipo do token conforme definido	Deve ser valorado com «refresh_token» ou com «access_token»
client_id	[1..1]	Identificação do TPP	String[36] deve ser igual ou estar vinculado a OrganizationIdentifier do Distinguished Name do certificado eIDAS, segundo a especificação ETSI
client_secret	[0..1]	O segredo de cliente	Como a autenticação do cliente TPP é fornecida por meio de MTLS, este parâmetro não é muito útil.

O ASPSP
- Identifica e autentica o TPP por meio do certificado eIDAS apresentado (QWAC)

Verifica a correspondência direta ou indireta do valor de [token] com o número de autorização situado no certificado eIDAS do TPP (QWAC).
obtém o token correspondente e suas metainformações para construir a resposta.

Introspection Response

O ASPSP responde com um objeto JSON com os elementos a seguir sugeridos conforme especificado pela RFC:

NOME		DADO	TIPO E RESTRIÇÕES
Active	[1..1]	Indicador booleano de se o token apresentado está atualmente ativo ou não.	«true» ou «false»
Scope	[0..1]	Lista separada por espaços dos scopes associados a este token	String[140] Lista de papéis separada por espaços.
client_id	[0..1]	Identificador de cliente do cliente OAuth 2.0 que solicitou este token.	String[36] deve ser igual ou estar vinculado ao OrganizationIdentifier do Distinguished Name do certificado eIDAS, segundo a especificação ETSI
token_type	[0..1]	Tipo do token de acesso fornecido («Bearer» ou «MAC»)	String[10] Deve ser valorado com «Bearer» para os tokens de acesso. O valor é irrelevante para os refresh tokens.
Exp	[0..1]	Timestamp inteiro, medido em número de segundos desde 1º de janeiro de 1970 UTC, indicando quando este token expirará.	Integer Este campo DEVE ser fornecido
Iat	[0..1]	Timestamp inteiro, medido em número de segundos desde 1º de janeiro de 1970 UTC, indicando quando este token foi originalmente emitido	Integer Este campo pode ser fornecido

A especificação da API STET sugere o fornecimento de outro elemento específico definido da seguinte maneira:

NOME	DADO	TIPO E RESTRIÇÕES
login_hint_token	Um token contendo informações que identificam o usuário final para o qual o token foi emitido. Essas informações também podem incluir o contexto de uso específico se necessário. Os detalhes particulares e os requisitos de segurança deste elemento, bem como a forma como o usuário final é identificado por seu conteúdo, são específicos de cada ASPSP que implemente esta funcionalidade.	String [2048]

O [login_hint_token] pode em seguida ser utilizado pelo TPP para fornecer novamente uma pista sobre a identidade e o contexto de uso do PSU, em particular:

durante um novo OAuth2 Authorisation Code Grant (cf. § 3.4.2.3) ou seu equivalente OpenID connect (cf. § 3.4.2.4)
durante uma nova Client Initiated Backchannel Authentication (cf. § 3.4.2.5)
durante o envio de uma solicitação de pagamento (por meio dos dados suplementares do payload).

3.4.2.8. Uso do token de acesso

O token de acesso deve ser utilizado em cada solicitação dentro do cabeçalho «Authorization», precedido pelo tipo de token «Bearer».

O [client_id] vinculado ao token de acesso deve corresponder direta ou indiretamente ao

número de autorização situado no certificado eIDAS do TPP (QWAC).

Se o token de acesso estiver expirado, a solicitação será rejeitada com um HTTP401 e um erro igual a

«invalid_token» e a solicitação poderá ser repetida assim que o token de acesso for renovado.

Se o scope do token de acesso não puder cobrir a solicitação (caso de uma solicitação de histórico de transações estendido, por exemplo):

a solicitação será rejeitada com um HTTP403 e um erro igual a «insufficient_scope»
o refresh token será revogado para que a solicitação possa ser repetida assim que um novo token, com o scope adequado, for solicitado e fornecido.

3.4.2.9. Renovação do token de acesso

A renovação do token de acesso só é possível quando o token de acesso foi concedido por meio de um OAuth2 «Authorization Code», OpenID Connect ou «Client Initiated Backchannel Authentication» Grants.

Segundo a RFC 6749 (cf. https://tools.ietf.org/html/rfc6749#section-6), o Refresh Token pode ser utilizado pelo TPP para obter um token de acesso renovado por meio da seguinte solicitação.

POST /token HTTP/1.1

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

NOME		DADO	TIPO E RESTRIÇÕES
grant_type	[1..1]		Deve ser valorado com «refresh_token»
refresh_token	[1..1]	Valor do refresh token fornecido
client_id	[1..1]	Identificação do TPP	String[36] deve ser igual ou estar vinculado a OrganizationIdentifier do Distinguished Name do certificado eIDAS, segundo a especificação ETSI
client_secret	[0..1]	O segredo de cliente	Como a autenticação do cliente TPP é fornecida por meio de MTLS, este parâmetro não é muito útil.
scope	[0..1]	Especifica as acreditações genéricas acordadas pelo PSU e pelo TPP: «aisp» ou «cbpii». «extended_transaction_history» não é permitido neste caso.	String[140] Lista de papéis separada por espaços.

O ASPSP
- Identifica e autentica o TPP por meio do certificado eIDAS apresentado (QWAC)
- Verifica a correspondência direta ou indireta entre o número de autorização do certificado eIDAS e o valor de [client_id].
O ASPSP responde por meio de uma resposta HTTP200 (OK) que incorpora os dados a seguir.

NOME		DADO
access_token	[1..1]	Token de acesso fornecido pelo ASPSP ao TPP.	String[140]
token_type	[1..1]	Tipo do token de acesso fornecido («Bearer» ou «MAC»)	String[10] Deve ser valorado com «Bearer»
expires_in	[0..1]	Duração de vida do token, em segundos. O token pode ser utilizado várias vezes enquanto não estiver expirado.	Numeric
refresh_token	[0..1]	Refresh token que pode substituir o refresh token anterior.	String[140]

Se o refresh token tiver sido revogado, a solicitação será rejeitada com um HTTP400 e um erro igual a «invalid grant».

3.4.2.10. Revogação do refresh token

O refresh token fornecido a um AISP é de fato revogado pelo ASPSP

Após a expiração do prazo legal especificado entre duas SCA.
Após a expiração do prazo especificado pelo ASPSP com base em regras internas, se houver.
Após a rejeição de uma solicitação por scope insuficiente, para permitir ao AISP solicitar outro token com o scope desejado.
A pedido de um PSU que deseje revogar o acesso do TPP aos dados de sua conta.

O TPP também pode solicitar a revogação do refresh token, segundo a RFC 7009 (cf.

https://tools.ietf.org/html/rfc7009) por meio da seguinte solicitação.

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

NOME		DADO	TIPO E RESTRIÇÕES
token	[1..1]	Token a ser revogado pelo ASPSP.	String[140]
token_type_hint	[0..1]	Informação sobre o tipo de token a ser revogado	Deve ser valorado com «refresh_token»
client_id	[1..1]	Identificação do TPP	String[36] deve ser igual ou estar vinculado a OrganizationIdentifier do Distinguished Name do certificado eIDAS, segundo a especificação ETSI
client_secret	[0..1]	O segredo de cliente	Como a autenticação do cliente TPP é fornecida por meio de MTLS, este parâmetro não é muito útil.

O ASPSP
- Identifica e autentica o TPP por meio do certificado eIDAS apresentado (QWAC)
- Verifica a correspondência direta ou indireta do valor de [client_id] com o número de autorização situado no certificado eIDAS do TPP (QWAC).
- Revoga o refresh token

3.4.2.11. OAuth2 para aplicativos nativos

A RFC 8252 (https://tools.ietf.org/html/rfc8252) amplia o uso da OAuth Authorization request aos aplicativos instalados em um determinado dispositivo (p. ex. um smartphone).

Com base nessa RFC, poderia considerar-se um processo de autorização direto (straight through) utilizando

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

No entanto, a especificação da API não impõe esse mecanismo.

3.4.3. Níveis de autorização AISP

Como um TPP age em nome de um PSU que é um PAO, os casos de uso PSD2 ligados ao papel AISP requerem os seguintes níveis de autorização:

Autorização por papel
Autorização por acordo TPP-PSU
Autorização por contexto PSU

3.4.3.1. Lista dos ASPSP correspondentes

Ao contratar um TPP, o PSU fornecerá uma lista dos ASPSP aos quais autoriza o acesso do TPP.

Essa lista pode não ser exaustiva e, portanto, não incluir alguns dos ASPSP do PSU.

3.4.3.2. Registro do acordo TPP-PSU por cada ASPSP

Esse registro tem como objetivo permitir o acesso posterior do TPP aos dados do PSU hospedados por um determinado ASPSP, fornecendo ao TPP um token de acesso OAuth2.

O token de acesso pode ser obtido por meio de um dos seguintes Grants:

OAuth2 Authorization Code grant (abordagem REDIRECT)
- Esse grant pode ser enriquecido com os seguintes parâmetros adicionais emprestados do OpenID Connect:
  - [login_hint]
  - [ui_locales]
OpenID Connect Grant (abordagem REDIRECT)
Client Initiated Backchannel Authentication Grant (abordagem DESACOPLADA)

Cada ASPSP deverá documentar sua própria escolha sobre esse tema.

3.4.3.3. Scopes OAuth2 AISP

Solicita-se que os papéis AISP, CBPII ou PISP não sejam misturados dentro de uma mesma definição de scope em uma solicitação de token de acesso OAuth2.

O scope OAuth2 solicitado por um AISP pode ser um dos seguintes valores:

«aisp»
«aisp extended_transaction_history»

O primeiro valor de scope permite ao AISP acessar todas as contas acessíveis e dados autorizados pelo PSU até a expiração do prazo legal especificado entre duas SCA. No entanto, esse valor não permite solicitar um histórico de transações estendido, ou seja, um histórico que inclua transações de mais de 90 dias.

O segundo valor de scope permite ao AISP acessar todas as contas acessíveis e dados autorizados pelo PSU até a expiração do prazo legal especificado entre duas SCA. Ele também permite solicitar um histórico de transações estendido.

No entanto, esse scope «aisp extended_transaction_history» será restringido a «aisp» pelo ASPSP durante a primeira renovação de token. Assim:

O AISP poderá solicitar um histórico de transações estendido com o primeiro token de acesso obtido após uma solicitação de token. Assim, nesse caso, uma única SCA será necessária e utilizada para obter o token e solicitar um histórico de transações estendido.
Qualquer solicitação posterior de histórico de transações estendido será considerada fora de scope (cf. §3.4.2)

3.4.3.4. Consentimento detalhado do PSU

O consentimento detalhado do PSU especificará qual conta ou qual funcionalidade será acessível ao AISP. Ele pode ser visto como um conjunto de acreditações individuais.

Esse conjunto é específico de um determinado PSU, um determinado TPP e um determinado ASPSP.

Cada acreditação individual baseia-se em uma conta específica que pertence ao PSU e é mantida pelo ASPSP. Ela especifica quais dados (transações, saldos) o TPP está autorizado a tratar sobre essa conta.

O PSU gerencia esse contexto com o AISP, que é responsável por:

‒ A captura das escolhas do PSU:

O PSU especifica ao AISP qual conta e qual funcionalidade devem ser acessadas ou não.
A execução das escolhas do PSU:
- O AISP tem a responsabilidade de respeitar as escolhas do PSU e de não acessar nenhuma funcionalidade para a qual não tenha sido habilitado.

A qualquer momento, o PSU pode modificar suas escolhas de consentimento, mas isso só pode ser feito com o AISP.

Além disso, o consentimento do PSU pode ou não ser transmitido pelo AISP ao ASPSP, segundo um dos dois modelos de gestão do consentimento a seguir.

Modelo Full-AISP (A1)

Nesse modelo, o ASPSP não exige ser informado dos detalhes do consentimento do PSU.

Qualquer que seja a solicitação do AISP, o ASPSP responderá, sem poder verificar a conformidade da solicitação com as escolhas do PSU.

De fato, ao obter o contexto PSU do ASPSP (por meio da chamada [get /accounts]), o AISP obterá todos os links HAL e identificadores de recurso pertinentes para cada conta elegível.

Esses links HAL ajudarão o AISP a solicitar as funcionalidades necessárias sobre essas contas: saldos e/ou transações.

Modelo misto (A2)

Nesse modelo, o ASPSP exige ser informado dos detalhes do consentimento do PSU. Portanto, o ASPSP implementou um ponto de entrada de API ad-hoc que pode ser invocado pelo AISP para transmitir as escolhas do PSU.

De fato, ao obter o contexto PSU do ASPSP (por meio da chamada [get /accounts]), o AISP obterá todas as contas elegíveis, mas os links HAL e identificadores de recurso só serão fornecidos para as contas sobre as quais o consentimento foi dado pelo PSU.

Esses links HAL ajudarão o AISP a solicitar as funcionalidades necessárias sobre essas contas: saldos e/ou transações.

Escolha do modelo

Cabe ao ASPSP implementar ou não o modelo misto (A2). No entanto, se esse modelo tiver sido implementado pelo ASPSP, cabe ao AISP transmitir os detalhes do consentimento do PSU ao ASPSP sempre que o PSU der ou modificar esse consentimento.

Uma vez que os detalhes do consentimento do PSU tenham sido recebidos e salvos pelo ASPSP, o AISP, ao obter o contexto PSU do ASPSP (por meio da chamada [get /accounts]), só obterá links HAL para as contas e funcionalidades autorizadas.

3.4.4. Níveis de autorização CBPII

Como um CBPII age em nome de um PSU que é um PAO, os casos de uso PSD2 ligados aos papéis AISP e CBPII requerem os seguintes níveis de autorização:

Autorização por papel
Autorização por acordo TPP-PSU
Autorização por contexto PSU

No entanto, em alguns casos, o CBPII pode ter sido previamente inscrito pelo PSU junto ao ASPSP correspondente (cf. §3.4.4.3).

3.4.4.1. Lista dos ASPSP correspondentes

Ao contratar um TPP, o PSU fornecerá uma lista dos ASPSP aos quais autoriza o acesso do TPP. Essa lista pode não ser exaustiva e, portanto, não incluir alguns dos ASPSP do PSU.

3.4.4.2. Registro do acordo TPP-PSU por cada ASPSP

Esse registro tem como objetivo permitir o acesso posterior do TPP aos dados do PSU hospedados por um determinado ASPSP, fornecendo ao TPP um token de acesso OAuth2.

O token de acesso pode ser obtido:

Seja por meio de um fluxo OAuth2 Authorization Code (abordagem REDIRECT)
OpenID Connect Grant (abordagem REDIRECT)
Client Initiated Backchannel Authentication Grant (abordagem DESACOPLADA)

3.4.4.3. Nível de autorização CBPII pré-inscrito

Quando o PSU inscreveu previamente o CBPII junto a seu ASPSP correspondente, este último pode preferir aplicar um esquema de autorização mais simples.

O token de acesso pode então ser obtido por meio de um fluxo OAuth2 Client Credentials, já que a autenticação do PSU é desnecessária, pois o consentimento do PSU já foi capturado.

3.4.4.4. Scope CBPII

Solicita-se que os papéis AISP e CBPII não sejam misturados dentro de uma mesma definição de scope em uma solicitação de token de acesso OAuth2.

O scope OAuth2 solicitado por um CBPII só pode ser «cbpii».

3.4.5. Níveis de autorização PISP e gestão de fraude

3.4.5.1. Casos de uso

Publicar e obter uma solicitação de pagamento/transferência

Para publicar ou obter uma solicitação de pagamento em nome de um Comerciante, ou uma solicitação de transferência em nome de um Ordenante, o PISP pode utilizar um token de acesso que pode ser obtido do ASPSP por meio de um fluxo OAuth2 Client Credentials.

No entanto, a execução da solicitação de pagamento requer uma confirmação:

por parte do PSU por meio de uma autenticação adequada
por parte do próprio PISP após a conclusão de sua análise de risco de fraude.

Nessa perspectiva, durante a publicação da solicitação de pagamento, o PISP deverá sugerir

as abordagens de autenticação que suporta. O ASPSP responderá então com a abordagem de autenticação escolhida completada e a URL a ser utilizada para iniciar a autenticação do PSU.

Confirmação de uma solicitação de pagamento

Essa autenticação deve ser forte, salvo casos de isenção, e pode ser realizada por meio de uma abordagem ENFORCED REDIRECT ou DESACOPLADA (cf. infra).

Uma vez que o PSU tenha confirmado a solicitação de pagamento ao ASPSP por meio dessa autenticação, o PISP obterá um token de acesso. O PISP deve utilizar esse token de acesso para sua própria confirmação da solicitação de pagamento após ter verificado, por exemplo, a ausência de uma possível falha de segurança.

Cancelamento de uma solicitação de pagamento

Caso o PISP precise cancelar uma solicitação de pagamento, o token de acesso a ser utilizado pode ser obtido do ASPSP por meio de um fluxo OAuth2 Client Credentials.

No entanto, o ASPSP pode exigir uma confirmação por meio de uma autenticação do PSU. Essa autenticação pode ser realizada por meio de uma abordagem SIMPLE REDIRECT ou DESACOPLADA (cf. infra).

Nessa perspectiva, durante a solicitação de cancelamento, o PISP deverá sugerir as abordagens de autenticação que suporta. O ASPSP responderá então:

seja com a decisão de não tratar a autenticação do PSU; o cancelamento é então efetivo
seja com a abordagem de autenticação escolhida completada com a URL a ser utilizada para iniciar a autenticação do PSU; o cancelamento será efetivo após essa autenticação do PSU.

3.4.5.2. Abordagem SIMPLE REDIRECT

Essa abordagem só pode ser utilizada para um cancelamento de solicitação de pagamento.

A autenticação do PSU é então tratada por meio de um simples redirecionamento do PSU ao servidor de autenticação do ASPSP utilizando a URL inicialmente fornecida pelo ASPSP.

O ASPSP autentica o PSU e em seguida redireciona este último utilizando uma das URLs de call-back fornecidas pelo PISP.

3.4.5.3. Abordagem ENFORCED REDIRECT

Essa abordagem é obrigatória para uma confirmação de solicitação de pagamento em abordagem REDIRECT.

Um token Authorization Code será utilizado para a confirmação. A autenticação do PSU é tratada por meio do fluxo Authorization Code com o servidor de autenticação do ASPSP.

Objetivo e análise de risco

A iniciação de pagamento pode, de fato, enfrentar certos problemas de segurança na abordagem REDIRECT.

Um primeiro ataque (fixação de sessão) poderia ocorrer, baseado no fato de que um determinado PSU transmitirá a solicitação de redirecionamento a outro PSU que poderia estar em condições de se autenticar e pagar a compra feita pelo primeiro PSU.

Além disso, mesmo que o primeiro ataque seja mitigado, o atacante também poderia tentar simular o redirecionamento (falso redirecionamento) ao TPP para induzir a confirmação da solicitação de pagamento junto ao ASPSP.

Proteção contra a fixação de sessão

Para evitar o ataque por fixação de sessão, o PISP deve garantir que não haja «PSU-switch» durante o redirecionamento. Isso pode ser feito gerenciando um nonce que

será armazenado na sessão do user agent do PSU antes do redirecionamento ao ASPSP e
- será recuperado do user agent do PSU após o redirecionamento.

Em caso de falha da recuperação, há grandes chances de que tal ataque tenha ocorrido. O PISP deveria então cancelar a solicitação de pagamento por motivo de fraude.

Caso contrário, em caso de recuperação bem-sucedida do nonce, o PISP pode confirmar a solicitação de pagamento ao ASPSP, que está então em condições de acionar as transferências correspondentes.

Proteção contra o falso redirecionamento

Para publicar a confirmação, o PISP deve solicitar um token Authorization Code ao ASPSP.

Em resposta à solicitação de pagamento, o ASPSP forneceu ao PISP o URI do

servidor de autorização. Alguns parâmetros OAuth2 devem ter sido pré-valorados:

[response_type] valorado com «code»
[scope] valorado com «pisp»
[context] valorado com uma pista para a solicitação de pagamento

O PISP completará essa URL com seus próprios parâmetros OAuth2

[client_id]
[state] se necessário
[redirect_uri] como URL de call-back.

O OAuth2 Authorization Code grant pode então ser concluído (cf. §3.4.2.3).

Após a recuperação do Authorization Code por meio do redirecionamento do PSU de volta ao PISP, este último deve então garantir, por meio do mecanismo de verificação do nonce, que não houve «PSU-switch» durante o redirecionamento, como explicado anteriormente.

O PISP pode então trocar o Authorization Code pelo token de acesso.

a duração de vida do token de acesso é especificada pelo servidor de autorização para limitar o período de usabilidade.
nenhum refresh token deve ser fornecido.

A confirmação é então publicada, utilizando esse token de acesso.

Em caso de ataque por falso redirecionamento, o token de acesso não poderia ter sido recuperado pelo PISP. Mesmo na tentativa de confirmação, o ASPSP pode detectar a ausência do token e rejeitará então a solicitação de pagamento por motivo de FRAUDE.

Caso contrário, a confirmação enviada pelo PISP conduzirá ao acionamento normal das transferências correspondentes.

3.4.5.4. Abordagem OAuth2 DESACOPLADA

Nessa abordagem, o token Client Credential pode ser utilizado para todos os casos de uso PISP:

Publicar uma solicitação de pagamento
Obter a solicitação de pagamento publicada anteriormente
Modificar para cancelamento a solicitação de pagamento
Confirmar a solicitação de pagamento

A autenticação do PSU é tratada por meio de um canal desacoplado iniciado pelo ASPSP.

Após a autenticação do PSU, o PISP é informado por uma chamada direta do ASPSP. O PISP pode então confirmar a solicitação de pagamento, o que conduzirá ao acionamento normal das transferências correspondentes.

3.4.5.5. Tabela recapitulativa

	SIMPLE REDIRECT	ENFORCED REDIRECT	DECOUPLED
Proteção por mecanismo de nonce aplicada pelo PISP	O nonce deve ser calculado pelo PISP e armazenado no user-agent do PSU desde que o PISP aceite as abordagens Simple REDIRECT ou Enforced REDIRECT ao publicar ou cancelar uma solicitação de pagamento.

	SIMPLE REDIRECT	ENFORCED REDIRECT	DECOUPLED
Successful e Unsuccessful Report Uri fornecidos pelo PISP	Para serem utilizados pelo ASPSP por meio do redirecionamento do PSU		Para serem utilizados diretamente pelo ASPSP após a autenticação do PSU
Abordagem de autenticação aceita definida pelo PISP	Deve incluir «REDIRECT»		Deve incluir «DECOUPLED»
Abordagem de autenticação aplicada definida pelo ASPSP	«REDIRECT»		«DECOUPLED»
Autenticação do PSU	Para a confirmação de um cancelamento	Para a confirmação de uma solicitação de pagamento

3.5. Autenticação aplicativa

Cada solicitação enviada pelo TPP deve ser assinada e o ASPSP também pode assinar suas respostas.

Se o ASPSP constatar que a assinatura está ausente ou é inválida para uma determinada solicitação, deve rejeitar essa solicitação com um HTTP400.

Se o TPP constatar que a assinatura é inválida para uma determinada resposta, deve avisar o ASPSP correspondente.

3.5.1. Mecanismo Http-Signature

O mecanismo http-signature é especificado pelo seguinte draft IETF:

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

Cabe notar que esse draft IETF foi agora substituído por um novo draft:

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

No entanto, como a OpenBankingEurope e a ETSI, juntamente com várias iniciativas de API PSD2 incluindo a STET, publicaram um novo padrão de assinatura, é fortemente recomendado considerar substituir o http-signature por esse novo padrão de assinatura (cf. 3.5.2).

3.5.1.1. Cálculo da assinatura

A forma como deveria ser implementado é a seguinte

Calcular um digest SHA256 do corpo HTTP e adicionar esse digest como cabeçalho HTTP adicional.

Utilizar um certificado qualificado específico (QSealC), respeitando a especificação técnica ETSI/TS119495, para aplicar uma assinatura RSA-SHA256 sobre
- todos os cabeçalhos a seguir presentes na solicitação HTTP enviada pelo TPP, incluindo o digest calculado anteriormente
  - Date (se disponível)
  - Content-Type (quando há um payload)
  - Content-Length (quando há um payload)
  - X-Request-Id
  - Todos os cabeçalhos com prefixo «PSU» disponíveis (cf. § 3.5.2)
  - o pseudo-cabeçalho específico «(request-target)» especificado pelo draft IETF
- todos os cabeçalhos a seguir presentes na resposta HTTP fornecida pelo ASPSP, incluindo o digest calculado anteriormente
  - Date (se disponível)
  - Content-Type (quando há um payload)
  - Content-Length (se disponível)
  - X-Request-Id
Adicionar essa assinatura em um cabeçalho HTTP adicional que incorpora
- O identificador de chave, que deve especificar a forma de obter o certificado qualificado correspondente (ver abaixo)
- O algoritmo que foi utilizado
- A lista de cabeçalhos que foram assinados
- A assinatura propriamente dita.

Desde a versão #11 do draft, dois novos pseudo-cabeçalhos foram introduzidos para

reforçar a assinatura: (created) e (expires). No entanto, o trabalho sobre esse tema ainda está em curso e o uso desses dois campos ainda não é recomendado.

CABEÇALHO HTTP ADICIONAL	DADO	COMENTÁRIO
Digest	Digest do corpo
Signature	http-signature da solicitação (cf. https://datatracker.ietf.org/doc/draft-cavage-http- signatures/)

3.5.1.2. Valor do identificador de chave

Solicita-se que esse identificador seja valorado com:

Seja o keyId que foi atribuído pelo servidor de autorização durante a configuração técnica OAuth2 (cf. § 3.4.2.2).
Seja uma URL destinada a fornecer o certificado qualificado correspondente.
- Para assegurar uma fácil discriminação do certificado entre outros, solicita-se que a última parte da URL para o certificado seja sufixada por um underscore seguido da impressão digital SHA-256 do certificado.
  - Ex.: https://path.to/myQsealCertificate_714f8154ec259ac40b8a9786c9908 488b2582b68b17e865fede4636d726b709f
- Essa URL poderia ter sido fornecida durante a configuração técnica OAuth2 dentro do campo «5xu» do JKS fornecido pelo TPP (cf. RFC7517).

3.5.2. JSON Web Signature Profile for Open Banking

Esse mecanismo de assinatura é especificado pelo seguinte documento:

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

Ele baseia-se no uso de uma Json Web Signature (JWS conforme especificada pela RFC7515).

A forma como deveria ser implementado é a seguinte

Escolher um certificado qualificado (QSealC), respeitando a especificação técnica ETSI/TS119495 e pertencente ao emissor da solicitação ou da resposta como certificado de assinatura.
Escolher um algoritmo de assinatura entre os listados tanto na RFC7518 quanto na ETSI TS 119 312, embora uma revisão periódica das possíveis fraquezas desses algoritmos seja fortemente recomendada.
Calcular um digest SHA256 do corpo HTTP e adicionar esse digest como cabeçalho HTTP adicional.
Construir um JWS protected header cujo
- campo [sigD/pars] listará todos os campos de cabeçalho HTTP em minúsculas que devem ser assinados (ver abaixo) e codificá-lo em Base64url.
- campo [x5t#S256] será valorado com o hash codificado em Base64url do certificado de assinatura escolhido anteriormente
- campo [alg] será valorado com o nome do algoritmo de assinatura
- Construir a string de cabeçalhos HTTP como a lista de todos os cabeçalhos/valores que devem ser assinados.
o todos os cabeçalhos a seguir presentes na solicitação HTTP enviada pelo TPP, incluindo o digest calculado anteriormente
- Date (se disponível)
- Content-Type (quando há um payload)

Content-Length (quando há um payload)
X-Request-Id
Todos os cabeçalhos com prefixo «PSU» disponíveis (cf. § 3.5.2)
o pseudo-cabeçalho específico «(request-target)» especificado pelo draft IETF
todos os cabeçalhos a seguir presentes na resposta HTTP fornecida pelo ASPSP, incluindo o digest calculado anteriormente
- Date (se disponível)
- Content-Type (quando há um payload)
- Content-Length (se disponível)
- X-Request-Id
Concatenar o JWS protected header codificado em Base64url e a string de cabeçalhos HTTP com um ponto («.») como separador.
Calcular a assinatura, utilizando o certificado e o algoritmo escolhidos, sobre o resultado da concatenação anterior.
Concatenar o JWS protected header codificado em Base64url e a assinatura resultante com um ponto duplo («..») como separador

Adicionar o resultado da concatenação anterior como cabeçalho HTTP adicional «x-jws-signature»

3.6. Informações orientadas à detecção de fraude

Os seguintes cabeçalhos HTTP adicionais devem ser utilizados na solicitação HTTP enviada pelo TPP, desde que os dados correspondentes estejam disponíveis na conexão entre o PSU e o TPP. Essa transmissão permite ao ASPSP integrar essas informações em seu próprio processo de detecção de fraude.

Além disso, esses cabeçalhos podem ser considerados como prova da conexão do PSU.

CABEÇALHO HTTP ADICIONAL	DADO	COMENTÁRIO
PSU-IP-Address	Endereço IP do terminal do PSU ao conectar-se ao TPP	Em relação às regras da LGPD/RGPD, isso deve estar sujeito ao consentimento do PSU
PSU-IP-Port	Porta IP do terminal do PSU ao conectar-se ao TPP
PSU-HTTP-Method	Método HTTP utilizado para a solicitação mais relevante do terminal do PSU ao TPP
PSU-Date	Timestamp da solicitação mais relevante do terminal do PSU ao TPP
PSU-User-Agent	Campo de cabeçalho «User-Agent» enviado pelo terminal do PSU ao conectar-se ao TPP
PSU-Referer	Campo de cabeçalho «Referer» enviado pelo terminal do PSU ao conectar-se ao TPP
PSU-Accept	Campo de cabeçalho «Accept» enviado pelo terminal do PSU ao conectar-se ao TPP
PSU-Accept-Charset	Campo de cabeçalho «Accept-Charset» enviado pelo terminal do PSU ao conectar-se ao TPP
PSU-Accept-Encoding	Campo de cabeçalho «Accept-Encoding» enviado pelo terminal do PSU ao conectar-se ao TPP
PSU-Accept-Language	Campo de cabeçalho «Accept-Language» enviado pelo terminal do PSU ao conectar-se ao TPP
PSU-GEO-Location	A geolocalização transmitida da solicitação HTTP correspondente entre PSU e TPP se disponível.	Em relação às regras da LGPD/RGPD, isso deve estar sujeito ao consentimento do PSU
`PSU-Device-ID`	UUID (Universally Unique Identifier) de um dispositivo utilizado pelo PSU, se disponível. O UUID identifica um dispositivo ou uma instalação de aplicativo dependente de um dispositivo. Em caso de identificação de instalação, esse ID deve permanecer inalterado até a remoção do dispositivo.	Em relação às regras da LGPD/RGPD, isso deve estar sujeito ao consentimento do PSU

3.7. Outros cabeçalhos HTTP específicos que devem ser utilizados

CABEÇALHO HTTP ADICIONAL	DADO		COMENTÁRIO
X-Request-ID	Cabeçalho de correlação a ser definido em uma solicitação e recuperado na resposta correspondente.
Idempotency-Key	Chave de idempotência a ser adicionada pelo cliente da API para garantir que uma determinada solicitação, quando repetida duas ou mais vezes, só seja executada uma vez pelo servidor da API. Isso se aplica especialmente às solicitações POST.		As regras de unicidade, validade e expiração devem ser definidas conforme: https://datatracker.ietf.org/doc/draft-ietf-httpapi- idempotency-key-header/

3.8. Códigos e mensagens de retorno HTTP específicos que devem ser utilizados

MENSAGEM	CÓDIGO HTTP	SIGNIFICADO
FORMAT_ERROR	400	O formato de certos campos da solicitação não atende aos requisitos XS2A. Um path explícito para o campo correspondente pode ser adicionado na mensagem de retorno.
RESOURCE_UNKNOWN	404	Se resourceId no path
PERIOD_INVALID	400	Período de tempo solicitado fora dos limites.

MENSAGEM	CÓDIGO HTTP	SIGNIFICADO
ACCESS_EXCEEDED	429	O acesso à conta ultrapassou a multiplicidade consentida por dia.
REQUESTED_FORMATS _INVALID	406	Os formatos solicitados no cabeçalho Accept não correspondem aos formatos oferecidos pelo ASPSP.

3.9. Resumo técnico da API STET PSD2

TÓPICO	ESCOLHA		COMENTÁRIO
Rede de acesso	Internet
Protocolo de rede	HTTP 1.1 (Mínimo)
Criptografia de dados Autenticação cruzada	TLS 1.2		Poderia ser reforçada por meio de STS e/ou PFS
Protocolo de autorização			Em conformidade com as RFC 6749, 7009 Um dos seguintes modos de token - Authorization Code Grant (AISP, CBPII e PISP) para a abordagem REDIRECT - Client credential (PISP, CBPII) Com base em MTLS, a identidade do TPP é fornecida por seu certificado eIDAS durante os procedimentos OAuth2. https://datatracker.ietf.org/doc/rfc8705/ A extensão OpenId Connect também pode ser utilizada no lugar do Authorization Code Grant O Client Initiated Backchannel Authorization Grant pode ser utilizado para implementar uma abordagem DESACOPLADA



		OAuth2

Protocolo aplicativo	REST		Em conformidade com o Richardson Maturity Model, no nível três para fornecer links HYPERMEDIA.
Autenticação aplicativa	http-signature		Nota-se que se trata, na verdade, de um
Abordagens de autenticação forte do cliente (PSU)	REDIRECT, DECOUPLED
Formato de dados	JSON/UTF8		Com uso de estruturas de dados baseadas em ISO20022
Documentação técnica	SWAGGER 2.0		O formato Data/Hora deve respeitar ISO8601 e RFC3339 conforme as especificações OpenApi. O criador de uma Data/Hora deve escolher - Qualquer formato de fuso horário, embora o formato UTC seja recomendado. - Qualquer formato de fração de segundo, incluindo a ausência de fração de segundo. Uma data simples pode ser especificada como uma data/hora UTC com uma parte de hora igual a «00:00:00Z». O destinatário de uma Data/Hora deve poder interpretar seu valor desde que esteja em conformidade com ISO8601 e RFC3339.