From 70be9fc8dc73acaa85e27fa9297faaef757f42d0 Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Mon, 25 Oct 2021 09:05:38 -0300
Subject: [PATCH 01/59] =?UTF-8?q?Inclus=C3=A3o=20de=20instru=C3=A7=C3=B5es?=
 =?UTF-8?q?=20para=20atualiza=C3=A7=C3=A3o=20de=20refer=C3=AAncias=20de=20?=
 =?UTF-8?q?documentos?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 README.md | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/README.md b/README.md
index dfd93ad..3e8aecf 100644
--- a/README.md
+++ b/README.md
@@ -26,6 +26,16 @@ Esse repositório inclui o detalhamento técnico necessário para o entendimento
  - [Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)](https://openbanking-brasil.github.io/specs-seguranca/tpp-user-guide-ptbr.html)
  - [Padrão de Certificados Open Banking Brasil](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1-ptbr.html)
 
+## Manutenção dos links
+
+Sempre que for publicado um novo ID de documentação, deve-se atentar a atualização dos links nos seguintes locais:
+
+|Documento|Referências|
+|------------------------------------------|---------------------------------------------------------------------------------------------------|
+|Registro e Cadastramento Dinâmico do Cliente de APIs|Perfil de Segurança do OpenBanking Brasil<br>Padrão de Certificados Open Banking Brasil<br>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)<br>Áerea do Desenvolvedor do Portal do Open Banking Brasil|
+|Perfil de Segurança do OpenBanking Brasil|Registro e Cadastramento Dinâmico do Cliente de APIs<br>Padrão de Certificados Open Banking Brasil<br>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)<br>Áerea do Desenvolvedor do Portal do Open Banking Brasil|
+|Padrão de Certificados Open Banking Brasil|Perfil de Segurança do OpenBanking Brasil<br>Registro e Cadastramento Dinâmico do Cliente de APIs<br>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)<br>Áerea do Desenvolvedor do Portal do Open Banking Brasil|
+
 ## Documentation Generation for Maintainers
 
 The formal specifications are created using guidelines, processes and tools created by the IETF and the OIDF which ensures consistency and familiarity for implementers. All references to the specifications should be to the normative version of the published specification published in HTML version. Linking to actively developed versions of MarkDown files directly should be avoided.

From 937486241ced68ed382773c1570206ddf07ae6f3 Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Mon, 25 Oct 2021 09:08:51 -0300
Subject: [PATCH 02/59] =?UTF-8?q?Incluso=20link=20para=20o=20DCR=20da=20do?=
 =?UTF-8?q?cumenta=C3=A7=C3=A3o=20de=20certificados,=20que=20cita=20DCR,?=
 =?UTF-8?q?=20mas=20n=C3=A3o=20possui=20link=20para=20o=20padr=C3=A3o?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 open-banking-brasil-certificate-standards-1_ID1-ptbr.md | 1 +
 open-banking-brasil-certificate-standards-1_ID1.md      | 1 +
 2 files changed, 2 insertions(+)

diff --git a/open-banking-brasil-certificate-standards-1_ID1-ptbr.md b/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
index 5a9f652..cb87efa 100644
--- a/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
+++ b/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
@@ -93,6 +93,7 @@ Os seguintes documentos referenciados são indispensáveis para a aplicação de
 * [BCP195] - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]: <https://tools.ietf.org/html/bcp195>
 * [RFC8705] - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens [RFC8705]: <https://tools.ietf.org/html/rfc8705>
 * [OBB-FAPI] - Open Banking Brasil Financial-grade API Security Profile 1.0 [OBB-FAPI]: <https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html>
+* [OBB-FAPI-DCR] - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0 [OBB-FAPI-DCR]: <https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1.html
 * [DOC-ICP-01] - DECLARAÇÃO DE PRÁTICAS DE CERTIFICAÇÃO DA AUTORIDADE CERTIFICADORA RAIZ DA ICP-BRASIL: <https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf>
 * [RFC6749] - The OAuth 2.0 Authorization Framework [RFC6749]: <https://tools.ietf.org/html/rfc6749>
 * [BCB-IN134] - Manual de Segurança do Open Banking: <https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364>
diff --git a/open-banking-brasil-certificate-standards-1_ID1.md b/open-banking-brasil-certificate-standards-1_ID1.md
index 362e9bb..6365f74 100644
--- a/open-banking-brasil-certificate-standards-1_ID1.md
+++ b/open-banking-brasil-certificate-standards-1_ID1.md
@@ -92,6 +92,7 @@ The following referenced documents are indispensable for the application of this
 * [BCP195] - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]: <https://tools.ietf.org/html/bcp195>
 * [RFC8705] - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens [RFC8705]: <https://tools.ietf.org/html/rfc8705>
 * [OBB-FAPI] - Open Banking Brasil Financial-grade API Security Profile 1.0 [OBB-FAPI]: <https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html>
+* [OBB-FAPI-DCR] - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0 [OBB-FAPI-DCR]: <https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1.html
 * [DOC-ICP-01] - DECLARAÇÃO DE PRÁTICAS DE CERTIFICAÇÃO DA AUTORIDADE CERTIFICADORA RAIZ DA ICP-BRASIL: <https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf>
 * [RFC6749] - The OAuth 2.0 Authorization Framework [RFC6749]: <https://tools.ietf.org/html/rfc6749>
 * [BCB-IN134] - Manual de Segurança do Open Banking: <https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364>

From 09f589aec28d30597789139f744cf8fd73b3b1a0 Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Mon, 25 Oct 2021 09:13:52 -0300
Subject: [PATCH 03/59] =?UTF-8?q?Melhoria=20de=20formata=C3=A7=C3=A3o=20na?=
 =?UTF-8?q?=20tabela=20de=20refer=C3=AAncias?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 README.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/README.md b/README.md
index 3e8aecf..e413b66 100644
--- a/README.md
+++ b/README.md
@@ -32,9 +32,9 @@ Sempre que for publicado um novo ID de documentação, deve-se atentar a atualiz
 
 |Documento|Referências|
 |------------------------------------------|---------------------------------------------------------------------------------------------------|
-|Registro e Cadastramento Dinâmico do Cliente de APIs|Perfil de Segurança do OpenBanking Brasil<br>Padrão de Certificados Open Banking Brasil<br>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)<br>Áerea do Desenvolvedor do Portal do Open Banking Brasil|
-|Perfil de Segurança do OpenBanking Brasil|Registro e Cadastramento Dinâmico do Cliente de APIs<br>Padrão de Certificados Open Banking Brasil<br>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)<br>Áerea do Desenvolvedor do Portal do Open Banking Brasil|
-|Padrão de Certificados Open Banking Brasil|Perfil de Segurança do OpenBanking Brasil<br>Registro e Cadastramento Dinâmico do Cliente de APIs<br>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)<br>Áerea do Desenvolvedor do Portal do Open Banking Brasil|
+|Registro e Cadastramento Dinâmico do Cliente de APIs|<ul><li>Perfil de Segurança do OpenBanking Brasil</li><li>Padrão de Certificados Open Banking Brasil</li><li>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)</li><li>Áerea do Desenvolvedor do Portal do Open Banking Brasil</li></ul>|
+|Perfil de Segurança do OpenBanking Brasil|<ul><li>Registro e Cadastramento Dinâmico do Cliente de APIs</li><li>Padrão de Certificados Open Banking Brasil</li><li>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)</li><li>Áerea do Desenvolvedor do Portal do Open Banking Brasil</li></ul>|
+|Padrão de Certificados Open Banking Brasil|<ul><li>Perfil de Segurança do OpenBanking Brasil</li><li>Registro e Cadastramento Dinâmico do Cliente de APIs</li><li>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)</li><li>Áerea do Desenvolvedor do Portal do Open Banking Brasil</li></ul>|
 
 ## Documentation Generation for Maintainers
 

From 5958a83421725fb0045476b5028de88f46d79ea2 Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Mon, 25 Oct 2021 09:21:27 -0300
Subject: [PATCH 04/59] =?UTF-8?q?Atualiza=C3=A7=C3=A3o=20dos=20links=20no?=
 =?UTF-8?q?=20guia=20do=20TPP?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 tpp-user-guide-ptbr.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tpp-user-guide-ptbr.md b/tpp-user-guide-ptbr.md
index afd78c6..2086c30 100644
--- a/tpp-user-guide-ptbr.md
+++ b/tpp-user-guide-ptbr.md
@@ -522,15 +522,15 @@ eyJraWQiOiJzaWduZXIiLCJ0eXAiOiJKV1QiLCJhbGciOiJQUzI1NiJ9.eyJzb2Z0d2FyZV9tb2RlIjo
 
 ## 3.3 Enviando uma Solicitação de Dynamic Client Registration (RFC7591)  {#RFC7591}
 
-Consulte o [Dynamic Client Registration do Open Banking Brasil](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html)
+Consulte o [Dynamic Client Registration do Open Banking Brasil](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html)
 
 ## 3.4 Salvando o Token de Dynamic Registration Management (RFC7592)  {#RFC7592}
 
-Consulte o [Dynamic Client Registration do Open Banking Brasil](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html)
+Consulte o [Dynamic Client Registration do Open Banking Brasil](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html)
 
 ## 3.5 Modificando um cliente usando Dynamic Client Management Token (RFC7592) {#RFC7592Token}
 
-Consulte o [Dynamic Client Registration do Open Banking Brasil](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html)
+Consulte o [Dynamic Client Registration do Open Banking Brasil](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html)
 
 ## 4.0 Obtendo Acesso aos Recursos dos Clientes  {#AcessoClientes}
 
@@ -630,7 +630,7 @@ A tabela abaixo reflete os diferentes profiles de segurança e combinações que
 | BR-OB Adv. OP w/ MTLS, PAR	|
 | BR-OB Adv. OP w/ Private Key, PAR	|
 
-Todos os requisitos para o OpenID Request Object estão incluídos no [Perfil de Segurança do Open Banking Brasil](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID1-ptbr.html). Veja o exemplo com JWS a seguir:
+Todos os requisitos para o OpenID Request Object estão incluídos no [Perfil de Segurança do Open Banking Brasil](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3-ptbr.html). Veja o exemplo com JWS a seguir:
 
 ```
 {

From f116e5fd4119ae436023ee66c9bdb80642809cd0 Mon Sep 17 00:00:00 2001
From: rafael-hashimoto <89614766+rafael-hashimoto@users.noreply.github.com>
Date: Tue, 26 Oct 2021 10:19:03 -0300
Subject: [PATCH 05/59] Update
 open-banking-brasil-certificate-standards-1_ID1-ptbr.md

---
 open-banking-brasil-certificate-standards-1_ID1-ptbr.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/open-banking-brasil-certificate-standards-1_ID1-ptbr.md b/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
index cb87efa..17ffba3 100644
--- a/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
+++ b/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
@@ -93,7 +93,7 @@ Os seguintes documentos referenciados são indispensáveis para a aplicação de
 * [BCP195] - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]: <https://tools.ietf.org/html/bcp195>
 * [RFC8705] - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens [RFC8705]: <https://tools.ietf.org/html/rfc8705>
 * [OBB-FAPI] - Open Banking Brasil Financial-grade API Security Profile 1.0 [OBB-FAPI]: <https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html>
-* [OBB-FAPI-DCR] - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0 [OBB-FAPI-DCR]: <https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1.html
+* [OBB-FAPI-DCR] - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0 [OBB-FAPI-DCR]: <https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html
 * [DOC-ICP-01] - DECLARAÇÃO DE PRÁTICAS DE CERTIFICAÇÃO DA AUTORIDADE CERTIFICADORA RAIZ DA ICP-BRASIL: <https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf>
 * [RFC6749] - The OAuth 2.0 Authorization Framework [RFC6749]: <https://tools.ietf.org/html/rfc6749>
 * [BCB-IN134] - Manual de Segurança do Open Banking: <https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364>

From 7e4fda71b1f48e2bf43fafcc730af439a4b63a93 Mon Sep 17 00:00:00 2001
From: rafael-hashimoto <89614766+rafael-hashimoto@users.noreply.github.com>
Date: Tue, 26 Oct 2021 10:22:46 -0300
Subject: [PATCH 06/59] Atualizado link do DCR para ID2 e FAPI para ID3

---
 open-banking-brasil-certificate-standards-1_ID1-ptbr.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/open-banking-brasil-certificate-standards-1_ID1-ptbr.md b/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
index 17ffba3..3c76092 100644
--- a/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
+++ b/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
@@ -92,7 +92,7 @@ Os seguintes documentos referenciados são indispensáveis para a aplicação de
 * [RFC7592] - OAuth 2.0 Dynamic Client Registration Management Protocol [RFC7592]:<https://tools.ietf.org/html/rfc7592>
 * [BCP195] - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]: <https://tools.ietf.org/html/bcp195>
 * [RFC8705] - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens [RFC8705]: <https://tools.ietf.org/html/rfc8705>
-* [OBB-FAPI] - Open Banking Brasil Financial-grade API Security Profile 1.0 [OBB-FAPI]: <https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html>
+* [OBB-FAPI] - Open Banking Brasil Financial-grade API Security Profile 1.0 [OBB-FAPI]: <https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html>
 * [OBB-FAPI-DCR] - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0 [OBB-FAPI-DCR]: <https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html
 * [DOC-ICP-01] - DECLARAÇÃO DE PRÁTICAS DE CERTIFICAÇÃO DA AUTORIDADE CERTIFICADORA RAIZ DA ICP-BRASIL: <https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf>
 * [RFC6749] - The OAuth 2.0 Authorization Framework [RFC6749]: <https://tools.ietf.org/html/rfc6749>

From 9667462fdad3aa38962992bcf9a1105d0c655b83 Mon Sep 17 00:00:00 2001
From: rafael-hashimoto <89614766+rafael-hashimoto@users.noreply.github.com>
Date: Tue, 26 Oct 2021 10:24:01 -0300
Subject: [PATCH 07/59] Atualizado link do FAPI para ID 3 e DCR para ID 2

---
 open-banking-brasil-certificate-standards-1_ID1.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/open-banking-brasil-certificate-standards-1_ID1.md b/open-banking-brasil-certificate-standards-1_ID1.md
index 6365f74..483c913 100644
--- a/open-banking-brasil-certificate-standards-1_ID1.md
+++ b/open-banking-brasil-certificate-standards-1_ID1.md
@@ -91,8 +91,8 @@ The following referenced documents are indispensable for the application of this
 * [RFC7592] - OAuth 2.0 Dynamic Client Registration Management Protocol [RFC7592]:<https://tools.ietf.org/html/rfc7592>
 * [BCP195] - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]: <https://tools.ietf.org/html/bcp195>
 * [RFC8705] - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens [RFC8705]: <https://tools.ietf.org/html/rfc8705>
-* [OBB-FAPI] - Open Banking Brasil Financial-grade API Security Profile 1.0 [OBB-FAPI]: <https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html>
-* [OBB-FAPI-DCR] - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0 [OBB-FAPI-DCR]: <https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1.html
+* [OBB-FAPI] - Open Banking Brasil Financial-grade API Security Profile 1.0 [OBB-FAPI]: <https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html>
+* [OBB-FAPI-DCR] - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0 [OBB-FAPI-DCR]: <https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html
 * [DOC-ICP-01] - DECLARAÇÃO DE PRÁTICAS DE CERTIFICAÇÃO DA AUTORIDADE CERTIFICADORA RAIZ DA ICP-BRASIL: <https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf>
 * [RFC6749] - The OAuth 2.0 Authorization Framework [RFC6749]: <https://tools.ietf.org/html/rfc6749>
 * [BCB-IN134] - Manual de Segurança do Open Banking: <https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364>

From e7f24803d65f89e169fb709a4b6e50000c72d4a1 Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Tue, 26 Oct 2021 19:45:52 -0300
Subject: [PATCH 08/59] English Outdated Notice

---
 open-banking-brasil-certificate-standards-1_ID1.html     | 5 +++++
 open-banking-brasil-certificate-standards-1_ID1.md       | 4 ++++
 open-banking-brasil-dynamic-client-registration-1_ID2.md | 4 ++++
 3 files changed, 13 insertions(+)

diff --git a/open-banking-brasil-certificate-standards-1_ID1.html b/open-banking-brasil-certificate-standards-1_ID1.html
index 42de0cc..5f88368 100644
--- a/open-banking-brasil-certificate-standards-1_ID1.html
+++ b/open-banking-brasil-certificate-standards-1_ID1.html
@@ -1109,6 +1109,11 @@
 </dl>
 </div>
 <h1 id="title">Open Banking Brasil Certificate Standards 1.0</h1>
+<div>
+<h1>The english version of this document is Outdated</h1>
+Please refer to the portuguese version for up to date information:<br>
+<a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html">https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html</a>
+</div>
 <section class="note" id="section-note.1">
       <h2 id="name-foreword">
 <a href="#name-foreword" class="section-name selfRef">Foreword</a>
diff --git a/open-banking-brasil-certificate-standards-1_ID1.md b/open-banking-brasil-certificate-standards-1_ID1.md
index bbba170..98c6a2e 100644
--- a/open-banking-brasil-certificate-standards-1_ID1.md
+++ b/open-banking-brasil-certificate-standards-1_ID1.md
@@ -48,6 +48,10 @@
       uri = "https://openbankingbrasil.org.br/"
 %%%
 
+# The English version of this document is Outdated
+Please refer to the portuguese version for up to date information:
+>[https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html)
+
 .# Foreword
 
 Este documento também está disponível em [português](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1-ptbr.html).
diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.md b/open-banking-brasil-dynamic-client-registration-1_ID2.md
index 65eea56..b12feca 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.md
@@ -39,6 +39,10 @@
 
 %%%
 
+# The English version of this document is Outdated
+Please refer to the portuguese version for up to date information:
+>[https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html)
+
 .# Foreword
 
 Este documento também está disponível em [português](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html)

From f83f798a6680ca0dbda12ae43ff3263e8cfde72b Mon Sep 17 00:00:00 2001
From: JOAO RODOLFO <joao.rodolfo+github@gmail.com>
Date: Thu, 28 Oct 2021 14:09:00 -0300
Subject: [PATCH 09/59] =?UTF-8?q?Delibera=C3=A7=C3=A3o=20no=20GET=20-=20SE?=
 =?UTF-8?q?G=20e=20Erro=20de=20Digita=C3=A7=C3=A3o?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Conforme sugestão do GT Seg, segue pedido de atualização do Texto.
Segue na tabela abaixo como deve ser feita a decodificação:
- Obtenha na ordem reversa os atributos do certificado
- Concatene cada RDN (RelativeDistinguishedName) com uma virgula (',')
- Use as strings da RFC (CN, L, ST, O, OU, C, Street, DC, UID) + os nomes dos atributos definidos nesta especificação para uso no OBB (businessCategory, jurisdictionCountryName , serialNumber)

________________________________________________________________________________________________________________________________________________
Ajuste na tabela para corrigir o erro de digitação conforme a Issue:
https://github.com/OpenBanking-Brasil/specs-seguranca/issues/207
---
 ...king-brasil-dynamic-client-registration-1_ID2-ptbr.md | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
index f77ca8e..2045753 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
@@ -252,21 +252,22 @@ A cláusula 3 do [Lightweight Directory Access Protocol (LDAP): String Represent
 
 Para resolver essa ambigüidade, o Servidor de Autorização deve aceitar todas as strings de nome de AttributeType (descritores) definidas no último parágrafo da cláusula 3 [RFC4514], além de todos os AttributeTypes definidos no Distinguished Name [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards].
 
-Segue na tabela abaixo alguns exemplos de decodificação:
+Segue na tabela abaixo como deve ser feita a decodificação:
 
 - Obtenha na ordem reversa os atributos do certificado
 - Concatene cada RDN (RelativeDistinguishedName) com uma virgula (',')
 - Use as strings da RFC (CN, L, ST, O, OU, C, Street, DC, UID) + os nomes dos atributos definidos nesta especificação para uso no OBB (businessCategory, jurisdictionCountryName , serialNumber)
 
-Exemplos:
+Seguem abaixo exemplos para os atributos obrigatórios da CAs atualmente ativas:
 
 | subject_dn | Issuer |
 | --- | --- |
 | UID=67c57882-043b-11ec-9a03-0242ac130003,jurisdictionCountryName=BR,businessCategory=Private      Organization,serialNumber=00038166000954,CN=mycn.bank.com.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=MY BANK SA,L=SAO PAULO,ST=SP,C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
-| UID=67c57882-043b-11ec-9a03-0242ac130003,   jurisdictionCountryName=BR,businessCategory=Business Entity,CN=mycn.bank.gov.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR,jurisdictionCountryName=BR,businessCategory=Private |
-| Organization,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003,   jurisdictionCountryName=BR,businessCategory=Business Entity,CN=mycn.bank.gov.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| jurisdictionCountryName=BR,businessCategory=Private Organization,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
 | CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao   Paulo,ST=SP,O=MyBank SA,C=BR,serialNumber=00038166000954,   jurisdictionCountryName=BR,businessCategory=Private   Organization | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
 
+
 ## Funções regulatórias para mapeamentos OpenID e OAuth 2.0  {#Regs}
 
 Para participar do ecossistema do Open Banking, as instituições credenciadas devem se cadastrar no Diretório de Participantes de acordo com seus papéis regulatórios. Essas funções refletem a autorização do Banco Central para as instituições e, consequentemente, as APIs que podem utilizar.

From 79e357abdc11d2e96ae0fb95da57513a3d952c65 Mon Sep 17 00:00:00 2001
From: Marcos Rodrigues <83780271+DeiGratia33@users.noreply.github.com>
Date: Fri, 5 Nov 2021 12:18:11 -0300
Subject: [PATCH 10/59] CIBA: Request expiration time

Definition of expiration time for request (Proposal)
---
 open-banking-brasil-financial-api-CIBA-1_ID1.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/open-banking-brasil-financial-api-CIBA-1_ID1.md b/open-banking-brasil-financial-api-CIBA-1_ID1.md
index acce2b1..0127a99 100644
--- a/open-banking-brasil-financial-api-CIBA-1_ID1.md
+++ b/open-banking-brasil-financial-api-CIBA-1_ID1.md
@@ -259,7 +259,7 @@ As described in [FAPI-CIBA], there are many mechanisms that can be used to conve
 `
 
 The use of a `binding message` is *not* mandatory if this token type is to be leveraged.
-//TODO: How long should the request expiry be in this scenario???
+The requested_expiry shall be greater than 3600 seconds and less than 43200 seconds
 
 ##### Authorisation Server Generated - Login Hint Token
 

From f862b24e3758607786c44bb563d6727dbeb0ed16 Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Fri, 5 Nov 2021 15:44:42 -0300
Subject: [PATCH 11/59] =?UTF-8?q?Adequa=C3=A7=C3=B5es=20item=2032=20Task?=
 =?UTF-8?q?=20Force=20Fase=203?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...-dynamic-client-registration-1_ID2-ptbr.md | 24 ++++++++++++++-----
 ...rasil-dynamic-client-registration-1_ID2.md | 17 ++++++++-----
 ...banking-brasil-financial-api-1_ID3-ptbr.md |  5 ++++
 open-banking-brasil-financial-api-1_ID3.md    |  4 ++++
 4 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
index 2045753..c525bbf 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
@@ -235,6 +235,8 @@ Além disso, o servidor de autorização
 10. deve, sempre que possível, validar os metadados declarados pelo cliente em relação aos metadados fornecidos no _software\_statement_, adotando os valores presentes no SSA com precedência.
 11. deve aceitar todos os nomes x.500 AttributeType definidas no _Distinguished Name_ dos Perfis de Certificado x.509 definidos em [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards];
 12. se for compatível com o mecanismo de autenticação do cliente `tls_client_auth`, conforme definido em [RFC8705], somente deve aceitar `tls_client_auth_subject_dn` como uma indicação do valor do atributo _subject_ do certificado, conforme definido na cláusula 2.1.2 [RFC8705];
+13. Os valores dos campos UID e OU do certificado devem coincidir com os enviados no SSA. O campo OU deve conter o valor do campo org_id do SSA e campo UID deve conter o valor do campo software_id do SSA.
+
 
 Estas disposições aplicam-se igualmente ao processamento de pedidos [RFC7591], [RFC7592] e [OpenID Registration][OIDR]
 
@@ -250,22 +252,28 @@ Quando as propriedades de uma solicitação DCR não estão incluídas e não s
 
 A cláusula 3 do [Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names][RFC4514] define os OIDs obrigatórios cujas as _strings_ do AttributeType (descritores) devem ser reconhecidos pelos implementadores. Esta lista obrigatória não inclui vários dos OIDs definidos em [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards], nem existe um mecanismo definido para os Servidores de Autorização publicarem informações sobre o formato que eles esperam de uma Solicitação Dinâmica de Registro do Cliente (_Dynamic Client Registrarion_) que inclui um `tls_client_auth_subject_dn`.
 
-Para resolver essa ambigüidade, o Servidor de Autorização deve aceitar todas as strings de nome de AttributeType (descritores) definidas no último parágrafo da cláusula 3 [RFC4514], além de todos os AttributeTypes definidos no Distinguished Name [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards].
+Para resolver essa ambigüidade, o Servidor de Autorização deve aceitar exckusivamente os AttributeType (descritores) definidas no último parágrafo da cláusula 3 [RFC4514] em formato string,  também deve aceitar em formato OID, com seus valores em ASN.1, todos os AttributeTypes definidos no Distinguished Name [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] ou adicionados pela Autoridade Certificadora.
+
+Em caso de não atendimento destes requisitos o Servidor de Autorização deverá rejeitar o registro.
 
 Segue na tabela abaixo como deve ser feita a decodificação:
 
 - Obtenha na ordem reversa os atributos do certificado
 - Concatene cada RDN (RelativeDistinguishedName) com uma virgula (',')
-- Use as strings da RFC (CN, L, ST, O, OU, C, Street, DC, UID) + os nomes dos atributos definidos nesta especificação para uso no OBB (businessCategory, jurisdictionCountryName , serialNumber)
+- Use as strings da RFC (CN, L, ST, O, OU, C, Street, DC, UID) com o valor dos seus atribudos em "printable string", ou seja legível para humanos + os OIDs dos atributos definidos nesta especificação para uso no OBB (businessCategory=OID 2.5.4.15,jurisdictionCountryName=OID: 1.3.6.1.4.1.311.60.2.1.3, serialNumber=2.5.4.5) com o valor dos seus atribudos em formato ASN.1”
 
 Seguem abaixo exemplos para os atributos obrigatórios da CAs atualmente ativas:
 
 | subject_dn | Issuer |
 | --- | --- |
-| UID=67c57882-043b-11ec-9a03-0242ac130003,jurisdictionCountryName=BR,businessCategory=Private      Organization,serialNumber=00038166000954,CN=mycn.bank.com.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=MY BANK SA,L=SAO PAULO,ST=SP,C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
-| UID=67c57882-043b-11ec-9a03-0242ac130003,   jurisdictionCountryName=BR,businessCategory=Business Entity,CN=mycn.bank.gov.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| jurisdictionCountryName=BR,businessCategory=Private Organization,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao   Paulo,ST=SP,O=MyBank SA,C=BR,serialNumber=00038166000954,   jurisdictionCountryName=BR,businessCategory=Private   Organization | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003,1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839,CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L= BRASILIA,ST=DF,C=BR
+ | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,CN=mycn.bank.gov.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR
+ | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR
+ | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao Paulo,ST=SP,O=MyBank SA,C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e
+ | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
 
 
 ## Funções regulatórias para mapeamentos OpenID e OAuth 2.0  {#Regs}
@@ -281,6 +289,10 @@ A tabela a seguir descreve as funções regulatórias do Open Banking e o mapeam
 | CONTA | Instituição detentora de conta (ASPSP) | openid | Phase 3 |
 | CCORR | Correspondente de crédito | openid | Phase 3* |
 
+## Cliente
+
+No processo de registro do cliente, utilizando-se o método de autenticação *tls_client_auth*, o cliente deve encaminhar o campo *tls_client_auth_subject_dn* com os AttibuteTypes(Descritores) em formato definido no item 7.1.2. Em caso de não aderencia a este padrão o registro será rejeitado.
+
 # Declaração de Software  {#SSA}
 
 Uma declaração de software (_software\_statement_) é um JSON Web Token (JWT) [RFC7519] que afirma valores de metadados sobre o software cliente como um todo. Na estrutura do Open Banking Brasil, esse _software\_statement_ é assinado pelo Diretório de Participantes, e sua assinatura DEVE ser validada pelos Servidores de Autorizacao usando as chaves públicas disponíveis na seção a seguir.
diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.md b/open-banking-brasil-dynamic-client-registration-1_ID2.md
index b12feca..87965fc 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.md
@@ -237,6 +237,7 @@ In addition, the Authorization Server
 10. should where possible validate client asserted metadata against metadata provided in the software_statement;
 11. shall accept all x.500 AttributeType name strings defined in the Distinguished Name of the x.509 Certificate Profiles defined in [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards];
 12. if supporting `tls_client_auth` client authentication mechanism as defined in [RFC8705] shall only accept `tls_client_auth_subject_dn`  as an indication of the certificate subject value as defined in clause 2.1.2 [RFC8705];
+13. The values of the *UID* and *OU* fields of the certificate must match those sent in the SSA. The *OU* field must contain the value of the SSA *org_id* field and the *UID* field must contain the value of the SSA *software_id* field.
 
 These provisions apply equally to the processing of [RFC7591], [RFC7592] and [OpenID Registration][OIDR] requests
 
@@ -252,22 +253,26 @@ Where properties of a DCR request are not included and are not mandatory in the
 
 Clause 3 of [Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names][RFC4514] defines the mandatory OIDs whose AttributeType strings (descriptors) must be recognized by implementers. This mandatory list does not include several of the OIDs defined in [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] nor is there a defined mechanism for Authorisation Servers to publish  information regarding the format that they would expect a Dynamic Client Registration request that includes a `tls_client_auth_subject_dn` to be presented in.
 
-To address this ambiguity, the Authorization Server must accept all AttributeType name strings (descriptors) defined in the last paragraph of clause 3 [RFC4514] in addition to all of the AttributeTypes defined in the Distinguished Name of the [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards].
+To address this ambiguity, the Authorization Server must only accept the AttributeTypes (descriptors) defined in the last paragraph of clause 3 [RFC4514] in string format, it must also accept in OID format, with their values in ASN.1, all the AttributeTypes defined in Distinguished Name [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] or added by the Certificate Authority.
 
 In terms of format, the Security WG have defined the examples in bellow:
 
 - Start backwards, the order is reversed from what is entered.
 - Append each RDN (RelativeDistinguishedName) segment with a comma ‘,’
-- Use RFC Strings (CN, L, ST, O, OU, C, Street, DC, UID) + OBB Certificate Specs (businessCategory, jurisdictionCountryName , serialNumber)
+- Use the RFC strings (CN, L, ST, O, OR, C, Street, DC, UID) with the value of their attributes in "printable string", ie human readable + the OIDs of the attributes defined in this specification for use in Distinguished Name [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] (businessCategory=OID 2.5.4.15,jurisdictionCountryName=OID: 1.3.6.1.4.1.311.60.2.1.3, serialNumber=2.5.4.5) with the value of your attributes in ASN.1 format
 
 Examples:
 
 | subject_dn | Issuer |
 | --- | --- |
-| UID=67c57882-043b-11ec-9a03-0242ac130003,jurisdictionCountryName=BR,businessCategory=Private      Organization,serialNumber=00038166000954,CN=mycn.bank.com.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=MY BANK SA,L=SAO PAULO,ST=SP,C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
-| UID=67c57882-043b-11ec-9a03-0242ac130003,   jurisdictionCountryName=BR,businessCategory=Business Entity,CN=mycn.bank.gov.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR,jurisdictionCountryName=BR,businessCategory=Private |
-| Organization,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao   Paulo,ST=SP,O=MyBank SA,C=BR,serialNumber=00038166000954,   jurisdictionCountryName=BR,businessCategory=Private   Organization | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003,1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839,CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L= BRASILIA,ST=DF,C=BR
+ | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,CN=mycn.bank.gov.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR
+ | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR
+ | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao Paulo,ST=SP,O=MyBank SA,C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e
+ | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
 
 ## Regulatory Roles to OpenID and OAuth 2.0 Mappings
 
diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.md b/open-banking-brasil-financial-api-1_ID3-ptbr.md
index 7a83bde..b9cb1a2 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.md
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.md
@@ -361,6 +361,11 @@ Para TLS, endpoints do Servidor de Autenticação e endpoints do Servidor de Rec
 1. devem suportar `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
 2. devem suportar `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
 
+## Considerações sobre a validação do cliente mTLS
+
+No momento de autenticação, pelo método *tls_client_auth*, deve ser validado que os campos *UID* e *OU* apresentados no certificado coincidem com os valores informados no campo *tls_client_auth_subject_dn*.
+
+
 # Considerações sobre compartilhamento de dados  {#dados}
 
 ## Mecanismo de Autorização  {#authmech}
diff --git a/open-banking-brasil-financial-api-1_ID3.md b/open-banking-brasil-financial-api-1_ID3.md
index ff7bff6..f4ddc46 100644
--- a/open-banking-brasil-financial-api-1_ID3.md
+++ b/open-banking-brasil-financial-api-1_ID3.md
@@ -378,6 +378,10 @@ For TLS, Authorization Server endpoints and Resource Server endpoints used direc
 1. shall support `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
 2. shall support `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
 
+## mTLS client validation considerations
+
+At the time of authentication, using the *tls_client_auth* method, it must be validated that the *UID* and *OU* fields present at the certificate matches the values in the *tls_client_auth_subject_dn* field.
+
 # Data Sharing Considerations
 
 ## Authorisation Mechanism

From b6bcaa9bfc0ce90789f74465bfc326096bccdbe6 Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Fri, 5 Nov 2021 15:50:00 -0300
Subject: [PATCH 12/59] =?UTF-8?q?corre=C3=A7=C3=A3o=20de=20link=20desatual?=
 =?UTF-8?q?izado?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md | 4 ++--
 open-banking-brasil-dynamic-client-registration-1_ID2.md      | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
index c525bbf..1ee9c85 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
@@ -41,7 +41,7 @@
 
 .# Prefácio  {#Forward}
 
-The normative version in [English](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1.html)
+The normative version in [English](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html)
 
 A Estrutura Inicial do Open Banking Brasil (EIOBB) é responsável por criar os padrões e especificações necessários para atender aos requisitos e obrigações da Legislação do Open Banking do Brasil, conforme originalmente delineado pelo [Banco Central do Brasil](https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf). É possível que alguns dos elementos deste documento estejam sujeitos a direitos de patente. O EIOBB não se responsabiliza pela identificação de qualquer ou todos os direitos de patente.
 
@@ -235,7 +235,7 @@ Além disso, o servidor de autorização
 10. deve, sempre que possível, validar os metadados declarados pelo cliente em relação aos metadados fornecidos no _software\_statement_, adotando os valores presentes no SSA com precedência.
 11. deve aceitar todos os nomes x.500 AttributeType definidas no _Distinguished Name_ dos Perfis de Certificado x.509 definidos em [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards];
 12. se for compatível com o mecanismo de autenticação do cliente `tls_client_auth`, conforme definido em [RFC8705], somente deve aceitar `tls_client_auth_subject_dn` como uma indicação do valor do atributo _subject_ do certificado, conforme definido na cláusula 2.1.2 [RFC8705];
-13. Os valores dos campos UID e OU do certificado devem coincidir com os enviados no SSA. O campo OU deve conter o valor do campo org_id do SSA e campo UID deve conter o valor do campo software_id do SSA.
+13. Os valores dos campos *UID* e *OU* do certificado devem coincidir com os enviados no SSA. O campo *OU* deve conter o valor do campo *org_id* do SSA e campo *UID* deve conter o valor do campo *software_id* do SSA.
 
 
 Estas disposições aplicam-se igualmente ao processamento de pedidos [RFC7591], [RFC7592] e [OpenID Registration][OIDR]
diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.md b/open-banking-brasil-dynamic-client-registration-1_ID2.md
index 87965fc..9ebbc1a 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.md
@@ -45,7 +45,7 @@ Please refer to the portuguese version for up to date information:
 
 .# Foreword
 
-Este documento também está disponível em [português](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html)
+Este documento também está disponível em [português](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html)
 
 The Open Banking Brasil Initial Structure is responsible for creating standards and specifications necessary to meet the requirements and obligations of the Brasil Open Banking Legislation as originally outlined by the [Brasil Central Bank](https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf). There is a possibility that some of the elements of this document may be the subject to patent rights. OBBIS shall not be held responsible for identifying any or all such patent rights.
 

From 5b65eebac0558216c04b0ed6a4737feeec6cefec Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Fri, 5 Nov 2021 15:58:01 -0300
Subject: [PATCH 13/59] Incluso item pendente no DCR em ingles

---
 open-banking-brasil-dynamic-client-registration-1_ID2.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.md b/open-banking-brasil-dynamic-client-registration-1_ID2.md
index 9ebbc1a..ac9cd47 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.md
@@ -298,6 +298,10 @@ In line with guidance from the IETF and the direction of travel for fine-grained
 | DADOS | consent:{ConsentId} |
 | PAGTO | consent:{ConsentId} |
 
+## Client
+
+In the client registration process, using the authentication method *tls_client_auth*, the client must send the field *tls_client_auth_subject_dn* with the AttibuteTypes(Descriptors) in the format defined in item 7.1.2. In case of non-adherence to this standard, the registration will be rejected.
+
 # Software Statement
 
 > A software statement is a JSON Web Token (JWT) [RFC7519] that asserts metadata values about the client software as a bundle.

From cc7d3603414fecd98b0e1feeea2b45aa3e62ef25 Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Fri, 5 Nov 2021 16:00:07 -0300
Subject: [PATCH 14/59] =?UTF-8?q?Corre=C3=A7=C3=A3o=20de=20formata=C3=A7?=
 =?UTF-8?q?=C3=A3o=20das=20tabelas=20de=20exemplo?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...-brasil-dynamic-client-registration-1_ID2-ptbr.md | 12 ++++--------
 ...nking-brasil-dynamic-client-registration-1_ID2.md | 12 ++++--------
 2 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
index 1ee9c85..b0f80d3 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
@@ -266,14 +266,10 @@ Seguem abaixo exemplos para os atributos obrigatórios da CAs atualmente ativas:
 
 | subject_dn | Issuer |
 | --- | --- |
-| UID=67c57882-043b-11ec-9a03-0242ac130003,1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839,CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L= BRASILIA,ST=DF,C=BR
- | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
-| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,CN=mycn.bank.gov.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR
- | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR
- | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao Paulo,ST=SP,O=MyBank SA,C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e
- | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003,1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839,CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L= BRASILIA,ST=DF,C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,CN=mycn.bank.gov.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao Paulo,ST=SP,O=MyBank SA,C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
 
 
 ## Funções regulatórias para mapeamentos OpenID e OAuth 2.0  {#Regs}
diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.md b/open-banking-brasil-dynamic-client-registration-1_ID2.md
index ac9cd47..34d647f 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.md
@@ -265,14 +265,10 @@ Examples:
 
 | subject_dn | Issuer |
 | --- | --- |
-| UID=67c57882-043b-11ec-9a03-0242ac130003,1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839,CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L= BRASILIA,ST=DF,C=BR
- | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
-| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,CN=mycn.bank.gov.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR
- | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR
- | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao Paulo,ST=SP,O=MyBank SA,C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e
- | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003,1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839,CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L= BRASILIA,ST=DF,C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,CN=mycn.bank.gov.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao Paulo,ST=SP,O=MyBank SA,C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
 
 ## Regulatory Roles to OpenID and OAuth 2.0 Mappings
 

From 6b8e546ea11e14acb8e04e16fa3ec294969f6442 Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Mon, 8 Nov 2021 14:41:54 -0300
Subject: [PATCH 15/59] Ajuste de formatacao de tabela

---
 open-banking-brasil-dynamic-client-registration-1_ID2.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.md b/open-banking-brasil-dynamic-client-registration-1_ID2.md
index 34d647f..dfaf60c 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.md
@@ -265,10 +265,10 @@ Examples:
 
 | subject_dn | Issuer |
 | --- | --- |
-| UID=67c57882-043b-11ec-9a03-0242ac130003,1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839,CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L= BRASILIA,ST=DF,C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
-| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,CN=mycn.bank.gov.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao Paulo,ST=SP,O=MyBank SA,C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839, CN= mycn.bank.gov.br, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L= BRASILIA,ST=DF, C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, CN=mycn.bank.gov.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L=BRASILIA, ST=DF, C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, UID=67c57882-043b-11ec-9a03-0242ac130003, CN=openbanking.mybank.com.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Goiania, ST=GO, O=MyBank SA, C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| CN=mycn.bank.com.br, UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Sao Paulo, ST=SP, O=MyBank SA, C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
 
 ## Regulatory Roles to OpenID and OAuth 2.0 Mappings
 

From 491dfe4d2d330e5630a8c049b1f6b44116c9e5ee Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Mon, 8 Nov 2021 14:44:53 -0300
Subject: [PATCH 16/59] Ajuste de formatacao de tabela

---
 ...nking-brasil-dynamic-client-registration-1_ID2-ptbr.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
index b0f80d3..e42d0ac 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
@@ -266,10 +266,10 @@ Seguem abaixo exemplos para os atributos obrigatórios da CAs atualmente ativas:
 
 | subject_dn | Issuer |
 | --- | --- |
-| UID=67c57882-043b-11ec-9a03-0242ac130003,1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839,CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L= BRASILIA,ST=DF,C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
-| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,CN=mycn.bank.gov.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,2.5.4.5=#130d31333335333233363030313839,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao Paulo,ST=SP,O=MyBank SA,C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839, CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L= BRASILIA, ST=DF, C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, CN=mycn.bank.gov.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L=BRASILIA, ST=DF, C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, UID=67c57882-043b-11ec-9a03-0242ac130003, CN=openbanking.mybank.com.br,2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Goiania, ST=GO, O=MyBank SA, C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| CN=mycn.bank.com.br, UID=67c57882-043b-11ec-9a03-0242ac130003, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Sao Paulo, ST=SP, O=MyBank SA, C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
 
 
 ## Funções regulatórias para mapeamentos OpenID e OAuth 2.0  {#Regs}

From 5614afc15ce26ad8ea96f5cdbd95934eeeb4d7ee Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Mon, 8 Nov 2021 14:57:47 -0300
Subject: [PATCH 17/59] =?UTF-8?q?Remo=C3=A7=C3=A3o=20do=20requisito=20de?=
 =?UTF-8?q?=20valida=C3=A7=C3=A3o=20do=20OU=20e=20UID=20no=20perfil=20de?=
 =?UTF-8?q?=20seguran=C3=A7a=20Ser=C3=A1=20feita=20valida=C3=A7=C3=A3o=20d?=
 =?UTF-8?q?e=20string=20conforme=20padr=C3=A3o=20RFC8705=20Tamb=C3=A9m=20c?=
 =?UTF-8?q?orrigidos=20dois=20erros=20de=20digita=C3=A7=C3=A3o?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...banking-brasil-dynamic-client-registration-1_ID2-ptbr.md | 6 +++---
 open-banking-brasil-financial-api-1_ID3-ptbr.md             | 4 ----
 open-banking-brasil-financial-api-1_ID3.md                  | 4 ----
 3 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
index e42d0ac..5dae867 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
@@ -252,7 +252,7 @@ Quando as propriedades de uma solicitação DCR não estão incluídas e não s
 
 A cláusula 3 do [Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names][RFC4514] define os OIDs obrigatórios cujas as _strings_ do AttributeType (descritores) devem ser reconhecidos pelos implementadores. Esta lista obrigatória não inclui vários dos OIDs definidos em [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards], nem existe um mecanismo definido para os Servidores de Autorização publicarem informações sobre o formato que eles esperam de uma Solicitação Dinâmica de Registro do Cliente (_Dynamic Client Registrarion_) que inclui um `tls_client_auth_subject_dn`.
 
-Para resolver essa ambigüidade, o Servidor de Autorização deve aceitar exckusivamente os AttributeType (descritores) definidas no último parágrafo da cláusula 3 [RFC4514] em formato string,  também deve aceitar em formato OID, com seus valores em ASN.1, todos os AttributeTypes definidos no Distinguished Name [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] ou adicionados pela Autoridade Certificadora.
+Para resolver essa ambigüidade, o Servidor de Autorização deve aceitar exclusivamente os AttributeType (descritores) definidas no último parágrafo da cláusula 3 [RFC4514] em formato string,  também deve aceitar em formato OID, com seus valores em ASN.1, todos os AttributeTypes definidos no Distinguished Name [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] ou adicionados pela Autoridade Certificadora.
 
 Em caso de não atendimento destes requisitos o Servidor de Autorização deverá rejeitar o registro.
 
@@ -260,7 +260,7 @@ Segue na tabela abaixo como deve ser feita a decodificação:
 
 - Obtenha na ordem reversa os atributos do certificado
 - Concatene cada RDN (RelativeDistinguishedName) com uma virgula (',')
-- Use as strings da RFC (CN, L, ST, O, OU, C, Street, DC, UID) com o valor dos seus atribudos em "printable string", ou seja legível para humanos + os OIDs dos atributos definidos nesta especificação para uso no OBB (businessCategory=OID 2.5.4.15,jurisdictionCountryName=OID: 1.3.6.1.4.1.311.60.2.1.3, serialNumber=2.5.4.5) com o valor dos seus atribudos em formato ASN.1”
+- Use as strings da RFC (CN, L, ST, O, OU, C, Street, DC, UID) com o valor dos seus atribudos em "printable string", ou seja legível para humanos + os OIDs dos atributos definidos nesta especificação para uso no OBB (businessCategory=OID 2.5.4.15,jurisdictionCountryName=OID: 1.3.6.1.4.1.311.60.2.1.3, serialNumber=2.5.4.5) com o valor dos seus atributos em formato ASN.1”
 
 Seguem abaixo exemplos para os atributos obrigatórios da CAs atualmente ativas:
 
@@ -268,7 +268,7 @@ Seguem abaixo exemplos para os atributos obrigatórios da CAs atualmente ativas:
 | --- | --- |
 | UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839, CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L= BRASILIA, ST=DF, C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
 | UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, CN=mycn.bank.gov.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L=BRASILIA, ST=DF, C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, UID=67c57882-043b-11ec-9a03-0242ac130003, CN=openbanking.mybank.com.br,2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Goiania, ST=GO, O=MyBank SA, C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, UID=67c57882-043b-11ec-9a03-0242ac130003, CN=openbanking.mybank.com.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Goiania, ST=GO, O=MyBank SA, C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
 | CN=mycn.bank.com.br, UID=67c57882-043b-11ec-9a03-0242ac130003, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Sao Paulo, ST=SP, O=MyBank SA, C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
 
 
diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.md b/open-banking-brasil-financial-api-1_ID3-ptbr.md
index b9cb1a2..e599e65 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.md
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.md
@@ -361,10 +361,6 @@ Para TLS, endpoints do Servidor de Autenticação e endpoints do Servidor de Rec
 1. devem suportar `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
 2. devem suportar `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
 
-## Considerações sobre a validação do cliente mTLS
-
-No momento de autenticação, pelo método *tls_client_auth*, deve ser validado que os campos *UID* e *OU* apresentados no certificado coincidem com os valores informados no campo *tls_client_auth_subject_dn*.
-
 
 # Considerações sobre compartilhamento de dados  {#dados}
 
diff --git a/open-banking-brasil-financial-api-1_ID3.md b/open-banking-brasil-financial-api-1_ID3.md
index f4ddc46..ff7bff6 100644
--- a/open-banking-brasil-financial-api-1_ID3.md
+++ b/open-banking-brasil-financial-api-1_ID3.md
@@ -378,10 +378,6 @@ For TLS, Authorization Server endpoints and Resource Server endpoints used direc
 1. shall support `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
 2. shall support `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
 
-## mTLS client validation considerations
-
-At the time of authentication, using the *tls_client_auth* method, it must be validated that the *UID* and *OU* fields present at the certificate matches the values in the *tls_client_auth_subject_dn* field.
-
 # Data Sharing Considerations
 
 ## Authorisation Mechanism

From 2774eeb186adcce0aa80c03ef3630f5812b01b91 Mon Sep 17 00:00:00 2001
From: rafael-hashimoto <89614766+rafael-hashimoto@users.noreply.github.com>
Date: Mon, 8 Nov 2021 15:03:45 -0300
Subject: [PATCH 18/59] Update
 open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md

---
 open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
index 5dae867..5942eef 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
@@ -252,7 +252,7 @@ Quando as propriedades de uma solicitação DCR não estão incluídas e não s
 
 A cláusula 3 do [Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names][RFC4514] define os OIDs obrigatórios cujas as _strings_ do AttributeType (descritores) devem ser reconhecidos pelos implementadores. Esta lista obrigatória não inclui vários dos OIDs definidos em [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards], nem existe um mecanismo definido para os Servidores de Autorização publicarem informações sobre o formato que eles esperam de uma Solicitação Dinâmica de Registro do Cliente (_Dynamic Client Registrarion_) que inclui um `tls_client_auth_subject_dn`.
 
-Para resolver essa ambigüidade, o Servidor de Autorização deve aceitar exclusivamente os AttributeType (descritores) definidas no último parágrafo da cláusula 3 [RFC4514] em formato string,  também deve aceitar em formato OID, com seus valores em ASN.1, todos os AttributeTypes definidos no Distinguished Name [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] ou adicionados pela Autoridade Certificadora.
+Para resolver essa ambiguidade, o Servidor de Autorização deve aceitar exclusivamente os AttributeType (descritores) definidas no último parágrafo da cláusula 3 [RFC4514] em formato string,  também deve aceitar em formato OID, com seus valores em ASN.1, todos os AttributeTypes definidos no Distinguished Name [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] ou adicionados pela Autoridade Certificadora.
 
 Em caso de não atendimento destes requisitos o Servidor de Autorização deverá rejeitar o registro.
 

From e0399baf692e2fa8f6810db8626d6713fbaf6563 Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Mon, 8 Nov 2021 15:06:34 -0300
Subject: [PATCH 19/59] Ajuste link do documento de DCR para ID2 no Swagger

---
 dcr_review/dcr-dcm-swagger.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dcr_review/dcr-dcm-swagger.yaml b/dcr_review/dcr-dcm-swagger.yaml
index aacff5c..8186b36 100644
--- a/dcr_review/dcr-dcm-swagger.yaml
+++ b/dcr_review/dcr-dcm-swagger.yaml
@@ -7,7 +7,7 @@ info:
   version: 1.0.0
 externalDocs:
   description: Documentação do processo de DCR / DCM no portal do desenvolvedor do Open Banking Brasil
-  url: https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-dynamic-client-registration-1_ID1.md
+  url: https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-dynamic-client-registration-1_ID2.md
 tags:
 - name: DCR
   description: Operações de registro dinâmico de cliente (DCR)

From 1aee52f4f25208ddf2903b4666ffd7a5c7553d50 Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Mon, 8 Nov 2021 15:32:06 -0300
Subject: [PATCH 20/59] restore english version

---
 ...rasil-dynamic-client-registration-1_ID2.md | 19 +++++++------------
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.md b/open-banking-brasil-dynamic-client-registration-1_ID2.md
index dfaf60c..b12feca 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.md
@@ -45,7 +45,7 @@ Please refer to the portuguese version for up to date information:
 
 .# Foreword
 
-Este documento também está disponível em [português](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html)
+Este documento também está disponível em [português](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html)
 
 The Open Banking Brasil Initial Structure is responsible for creating standards and specifications necessary to meet the requirements and obligations of the Brasil Open Banking Legislation as originally outlined by the [Brasil Central Bank](https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf). There is a possibility that some of the elements of this document may be the subject to patent rights. OBBIS shall not be held responsible for identifying any or all such patent rights.
 
@@ -237,7 +237,6 @@ In addition, the Authorization Server
 10. should where possible validate client asserted metadata against metadata provided in the software_statement;
 11. shall accept all x.500 AttributeType name strings defined in the Distinguished Name of the x.509 Certificate Profiles defined in [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards];
 12. if supporting `tls_client_auth` client authentication mechanism as defined in [RFC8705] shall only accept `tls_client_auth_subject_dn`  as an indication of the certificate subject value as defined in clause 2.1.2 [RFC8705];
-13. The values of the *UID* and *OU* fields of the certificate must match those sent in the SSA. The *OU* field must contain the value of the SSA *org_id* field and the *UID* field must contain the value of the SSA *software_id* field.
 
 These provisions apply equally to the processing of [RFC7591], [RFC7592] and [OpenID Registration][OIDR] requests
 
@@ -253,22 +252,22 @@ Where properties of a DCR request are not included and are not mandatory in the
 
 Clause 3 of [Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names][RFC4514] defines the mandatory OIDs whose AttributeType strings (descriptors) must be recognized by implementers. This mandatory list does not include several of the OIDs defined in [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] nor is there a defined mechanism for Authorisation Servers to publish  information regarding the format that they would expect a Dynamic Client Registration request that includes a `tls_client_auth_subject_dn` to be presented in.
 
-To address this ambiguity, the Authorization Server must only accept the AttributeTypes (descriptors) defined in the last paragraph of clause 3 [RFC4514] in string format, it must also accept in OID format, with their values in ASN.1, all the AttributeTypes defined in Distinguished Name [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] or added by the Certificate Authority.
+To address this ambiguity, the Authorization Server must accept all AttributeType name strings (descriptors) defined in the last paragraph of clause 3 [RFC4514] in addition to all of the AttributeTypes defined in the Distinguished Name of the [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards].
 
 In terms of format, the Security WG have defined the examples in bellow:
 
 - Start backwards, the order is reversed from what is entered.
 - Append each RDN (RelativeDistinguishedName) segment with a comma ‘,’
-- Use the RFC strings (CN, L, ST, O, OR, C, Street, DC, UID) with the value of their attributes in "printable string", ie human readable + the OIDs of the attributes defined in this specification for use in Distinguished Name [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] (businessCategory=OID 2.5.4.15,jurisdictionCountryName=OID: 1.3.6.1.4.1.311.60.2.1.3, serialNumber=2.5.4.5) with the value of your attributes in ASN.1 format
+- Use RFC Strings (CN, L, ST, O, OU, C, Street, DC, UID) + OBB Certificate Specs (businessCategory, jurisdictionCountryName , serialNumber)
 
 Examples:
 
 | subject_dn | Issuer |
 | --- | --- |
-| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839, CN= mycn.bank.gov.br, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L= BRASILIA,ST=DF, C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
-| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, CN=mycn.bank.gov.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L=BRASILIA, ST=DF, C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, UID=67c57882-043b-11ec-9a03-0242ac130003, CN=openbanking.mybank.com.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Goiania, ST=GO, O=MyBank SA, C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| CN=mycn.bank.com.br, UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Sao Paulo, ST=SP, O=MyBank SA, C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003,jurisdictionCountryName=BR,businessCategory=Private      Organization,serialNumber=00038166000954,CN=mycn.bank.com.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=MY BANK SA,L=SAO PAULO,ST=SP,C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003,   jurisdictionCountryName=BR,businessCategory=Business Entity,CN=mycn.bank.gov.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR,jurisdictionCountryName=BR,businessCategory=Private |
+| Organization,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao   Paulo,ST=SP,O=MyBank SA,C=BR,serialNumber=00038166000954,   jurisdictionCountryName=BR,businessCategory=Private   Organization | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
 
 ## Regulatory Roles to OpenID and OAuth 2.0 Mappings
 
@@ -294,10 +293,6 @@ In line with guidance from the IETF and the direction of travel for fine-grained
 | DADOS | consent:{ConsentId} |
 | PAGTO | consent:{ConsentId} |
 
-## Client
-
-In the client registration process, using the authentication method *tls_client_auth*, the client must send the field *tls_client_auth_subject_dn* with the AttibuteTypes(Descriptors) in the format defined in item 7.1.2. In case of non-adherence to this standard, the registration will be rejected.
-
 # Software Statement
 
 > A software statement is a JSON Web Token (JWT) [RFC7519] that asserts metadata values about the client software as a bundle.

From db1e71787322afec16b23ffaae205b213d41ce01 Mon Sep 17 00:00:00 2001
From: rafael-hashimoto <89614766+rafael-hashimoto@users.noreply.github.com>
Date: Mon, 8 Nov 2021 15:33:43 -0300
Subject: [PATCH 21/59] Update open-banking-brasil-financial-api-1_ID3-ptbr.md

---
 open-banking-brasil-financial-api-1_ID3-ptbr.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.md b/open-banking-brasil-financial-api-1_ID3-ptbr.md
index e599e65..7a83bde 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.md
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.md
@@ -361,7 +361,6 @@ Para TLS, endpoints do Servidor de Autenticação e endpoints do Servidor de Rec
 1. devem suportar `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
 2. devem suportar `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
 
-
 # Considerações sobre compartilhamento de dados  {#dados}
 
 ## Mecanismo de Autorização  {#authmech}

From 0c1ca1fcbebcd33fb8c38470b64f1c9f06ec1f1e Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Mon, 8 Nov 2021 15:35:59 -0300
Subject: [PATCH 22/59] Incluido instrucao para atualizar swagger quando houver
 atualizacao de versao do DCR

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index e413b66..5201f7c 100644
--- a/README.md
+++ b/README.md
@@ -32,7 +32,7 @@ Sempre que for publicado um novo ID de documentação, deve-se atentar a atualiz
 
 |Documento|Referências|
 |------------------------------------------|---------------------------------------------------------------------------------------------------|
-|Registro e Cadastramento Dinâmico do Cliente de APIs|<ul><li>Perfil de Segurança do OpenBanking Brasil</li><li>Padrão de Certificados Open Banking Brasil</li><li>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)</li><li>Áerea do Desenvolvedor do Portal do Open Banking Brasil</li></ul>|
+|Registro e Cadastramento Dinâmico do Cliente de APIs|<ul><li>Perfil de Segurança do OpenBanking Brasil</li><li>Padrão de Certificados Open Banking Brasil</li><li>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)</li><li>Áerea do Desenvolvedor do Portal do Open Banking Brasil</li><li>Swagger com a documentação do DCR</li></ul>|
 |Perfil de Segurança do OpenBanking Brasil|<ul><li>Registro e Cadastramento Dinâmico do Cliente de APIs</li><li>Padrão de Certificados Open Banking Brasil</li><li>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)</li><li>Áerea do Desenvolvedor do Portal do Open Banking Brasil</li></ul>|
 |Padrão de Certificados Open Banking Brasil|<ul><li>Perfil de Segurança do OpenBanking Brasil</li><li>Registro e Cadastramento Dinâmico do Cliente de APIs</li><li>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)</li><li>Áerea do Desenvolvedor do Portal do Open Banking Brasil</li></ul>|
 

From a7d3173a0db5202903d8c80632db4ca6bd017213 Mon Sep 17 00:00:00 2001
From: ediemerson-br <60996132+ediemerson-br@users.noreply.github.com>
Date: Mon, 8 Nov 2021 20:40:14 -0300
Subject: [PATCH 23/59] Update
 open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md

---
 open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
index 5942eef..2daff27 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
@@ -285,9 +285,9 @@ A tabela a seguir descreve as funções regulatórias do Open Banking e o mapeam
 | CONTA | Instituição detentora de conta (ASPSP) | openid | Phase 3 |
 | CCORR | Correspondente de crédito | openid | Phase 3* |
 
-## Cliente
+## Registro do Cliente {#registro_tls_client_auth}
 
-No processo de registro do cliente, utilizando-se o método de autenticação *tls_client_auth*, o cliente deve encaminhar o campo *tls_client_auth_subject_dn* com os AttibuteTypes(Descritores) em formato definido no item 7.1.2. Em caso de não aderencia a este padrão o registro será rejeitado.
+No processo de registro do cliente, utilizando-se o método de autenticação _tls\_client\_auth_, o cliente deve encaminhar o campo _tls\_client\_auth\_subject\_dn_ com os AttibuteTypes(Descritores) em formato definido no item 7.1.2. Em caso de não aderencia a este padrão o registro será rejeitado.
 
 # Declaração de Software  {#SSA}
 

From 9d42f1a10646a33d96c837420d39e77477487d47 Mon Sep 17 00:00:00 2001
From: ediemerson-br <60996132+ediemerson-br@users.noreply.github.com>
Date: Mon, 8 Nov 2021 20:41:31 -0300
Subject: [PATCH 24/59] Add files via upload

---
 ...ynamic-client-registration-1_ID2-ptbr.html | 58 ++++++++++++-------
 1 file changed, 36 insertions(+), 22 deletions(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html
index 630cc4f..550905a 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html
@@ -1068,7 +1068,7 @@
 <thead><tr>
 <td class="left"></td>
 <td class="center">OBB-FAPI-1-DCR-ID2</td>
-<td class="right">October 2021</td>
+<td class="right">November 2021</td>
 </tr></thead>
 <tfoot><tr>
 <td class="left">Bragg & Security</td>
@@ -1085,7 +1085,7 @@
 <dd class="internet-draft">open-banking-brasil-dynamic-client-registration-1_ID2-ptbr</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2021-10-08" class="published">8 October 2021</time>
+<time datetime="2021-11-08" class="published">8 November 2021</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Standards Track</dd>
@@ -1107,14 +1107,12 @@ <h1 id="title">Open Banking Brasil Financial-grade API Dynamic Client Registrati
       <h2 id="name-pref225cio">
 <a href="#name-pref225cio" class="section-name selfRef">Pref&#225;cio</a>
       </h2>
-<!--
-<p id="section-note.1-1">The normative version in <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1.html">English</a><a href="#section-note.1-1" class="pilcrow">¶</a></p>
--->
+<p id="section-note.1-1">The normative version in <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html">English</a><a href="#section-note.1-1" class="pilcrow">¶</a></p>
 <p id="section-note.1-2">A Estrutura Inicial do Open Banking Brasil (EIOBB) &#233; respons&#225;vel por criar os padr&#245;es e especifica&#231;&#245;es necess&#225;rios para atender aos requisitos e obriga&#231;&#245;es da Legisla&#231;&#227;o do Open Banking do Brasil, conforme originalmente delineado pelo <a href="https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf">Banco Central do Brasil</a>. &#201; poss&#237;vel que alguns dos elementos deste documento estejam sujeitos a direitos de patente. O EIOBB n&#227;o se responsabiliza pela identifica&#231;&#227;o de qualquer ou todos os direitos de patente.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
 <p id="section-note.1-3">O Perfil de Seguran&#231;a Financial-grade API 1.0 do Open Banking Brasil consiste nas seguintes partes:<a href="#section-note.1-3" class="pilcrow">¶</a></p>
 <ul class="note">
 <li class="note" id="section-note.1-4.1">
-          <p id="section-note.1-4.1.1"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html">Open Banking Brasil Financial-grade API Security Profile 1.0</a><a href="#section-note.1-4.1.1" class="pilcrow">¶</a></p>
+          <p id="section-note.1-4.1.1"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">Open Banking Brasil Financial-grade API Security Profile 1.0</a><a href="#section-note.1-4.1.1" class="pilcrow">¶</a></p>
 </li>
 <li class="note" id="section-note.1-4.2">
           <p id="section-note.1-4.2.1">Open Banking Brasil Dynamic Client Registration Profile 1.0<a href="#section-note.1-4.2.1" class="pilcrow">¶</a></p>
@@ -1199,6 +1197,9 @@ <h2 id="name-conven231245es-notacionais">
 <li class="toc ulEmpty" id="section-toc.1-1.7.2.2">
                 <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-fun231245es-regulat243rias-" class="xref">Fun&#231;&#245;es regulat&#243;rias para mapeamentos OpenID e OAuth 2.0</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
 </li>
+<li class="toc ulEmpty" id="section-toc.1-1.7.2.3">
+                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-registro-do-cliente" class="xref">Registro do Cliente</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
+</li>
 </ul>
 </li>
 <li class="toc ulEmpty" id="section-toc.1-1.8">
@@ -1295,7 +1296,7 @@ <h2 id="name-refer234ncias-normativas">
 <p id="section-2-19"><a href="https://tools.ietf.org/html/draft-ietf-oauth-jwsreq">JAR</a> - OAuth 2.0 JWT Secured Authorization Request<a href="#section-2-19" class="pilcrow">¶</a></p>
 <p id="section-2-20"><a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">FAPI-1-Baseline</a> - Financial-grade API Security Profile 1.0 - Part 1: Baseline<a href="#section-2-20" class="pilcrow">¶</a></p>
 <p id="section-2-21"><a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">FAPI-1-Advanced</a> - Financial-grade API Security Profile 1.0 - Part 2: Advanced<a href="#section-2-21" class="pilcrow">¶</a></p>
-<p id="section-2-22"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html">OBB-FAPI</a> - Open Banking Brasil Financial-grade API Security Profile 1.0<a href="#section-2-22" class="pilcrow">¶</a></p>
+<p id="section-2-22"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">OBB-FAPI</a> - Open Banking Brasil Financial-grade API Security Profile 1.0<a href="#section-2-22" class="pilcrow">¶</a></p>
 <p id="section-2-23"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">OBB-Cert-Standards</a> - Open Banking Brasil x.509 Certificate Standards<a href="#section-2-23" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -1365,7 +1366,7 @@ <h3 id="name-servidor-de-autoriza231227o">
             <p id="section-6.1-3.2.1">deve anunciar todos os recursos API REST do Open Banking Brasil protegidos pelo Provedor OpenID no Diret&#243;rio de Participantes;<a href="#section-6.1-3.2.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-6.1-3.3">
-            <p id="section-6.1-3.3.1">deve anunciar suporte para todos os mecanismos de assinatura, criptografia, autentica&#231;&#227;o e padr&#245;es necess&#225;rios para suportar o <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html">Open Banking Brasil Financial API</a>;<a href="#section-6.1-3.3.1" class="pilcrow">¶</a></p>
+            <p id="section-6.1-3.3.1">deve anunciar suporte para todos os mecanismos de assinatura, criptografia, autentica&#231;&#227;o e padr&#245;es necess&#225;rios para suportar o <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">Open Banking Brasil Financial API</a>;<a href="#section-6.1-3.3.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-6.1-3.4">
             <p id="section-6.1-3.4.1">deve anunciar suporte para <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Dynamic Client Registration</a>;<a href="#section-6.1-3.4.1" class="pilcrow">¶</a></p>
@@ -1453,6 +1454,9 @@ <h3 id="name-servidor-de-autoriza231227o-2">
 <li id="section-7.1-3.12">
             <p id="section-7.1-3.12.1">se for compat&#237;vel com o mecanismo de autentica&#231;&#227;o do cliente <code>tls_client_auth</code>, conforme definido em <a href="https://tools.ietf.org/html/rfc8705">RFC8705</a>, somente deve aceitar <code>tls_client_auth_subject_dn</code> como uma indica&#231;&#227;o do valor do atributo <em>subject</em> do certificado, conforme definido na cl&#225;usula 2.1.2 <a href="https://tools.ietf.org/html/rfc8705">RFC8705</a>;<a href="#section-7.1-3.12.1" class="pilcrow">¶</a></p>
 </li>
+<li id="section-7.1-3.13">
+            <p id="section-7.1-3.13.1">Os valores dos campos <em>UID</em> e <em>OU</em> do certificado devem coincidir com os enviados no SSA. O campo <em>OU</em> deve conter o valor do campo <em>org_id</em> do SSA e campo <em>UID</em> deve conter o valor do campo <em>software_id</em> do SSA.<a href="#section-7.1-3.13.1" class="pilcrow">¶</a></p>
+</li>
 </ol>
 <p id="section-7.1-4">Estas disposi&#231;&#245;es aplicam-se igualmente ao processamento de pedidos <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a>, <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a> e <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Registration</a><a href="#section-7.1-4" class="pilcrow">¶</a></p>
 <div id="Server">
@@ -1480,20 +1484,21 @@ <h4 id="name-an225lise-do-distinguished-">
 <a href="#section-7.1.2" class="section-number selfRef">7.1.2. </a><a href="#name-an225lise-do-distinguished-" class="section-name selfRef">An&#225;lise do Distinguished Name do Certificado</a>
           </h4>
 <p id="section-7.1.2-1">A cl&#225;usula 3 do <a href="https://www.rfc-editor.org/rfc/rfc4514">Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names</a> define os OIDs obrigat&#243;rios cujas as <em>strings</em> do AttributeType (descritores) devem ser reconhecidos pelos implementadores. Esta lista obrigat&#243;ria n&#227;o inclui v&#225;rios dos OIDs definidos em <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a>, nem existe um mecanismo definido para os Servidores de Autoriza&#231;&#227;o publicarem informa&#231;&#245;es sobre o formato que eles esperam de uma Solicita&#231;&#227;o Din&#226;mica de Registro do Cliente (<em>Dynamic Client Registrarion</em>) que inclui um <code>tls_client_auth_subject_dn</code>.<a href="#section-7.1.2-1" class="pilcrow">¶</a></p>
-<p id="section-7.1.2-2">Para resolver essa ambig&#252;idade, o Servidor de Autoriza&#231;&#227;o deve aceitar todas as strings de nome de AttributeType (descritores) definidas no &#250;ltimo par&#225;grafo da cl&#225;usula 3 <a href="https://www.rfc-editor.org/rfc/rfc4514">RFC4514</a>, al&#233;m de todos os AttributeTypes definidos no Distinguished Name <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a>.<a href="#section-7.1.2-2" class="pilcrow">¶</a></p>
-<p id="section-7.1.2-3">Segue na tabela abaixo alguns exemplos de decodifica&#231;&#227;o:<a href="#section-7.1.2-3" class="pilcrow">¶</a></p>
+<p id="section-7.1.2-2">Para resolver essa ambiguidade, o Servidor de Autoriza&#231;&#227;o deve aceitar exclusivamente os AttributeType (descritores) definidas no &#250;ltimo par&#225;grafo da cl&#225;usula 3 <a href="https://www.rfc-editor.org/rfc/rfc4514">RFC4514</a> em formato string,  tamb&#233;m deve aceitar em formato OID, com seus valores em ASN.1, todos os AttributeTypes definidos no Distinguished Name <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a> ou adicionados pela Autoridade Certificadora.<a href="#section-7.1.2-2" class="pilcrow">¶</a></p>
+<p id="section-7.1.2-3">Em caso de n&#227;o atendimento destes requisitos o Servidor de Autoriza&#231;&#227;o dever&#225; rejeitar o registro.<a href="#section-7.1.2-3" class="pilcrow">¶</a></p>
+<p id="section-7.1.2-4">Segue na tabela abaixo como deve ser feita a decodifica&#231;&#227;o:<a href="#section-7.1.2-4" class="pilcrow">¶</a></p>
 <ul>
-<li id="section-7.1.2-4.1">
-              <p id="section-7.1.2-4.1.1">Obtenha na ordem reversa os atributos do certificado<a href="#section-7.1.2-4.1.1" class="pilcrow">¶</a></p>
+<li id="section-7.1.2-5.1">
+              <p id="section-7.1.2-5.1.1">Obtenha na ordem reversa os atributos do certificado<a href="#section-7.1.2-5.1.1" class="pilcrow">¶</a></p>
 </li>
-<li id="section-7.1.2-4.2">
-              <p id="section-7.1.2-4.2.1">Concatene cada RDN (RelativeDistinguishedName) com uma virgula (',')<a href="#section-7.1.2-4.2.1" class="pilcrow">¶</a></p>
+<li id="section-7.1.2-5.2">
+              <p id="section-7.1.2-5.2.1">Concatene cada RDN (RelativeDistinguishedName) com uma virgula (',')<a href="#section-7.1.2-5.2.1" class="pilcrow">¶</a></p>
 </li>
-<li id="section-7.1.2-4.3">
-              <p id="section-7.1.2-4.3.1">Use as strings da RFC (CN, L, ST, O, OU, C, Street, DC, UID) + os nomes dos atributos definidos nesta especifica&#231;&#227;o para uso no OBB (businessCategory, jurisdictionCountryName , serialNumber)<a href="#section-7.1.2-4.3.1" class="pilcrow">¶</a></p>
+<li id="section-7.1.2-5.3">
+              <p id="section-7.1.2-5.3.1">Use as strings da RFC (CN, L, ST, O, OU, C, Street, DC, UID) com o valor dos seus atribudos em "printable string", ou seja leg&#237;vel para humanos + os OIDs dos atributos definidos nesta especifica&#231;&#227;o para uso no OBB (businessCategory=OID 2.5.4.15,jurisdictionCountryName=OID: 1.3.6.1.4.1.311.60.2.1.3, serialNumber=2.5.4.5) com o valor dos seus atributos em formato ASN.1"<a href="#section-7.1.2-5.3.1" class="pilcrow">¶</a></p>
 </li>
 </ul>
-<p id="section-7.1.2-5">Exemplos:<a href="#section-7.1.2-5" class="pilcrow">¶</a></p>
+<p id="section-7.1.2-6">Seguem abaixo exemplos para os atributos obrigat&#243;rios da CAs atualmente ativas:<a href="#section-7.1.2-6" class="pilcrow">¶</a></p>
 <table class="center" id="table-1">
             <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
 <thead>
@@ -1504,19 +1509,19 @@ <h4 id="name-an225lise-do-distinguished-">
             </thead>
             <tbody>
               <tr>
-                <td class="text-left" rowspan="1" colspan="1">UID=67c57882-043b-11ec-9a03-0242ac130003,jurisdictionCountryName=BR,businessCategory=Private      Organization,serialNumber=00038166000954,CN=mycn.bank.com.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=MY BANK SA,L=SAO PAULO,ST=SP,C=BR</td>
+                <td class="text-left" rowspan="1" colspan="1">UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839, CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L= BRASILIA, ST=DF, C=BR</td>
                 <td class="text-left" rowspan="1" colspan="1">issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR</td>
               </tr>
               <tr>
-                <td class="text-left" rowspan="1" colspan="1">UID=67c57882-043b-11ec-9a03-0242ac130003,   jurisdictionCountryName=BR,businessCategory=Business Entity,CN=mycn.bank.gov.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR</td>
-                <td class="text-left" rowspan="1" colspan="1">issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR,jurisdictionCountryName=BR,businessCategory=Private</td>
+                <td class="text-left" rowspan="1" colspan="1">UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, CN=mycn.bank.gov.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L=BRASILIA, ST=DF, C=BR</td>
+                <td class="text-left" rowspan="1" colspan="1">issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR</td>
               </tr>
               <tr>
-                <td class="text-left" rowspan="1" colspan="1">Organization,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR</td>
+                <td class="text-left" rowspan="1" colspan="1">1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, UID=67c57882-043b-11ec-9a03-0242ac130003, CN=openbanking.mybank.com.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Goiania, ST=GO, O=MyBank SA, C=BR</td>
                 <td class="text-left" rowspan="1" colspan="1">issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR</td>
               </tr>
               <tr>
-                <td class="text-left" rowspan="1" colspan="1">CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao   Paulo,ST=SP,O=MyBank SA,C=BR,serialNumber=00038166000954,   jurisdictionCountryName=BR,businessCategory=Private   Organization</td>
+                <td class="text-left" rowspan="1" colspan="1">CN=mycn.bank.com.br, UID=67c57882-043b-11ec-9a03-0242ac130003, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Sao Paulo, ST=SP, O=MyBank SA, C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e</td>
                 <td class="text-left" rowspan="1" colspan="1">issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR</td>
               </tr>
             </tbody>
@@ -1571,6 +1576,15 @@ <h3 id="name-fun231245es-regulat243rias-">
         </table>
 </section>
 </div>
+<div id="registro_tls_client_auth">
+<section id="section-7.3">
+        <h3 id="name-registro-do-cliente">
+<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-registro-do-cliente" class="section-name selfRef">Registro do Cliente</a>
+        </h3>
+<p id="section-7.3-1">No processo de registro do cliente, utilizando-se o m&#233;todo de autentica&#231;&#227;o <em>tls_client_auth</em>, o cliente deve encaminhar o campo <em>tls_client_auth_subject_dn</em> com os AttibuteTypes (Descritores) em formato definido no item 7.1.2.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
+<p id="section-7.3-2">Em caso de n&#227;o aderencia a este padr&#227;o o registro ser&#225; rejeitado.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
+</section>
+</div>
 </section>
 </div>
 <div id="SSA">

From 5ab4cdf5309c382168d5378ac170ace0044d5f9e Mon Sep 17 00:00:00 2001
From: JOAO RODOLFO <joao.rodolfo+github@gmail.com>
Date: Wed, 10 Nov 2021 18:31:26 -0300
Subject: [PATCH 25/59] Translate DOC:
 specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.md

Translate DOC: specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.md
---
 ...rasil-dynamic-client-registration-1_ID2.md | 82 ++++++++++++-------
 1 file changed, 53 insertions(+), 29 deletions(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.md b/open-banking-brasil-dynamic-client-registration-1_ID2.md
index b12feca..95d9b6b 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.md
@@ -24,8 +24,8 @@
     organization = "Raidiam"
     abbrev = "Raidiam"
       [author.address]
-      email = "ralph.bragg@raidiam.com"
-      uri = "https://www.raidiam.com/"
+      email = ralph.bragg@raidiam.com
+      uri = https://www.raidiam.com/
 
     [[author]]
     initials = "GT"
@@ -34,15 +34,11 @@
     organization = "Open Banking Brasil Initial Structure"
     abbrev = "OBBIS"
       [author.address]
-      email = "gt-seguranca@openbankingbr.org"
-      uri = "https://openbankingbrasil.org.br/"
+      email = gt-seguranca@openbankingbr.org
+      uri = https://openbankingbrasil.org.br/
 
 %%%
 
-# The English version of this document is Outdated
-Please refer to the portuguese version for up to date information:
->[https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html)
-
 .# Foreword
 
 Este documento também está disponível em [português](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html)
@@ -153,6 +149,9 @@ The following referenced documents are indispensable for the application of this
 [OBB-Cert-Standards] - Open Banking Brasil x.509 Certificate Standards
 [OBB-Cert-Standards]: <https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html
 
+[OBB-DCR/DCM-Swagger] - DCR & DCM Swagger 
+[OBB-DCR/DCM-Swagger]: <https://raw.githubusercontent.com/OpenBanking-Brasil/specs-seguranca/main/dcr_review/dcr-dcm-swagger.yaml
+
 # Terms and definitions
 
 For the purpose of this document, the terms defined in [RFC6749], [RFC6750], [RFC7636], [OpenID Connect Core][OIDC] and ISO29100 apply.
@@ -189,13 +188,14 @@ The services by the Directory include
 
 Participants within the ecosystem must leverage these services to facilitate API driven OAuth client registration using the process outlined in clause 3.1.1 of [RFC7591] with additional metadata necessary to support OpenID Connect defined in [OpenID Connect Registration][OIDR].
 
-Where possible, authorisation servers should compare client metadata asserted by a client made as part of registration or management request against metadata claims contained within a software statement. Not all metadata that a client wishes to provide may be contained in a software statement, e.g alternative [Metadata Languages and Script values](https://openid.net/specs/openid-connect-registration-1_0.html#LanguagesAndScripts).
+It's important to remember that the client registration payload has most of its non-mandatory attributes, and that assigned values; that conflict with the present in the assertion software declaration *will be overridden by the values of the software statement assertion issued by the Directory of Participants*. Not all metadata that a client wishes to provide may be contained in a software statement, e.g alternative [Metadata Languages and Script values](https://openid.net/specs/openid-connect-registration-1_0.html#LanguagesAndScripts). There are some cases when the client metadata are subset os the existing values in the SSA, such as redirect_URIs.
 
 # Open Banking Brasil OpenID Connect Discovery provisions
 
 ## Authorization server
 
-The Authorization Server shall support [OpenID Connect Discovery][OIDD] as required by [Financial-grade API Security Profile 1.0 - Part 1: Baseline][FAPI-1-Baseline]
+The Authorization Server shall support [OpenID Connect Discovery][OIDD] as required by [Financial-grade API Security Profile 1.0 - Part 1: Baseline][FAPI-1-Baseline]. 
+This support shall be explicit in Participant Directory configurations, and in the declaration of its attributes in the Discovery file (well-known), respecting the authentication mechanisms certified by the institution through the Open Banking Brazil compliance tests.
 
 In addition, the Authorization Server
 
@@ -221,20 +221,20 @@ In addition, the Client
 
 ## Authorization server
 
-The Authorization Server shall support the [RFC7591], [RFC7592] and [OpenID Registration][OIDR]
+The Authorization Server shall support the RFC RFCs Dynamic Client Registration (DCR) [RFC7591],  Dynamic Client Management (DCM) [RFC7592] and [OpenID Registration][OIDR]
 
 In addition, the Authorization Server
 
 1. shall reject dynamic client registration requests not performed over a connection secured with mutual tls using certificates issued by Brazil ICP (production) or the Directory of Participants (sandbox);
 2. shall validate that the request contains software_statement JWT signed using the `PS256` algorithim issued by the Open Banking Brasil directory of participants;
 3. shall validate that the `software_statement` was issued (iat) not more than 5 minutes prior to the request being received;
-4. shall validate that a `jwks` (key set by value) was **not** included;
-5. shall require and validate that the `jwks_uri` matches the `software_jwks_uri` provided in the software statement;
-6. shall require and validate that `redirect_uris` match or contain a sub set of software_redirect_uris provided in the software statement;
-7. shall require and validate that all client authentication mechanism adhere to the requirements defined in [Financial-grade API Security Profile 1.0 - Part 1: Advanced](https://openid.net/specs/openid-financial-api-part-2-1_0.html);
-8. shall require encrypted request objects as required by the Brasil Open Banking Security Profile;
-9. shall validate that requested scopes are appropriate for the softwares authorized regulatory roles;
-10. should where possible validate client asserted metadata against metadata provided in the software_statement;
+4. shall validate that the attribute `jwks` (key set by value) was **not** included; but declared as a reference in the `jwks_uri` attribute; 
+5. when the `jwks_uri` was informed, shall validate that matches the `software_jwks_uri` provided in the `software_statement`;
+6. shall require and validate that `redirect_uris` match or contain a sub set of software_redirect_uris provided in the `software_statement`;
+7. shall require and validate that all client authentication mechanism adhere to the requirements defined in [RFC7591] and [RFC7592], validating the `registration_access_token` and using a secure connection, protected by certificate Issued from chain of certificates linked to ICP-Brasil;
+8. _removed_;
+9. shall validate that the requested scopes are adequate for accredited institutions and their regulatory roles and contained in the `software_statement`. The list of regulatory permissions and the corresponding scopes are described in the following sections;
+10. where possible, shall compare client metadata asserted by a client toward the metadata provided into  `software_statement`, choosing the values present in the SSA with precedence;
 11. shall accept all x.500 AttributeType name strings defined in the Distinguished Name of the x.509 Certificate Profiles defined in [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards];
 12. if supporting `tls_client_auth` client authentication mechanism as defined in [RFC8705] shall only accept `tls_client_auth_subject_dn`  as an indication of the certificate subject value as defined in clause 2.1.2 [RFC8705];
 
@@ -245,29 +245,31 @@ These provisions apply equally to the processing of [RFC7591], [RFC7592] and [Op
 Where properties of a DCR request are not included and are not mandatory in the specification the Authorisation Server shall apply client defaults in the following manner
 
 1. shall select and apply the encryption algorithm and cipher choice from the most recommended of the IANA cipher suites that is supported by the Authorisation Server;
-2. shall populate defaults from values within the software statement assertion where possible;
-3. shall grant the client permission to the complete set of potential scopes based on the softwares regulatory permissions included in the software_statement;
+2. shall populate defaults from values within the `software_statement` assertion where possible;
+3. shall grant the client permission to the complete set of potential scopes based on the softwares regulatory permissions included in the `software_statement`;
 
 ### Certificate Distinguished Name Parsing
 
 Clause 3 of [Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names][RFC4514] defines the mandatory OIDs whose AttributeType strings (descriptors) must be recognized by implementers. This mandatory list does not include several of the OIDs defined in [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] nor is there a defined mechanism for Authorisation Servers to publish  information regarding the format that they would expect a Dynamic Client Registration request that includes a `tls_client_auth_subject_dn` to be presented in.
 
-To address this ambiguity, the Authorization Server must accept all AttributeType name strings (descriptors) defined in the last paragraph of clause 3 [RFC4514] in addition to all of the AttributeTypes defined in the Distinguished Name of the [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards].
+To address this ambiguity, the Authorization Server must accept only the AttributeTypes name strings (descriptors) defined in the last paragraph of clause 3 [RFC4514] in string format, it shall also accept in OID format, with their values in ASN.1, all the AttributeTypes defined in Distinguished Name [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] or added by the Certificate Authority.
 
-In terms of format, the Security WG have defined the examples in bellow:
+In case of non-compliance with these requirements, the Authorization Server shall reject the registration. 
+
+In terms of format, follow below how decoding should be done: 
 
 - Start backwards, the order is reversed from what is entered.
-- Append each RDN (RelativeDistinguishedName) segment with a comma ‘,’
-- Use RFC Strings (CN, L, ST, O, OU, C, Street, DC, UID) + OBB Certificate Specs (businessCategory, jurisdictionCountryName , serialNumber)
+- Append each RDN (RelativeDistinguishedName) segment with a comma ‘,’.
+- Use the RFC strings (CN, L, ST, O, OR, C, Street, DC, UID) with the value of their attributes in "printable string", ie human-readable + the OIDs of the attributes defined in this specification for use in Distinguished Name [Open Banking Brasil x.509 Certificate Standards][OBB-Cert-Standards] (businessCategory=OID 2.5.4.15,jurisdictionCountryName=OID: 1.3.6.1.4.1.311.60.2.1.3, serialNumber=OID:2.5.4.5) with the value of your attributes in ASN.1 format.
 
 Examples:
 
 | subject_dn | Issuer |
 | --- | --- |
-| UID=67c57882-043b-11ec-9a03-0242ac130003,jurisdictionCountryName=BR,businessCategory=Private      Organization,serialNumber=00038166000954,CN=mycn.bank.com.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=MY BANK SA,L=SAO PAULO,ST=SP,C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
-| UID=67c57882-043b-11ec-9a03-0242ac130003,   jurisdictionCountryName=BR,businessCategory=Business Entity,CN=mycn.bank.gov.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,O=My Public Bank,L=BRASILIA,ST=DF,C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR,jurisdictionCountryName=BR,businessCategory=Private |
-| Organization,UID=67c57882-043b-11ec-9a03-0242ac130003,CN=openbanking.mybank.com.br,serialNumber=00038166000954,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Goiania,ST=GO,O=MyBank SA,C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| CN=mycn.bank.com.br,UID=67c57882-043b-11ec-9a03-0242ac130003,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59,L=Sao   Paulo,ST=SP,O=MyBank SA,C=BR,serialNumber=00038166000954,   jurisdictionCountryName=BR,businessCategory=Private   Organization | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839, CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L= BRASILIA, ST=DF, C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, CN=mycn.bank.gov.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L=BRASILIA, ST=DF, C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, UID=67c57882-043b-11ec-9a03-0242ac130003, CN=openbanking.mybank.com.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Goiania, ST=GO, O=MyBank SA, C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| CN=mycn.bank.com.br, UID=67c57882-043b-11ec-9a03-0242ac130003, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Sao Paulo, ST=SP, O=MyBank SA, C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
 
 ## Regulatory Roles to OpenID and OAuth 2.0 Mappings
 
@@ -386,7 +388,8 @@ The following example contains all of the claims currently included in a softwar
 
 ## Posting a request with a software statement
 
-This example includes various optional fields, some of which may not be applicable to some deployments. Line wraps within values are for display purposes only.
+This example includes various optional fields, some of which may not be applicable to some deployments. For a complete guide to the attributes and their requirements, consult the Swagger DCR/DCM link: [OBB-DCR/DCM-Swagger] .
+Line wraps within values are for display purposes only.
 
 ```
 POST /reg HTTP/1.1
@@ -441,6 +444,20 @@ Open Banking Open Banking Brasil production SSA issuer
 
 Open Banking Open Banking Brasil sandbox SSA issuer
 
+## About authentication and authorization mechanisms for DCR and DCM services 
+As they are auxiliary services to the main flow of Open Banking Brasil, the dynamic registration and maintenance services for clients cannot use the exact access control mechanisms.  For example, it is not possible to require an OAuth 2.0 _access\_token_ from a client application that isn't registered yet with the transmitting institution. 
+
+To extend [RFC7591] and [RFC7592], which recommend minimum mechanisms for authentication of their services, institutions that support the registration flows and dynamic maintenance of clients must implement the following controls: 
+
+### Client registration - POST /register 
+1. validate that the certificate presented by the client application is subordinate to the ICP-Brasil chains defined in the Open Banking Brasil Certificates Standard; 
+2. ensure that the signature of the `software_statement`_ presented by the client application during registration has been made by the Directory of Participants using the public keys described in the previous section; 
+3. ensure that the `software_statement` presented by the client application during registration corresponds to the same institution as the client certificate presented, validating it through the attributes that bring `organization_id` in the X.509 certificate. 
+
+### Client Maintenance - GET /register - PUT /register - DELETE /register 
+1. validate that the certificate presented by the client application is subordinate to the ICP-Brasil chains defined in the Open Banking Brasil Certificates Standard; 
+2. Validate the presence and matching of the Bearer header `Authorization` containing the value of the `registration_access_token` attribute returned during registration of the corresponding client. 
+
 # Acknowledgement
 
 With thanks to all who have set the foundations for secure and safe data sharing through the formation of the OpenID Foundation FAPI Working Group, the Open Banking Brasil GT Security and to the pioneers who will stand on their shoulders.
@@ -450,6 +467,12 @@ The following people contributed to this document:
 * Ralph Bragg (Raidiam)
 * Alexandre Siqueira (Mercado Pago)
 * Bernardo Vale (Banco Inter)
+* André Borges (Banco Fibra)
+* Danilo Sasaki (Banco Itaú)
+* João Rodolfo Vieira da Silva (Banco Itaú)
+* Michelle Bandarra (Chicago)
+* Alexandre Daniel Dalabrida (Cooperativa Central Ailos)
+* Rafael Gonzalez Hashimoto - (Banco C6)
 
 {backmatter}
 
@@ -463,6 +486,7 @@ The technology described in this specification was made available from contribut
 
 ## Appendix A. Example Software Statement Assertion
 
+
 ```
 eyJraWQiOiJzaWduZXIiLCJ0eXAiOiJKV1QiLCJhbGciOiJQUzI1NiJ9.eyJzb2Z0d2FyZV9tb2RlIjoiTGl2ZSIsInNvZnR3YXJlX3JlZGlyZWN0X3VyaXMiOlsiaHR0cHM6XC9cL3d3dy5yYWlkaWFtLmNvbVwvYWNjb3VudGluZ1wvY2IiXSwic29mdHdhcmVfc3RhdGVtZW50X3JvbGVzIjpbeyJyb2xlIjoiREFET1MiLCJhdXRob3Jpc2F0aW9uX2RvbWFpbiI6Ik9wZW4gQmFua2luZyIsInN0YXR1cyI6IkFjdGl2ZSJ9LHsicm9sZSI6IlBBR1RPIiwiYXV0aG9yaXNhdGlvbl9kb21haW4iOiJPcGVuIEJhbmtpbmciLCJzdGF0dXMiOiJBY3RpdmUifV0sInNvZnR3YXJlX2NsaWVudF9uYW1lIjoiUmFpZGlhbSBBY2NvdW50aW5nIiwib3JnX3N0YXR1cyI6IkFjdGl2ZSIsInNvZnR3YXJlX2NsaWVudF9pZCI6IkNraTFFYnZqd3loUEIxMk5HTGx6MiIsImlzcyI6Ik9wZW4gQmFua2luZyBPcGVuIEJhbmtpbmcgQnJhc2lsIHByb2QgU1NBIGlzc3VlciIsInNvZnR3YXJlX3Rvc191cmkiOiJodHRwczpcL1wvd3d3LnJhaWRpYW0uY29tXC9hY2NvdW50aW5nXC90b3MuaHRtbCIsInNvZnR3YXJlX2NsaWVudF9kZXNjcmlwdGlvbiI6IlJhaWRpYW0gQWNjb3VudGluZyBsZXZlcmFnZSBjdXR0aW5nIGVkZ2Ugb3BlbiBiYW5raW5nIGFjY2VzcyB0byBicmluZyB5b3UgcmVhbCB0aW1lIHVwIHRvIGRhdGUgdmlld3Mgb2YgeW91ciBmaW5hbmNlcyIsInNvZnR3YXJlX2p3a3NfZW5kcG9pbnQiOiJodHRwczpcL1wva2V5c3RvcmUuZGlyZWN0b3J5Lm9wZW5iYW5raW5nYnJhc2lsLm9yZy5iclwvYjk2MWM0ZWItNTA5ZC00ZWRmLWFmZWItMzU2NDJiMzgxODVkXC8yNTU1NmQ1YS1iOWRkLTRlMjctYWExYS1jY2U3MzJmZTc0ZGVcL2FwcGxpY2F0aW9uLmp3a3MiLCJzb2Z0d2FyZV9wb2xpY3lfdXJpIjoiaHR0cHM6XC9cL3d3dy5yYWlkaWFtLmNvbVwvYWNjb3VudGluZ1wvcG9saWN5Lmh0bWwiLCJzb2Z0d2FyZV9pZCI6IjI1NTU2ZDVhLWI5ZGQtNGUyNy1hYTFhLWNjZTczMmZlNzRkZSIsInNvZnR3YXJlX2NsaWVudF91cmkiOiJodHRwczpcL1wvd3d3LnJhaWRpYW0uY29tXC9hY2NvdW50aW5nLmh0bWwiLCJzb2Z0d2FyZV9qd2tzX2luYWN0aXZlX2VuZHBvaW50IjoiaHR0cHM6XC9cL2tleXN0b3JlLmRpcmVjdG9yeS5vcGVuYmFua2luZ2JyYXNpbC5vcmcuYnJcL2I5NjFjNGViLTUwOWQtNGVkZi1hZmViLTM1NjQyYjM4MTg1ZFwvMjU1NTZkNWEtYjlkZC00ZTI3LWFhMWEtY2NlNzMyZmU3NGRlXC9pbmFjdGl2ZVwvYXBwbGljYXRpb24uandrcyIsInNvZnR3YXJlX2p3a3NfdHJhbnNwb3J0X2luYWN0aXZlX2VuZHBvaW50IjoiaHR0cHM6XC9cL2tleXN0b3JlLmRpcmVjdG9yeS5vcGVuYmFua2luZ2JyYXNpbC5vcmcuYnJcL2I5NjFjNGViLTUwOWQtNGVkZi1hZmViLTM1NjQyYjM4MTg1ZFwvMjU1NTZkNWEtYjlkZC00ZTI3LWFhMWEtY2NlNzMyZmU3NGRlXC9pbmFjdGl2ZVwvdHJhbnNwb3J0Lmp3a3MiLCJzb2Z0d2FyZV9qd2tzX3RyYW5zcG9ydF9lbmRwb2ludCI6Imh0dHBzOlwvXC9rZXlzdG9yZS5kaXJlY3Rvcnkub3BlbmJhbmtpbmdicmFzaWwub3JnLmJyXC9iOTYxYzRlYi01MDlkLTRlZGYtYWZlYi0zNTY0MmIzODE4NWRcLzI1NTU2ZDVhLWI5ZGQtNGUyNy1hYTFhLWNjZTczMmZlNzRkZVwvdHJhbnNwb3J0Lmp3a3MiLCJzb2Z0d2FyZV9sb2dvX3VyaSI6Imh0dHBzOlwvXC93d3cucmFpZGlhbS5jb21cL2FjY291bnRpbmdcL2xvZ28ucG5nIiwib3JnX2lkIjoiYjk2MWM0ZWItNTA5ZC00ZWRmLWFmZWItMzU2NDJiMzgxODVkIiwic29mdHdhcmVfZW52aXJvbm1lbnQiOiJwcm9kdWN0aW9uIiwic29mdHdhcmVfdmVyc2lvbiI6MS4xMCwic29mdHdhcmVfcm9sZXMiOlsiREFET1MiLCJQQUdUTyJdLCJvcmdfbmFtZSI6Ik9wZW4gQmFua2luZyBCcmFzaWwiLCJpYXQiOjE2MTgzMzYyNjIsIm9yZ2FuaXNhdGlvbl9jb21wZXRlbnRfYXV0aG9yaXR5X2NsYWltcyI6W3siYXV0aG9yaXNhdGlvbl9kb21haW4iOiJPcGVuIEJhbmtpbmciLCJhdXRob3Jpc2F0aW9ucyI6W10sInJlZ2lzdHJhdGlvbl9pZCI6IjEzMzUzMjM2LU9CQi1DT05UQSIsImF1dGhvcml0eV9pZCI6IjY4N2ExYzk0LWIzNjAtNGUwNC05NTg5LTBmYTVjYjE2NDUxYiIsImF1dGhvcmlzYXRpb25fcm9sZSI6IkNPTlRBIiwiYXV0aG9yaXR5X2NvZGUiOiJCQ0IiLCJzdGF0dXMiOiJBY3RpdmUifSx7ImF1dGhvcmlzYXRpb25fZG9tYWluIjoiT3BlbiBCYW5raW5nIiwiYXV0aG9yaXNhdGlvbnMiOltdLCJyZWdpc3RyYXRpb25faWQiOiIxMzM1MzIzNi1PQkItREFET1MiLCJhdXRob3JpdHlfaWQiOiI2ODdhMWM5NC1iMzYwLTRlMDQtOTU4OS0wZmE1Y2IxNjQ1MWIiLCJhdXRob3Jpc2F0aW9uX3JvbGUiOiJEQURPUyIsImF1dGhvcml0eV9jb2RlIjoiQkNCIiwic3RhdHVzIjoiQWN0aXZlIn0seyJhdXRob3Jpc2F0aW9uX2RvbWFpbiI6Ik9wZW4gQmFua2luZyIsImF1dGhvcmlzYXRpb25zIjpbXSwicmVnaXN0cmF0aW9uX2lkIjoiMTMzNTMyMzYtT0JCLVBBR1RPIiwiYXV0aG9yaXR5X2lkIjoiNjg3YTFjOTQtYjM2MC00ZTA0LTk1ODktMGZhNWNiMTY0NTFiIiwiYXV0aG9yaXNhdGlvbl9yb2xlIjoiUEFHVE8iLCJhdXRob3JpdHlfY29kZSI6IkJDQiIsInN0YXR1cyI6IkFjdGl2ZSJ9XX0.W6hUAYhjT6I61rxEIVMKYKre93LTbRdzKnk9dJvUdzVgAz5B9KxZNutf27oO3k0hrjYVWBdWq23o_e4Y_AaKdpS9-rtU84JiHtmqV0wcFYIM8nqcUVWqQ-Ux6Nq9L2G-s2YNd3PcJ1e3yGg9h8553Gr7iJusKEgApzXUpkM2rBELQuumktUE_JBiuIkXmWxoRnO1cW-Osbk3MT3bxG43SPcxii07Q5S8qXI6PjCPA3fYlnaUAygwZM3O0oa7jqmSr7d9UsHuDMJfYhIKdq2wyQQKORCN-D2UopmMX-lHMvAVkkrAO08T0-7odjr4PJk-PrwuoCxeAfa7440ZDOrlmQ
 ```

From cdd549d122330558861ceeb5c62c27f2cc9b5c12 Mon Sep 17 00:00:00 2001
From: Alexandre Daniel Dalabrida <alexandre.dalabrida@ailos.coop.br>
Date: Thu, 11 Nov 2021 17:00:15 -0300
Subject: [PATCH 26/59] =?UTF-8?q?Inclus=C3=A3o=20da=20documenta=C3=A7?=
 =?UTF-8?q?=C3=A3o=20da=20proibi=C3=A7=C3=A3o=20da=20rota=C3=A7=C3=A3o=20d?=
 =?UTF-8?q?o=20refresh=20token?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...banking-brasil-financial-api-1_ID3-ptbr.md | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.md b/open-banking-brasil-financial-api-1_ID3-ptbr.md
index 7a83bde..c03a885 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.md
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.md
@@ -1,3 +1,4 @@
+
 %%%
 
     #
@@ -227,10 +228,11 @@ Além disso, ele deve:
 10. pode suportar [Financial-grade API: Client Initiated Backchannel Authentication Profile][FAPI-CIBA]
 11. (requisito temporariamente retirado)
 12. deve suportar `refresh tokens`
-13. deve emitir `access tokens` com o tempo de expiração entre 300 (mínimo) e 900 (máximo) segundos
-14. deve sempre incluir a claim `acr` no id_token
-15. deve suportar os valores `code` e `id_token` para o atributo `response_type`
-16. pode suportar o valor `code` para o atributo `response_type`em conjunto com o valor `jwt` para o atributo `response_mode`
+13. não deve permitir o recurso de rotação de `refresh tokens`
+14. deve emitir `access tokens` com o tempo de expiração entre 300 (mínimo) e 900 (máximo) segundos
+15. deve sempre incluir a claim `acr` no id_token
+16. deve suportar os valores `code` e `id_token` para o atributo `response_type`
+17. pode suportar o valor `code` para o atributo `response_type`em conjunto com o valor `jwt` para o atributo `response_mode`
 
 #### Token de ID como assinatura separada  {#detached}
 
@@ -305,9 +307,10 @@ Além disso, o cliente confidencial
 3. deve usar objetos de solicitação _encrypted_ se não usar [PAR]
 4. deve suportar o escopo de recurso OAuth 2.0 parametrizado _consent_ conforme definido na cláusula 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP]
 5. deve suportar `refresh tokens`
-6. não deve incluir um valor específico na _claim_ `acr`
-7. deve definir a _claim_ `acr`como _essential_
-8. deve suportar todos os métodos de autenticação especificados no item 14 da seção 5.2.2 da [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] incluindo as diferentes combinações de métodos de encaminhamento dos Requests Objects (usando ou não [PAR] - item 11).
+6. não deve permitir o recurso de rotação de `refresh tokens`
+7. não deve incluir um valor específico na _claim_ `acr`
+8. deve definir a _claim_ `acr`como _essential_
+9. deve suportar todos os métodos de autenticação especificados no item 14 da seção 5.2.2 da [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] incluindo as diferentes combinações de métodos de encaminhamento dos Requests Objects (usando ou não [PAR] - item 11).
 
 # Considerações de segurança  {#authserver}
 
@@ -440,4 +443,4 @@ Copyright (c) 2021 Estrutura Inicial do Open Banking Brasil
 
 A Estrutura Inicial do Open Banking Brasil (EIOBB) concede a qualquer Colaborador, desenvolvedor, implementador ou outra parte interessada uma licença de direitos autorais mundial não exclusiva, livre de royalties para reproduzir, preparar trabalhos derivados, distribuir, executar e exibir, estes Implementadores Rascunho ou Especificação Final exclusivamente para fins de (i) desenvolver especificações e (ii) implementar Rascunhos de Implementadores e Especificações Finais com base em tais documentos, desde que a atribuição seja feita ao EIOBB como a fonte do material, mas que tal atribuição o faça não indica endosso do EIOBB.
 
-A tecnologia descrita nesta especificação foi disponibilizada a partir de contribuições de várias fontes, incluindo membros da OpenID Foundation, do Grupo de Trabalho de Segurança do Open Banking Brasil e outros. Embora a Estrutura Inicial do Open Banking Brasil tenha tomado medidas para ajudar a garantir que a tecnologia esteja disponível para distribuição, ela não toma posição quanto à validade ou escopo de qualquer propriedade intelectual ou outros direitos que possam ser reivindicados como pertencentes à implementação ou uso do tecnologia descrita nesta especificação ou até que ponto qualquer licença sob tais direitos pode ou não estar disponível; nem representa que fez qualquer esforço independente para identificar tais direitos. A Estrutura Inicial do Open Banking Brasil e os contribuidores desta especificação não oferecem (e por meio deste expressamente se isentam de quaisquer) garantias (expressas, implícitas ou de outra forma), incluindo garantias implícitas de comercialização, não violação, adequação a uma finalidade específica ou título, relacionados a esta especificação, e todo o risco quanto à implementação desta especificação é assumido pelo implementador. A política de Direitos de Propriedade Intelectual do Open Banking Brasil exige que os contribuidores ofereçam uma promessa de patente de não fazer valer certas reivindicações de patentes contra outros contribuidores e implementadores. A Estrutura Inicial do Open Banking Brasil convida qualquer parte interessada a trazer à sua atenção quaisquer direitos autorais, patentes, pedidos de patentes ou outros direitos de propriedade que possam abranger a tecnologia que possa ser necessária para praticar esta especificação.
+A tecnologia descrita nesta especificação foi disponibilizada a partir de contribuições de várias fontes, incluindo membros da OpenID Foundation, do Grupo de Trabalho de Segurança do Open Banking Brasil e outros. Embora a Estrutura Inicial do Open Banking Brasil tenha tomado medidas para ajudar a garantir que a tecnologia esteja disponível para distribuição, ela não toma posição quanto à validade ou escopo de qualquer propriedade intelectual ou outros direitos que possam ser reivindicados como pertencentes à implementação ou uso do tecnologia descrita nesta especificação ou até que ponto qualquer licença sob tais direitos pode ou não estar disponível; nem representa que fez qualquer esforço independente para identificar tais direitos. A Estrutura Inicial do Open Banking Brasil e os contribuidores desta especificação não oferecem (e por meio deste expressamente se isentam de quaisquer) garantias (expressas, implícitas ou de outra forma), incluindo garantias implícitas de comercialização, não violação, adequação a uma finalidade específica ou título, relacionados a esta especificação, e todo o risco quanto à implementação desta especificação é assumido pelo implementador. A política de Direitos de Propriedade Intelectual do Open Banking Brasil exige que os contribuidores ofereçam uma promessa de patente de não fazer valer certas reivindicações de patentes contra outros contribuidores e implementadores. A Estrutura Inicial do Open Banking Brasil convida qualquer parte interessada a trazer à sua atenção quaisquer direitos autorais, patentes, pedidos de patentes ou outros direitos de propriedade que possam abranger a tecnologia que possa ser necessária para praticar esta especificação.
\ No newline at end of file

From f2affee7cd5515e674b69f6d89d122dfc6002281 Mon Sep 17 00:00:00 2001
From: ediemerson-br <60996132+ediemerson-br@users.noreply.github.com>
Date: Thu, 11 Nov 2021 18:10:56 -0300
Subject: [PATCH 27/59] Update
 open-banking-brasil-dynamic-client-registration-1_ID2.md

---
 open-banking-brasil-dynamic-client-registration-1_ID2.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.md b/open-banking-brasil-dynamic-client-registration-1_ID2.md
index 95d9b6b..99df93e 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.md
@@ -24,8 +24,8 @@
     organization = "Raidiam"
     abbrev = "Raidiam"
       [author.address]
-      email = ralph.bragg@raidiam.com
-      uri = https://www.raidiam.com/
+      email = "ralph.bragg@raidiam.com"
+      uri = "https://www.raidiam.com/"
 
     [[author]]
     initials = "GT"
@@ -34,8 +34,8 @@
     organization = "Open Banking Brasil Initial Structure"
     abbrev = "OBBIS"
       [author.address]
-      email = gt-seguranca@openbankingbr.org
-      uri = https://openbankingbrasil.org.br/
+      email = "gt-seguranca@openbankingbr.org"
+      uri = "https://openbankingbrasil.org.br/"
 
 %%%
 

From 35c51bcab781bc548b3744a3e51fcab4ce4e4dd1 Mon Sep 17 00:00:00 2001
From: ediemerson-br <60996132+ediemerson-br@users.noreply.github.com>
Date: Thu, 11 Nov 2021 18:19:24 -0300
Subject: [PATCH 28/59] Add files via upload

---
 ...sil-dynamic-client-registration-1_ID2.html | 1915 +++++++++++++++++
 1 file changed, 1915 insertions(+)
 create mode 100644 open-banking-brasil-dynamic-client-registration-1_ID2.html

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.html b/open-banking-brasil-dynamic-client-registration-1_ID2.html
new file mode 100644
index 0000000..64ee7b2
--- /dev/null
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.html
@@ -0,0 +1,1915 @@
+<!DOCTYPE html>
+<html lang="en" class="Internet-Draft">
+<head>
+<meta charset="utf-8">
+<meta content="Common,Latin" name="scripts">
+<meta content="initial-scale=1.0" name="viewport">
+<title>Open Banking Brasil Financial-grade API Dynamic Client Registration 1.0 Implementers Draft 2</title>
+<meta content="Ralph Bragg" name="author">
+<meta content="OBBIS GT Security" name="author">
+<meta content="xml2rfc 2.40.1" name="generator">
+<meta content="FAPI" name="keyword">
+<meta content="Open Banking Brasil GT Security" name="keyword">
+<meta content="open-banking-brasil-dynamic-client-registration-1_ID2" name="ietf.draft">
+<link href="./open-banking-brasil-dynamic-client-registration-1_ID2.xml" rel="alternate" type="application/rfc+xml">
+<link href="#copyright" rel="license">
+<style type="text/css">/*
+
+  NOTE: Changes at the bottom of this file overrides some earlier settings.
+
+  Once the style has stabilized and has been adopted as an official RFC style,
+  this can be consolidated so that style settings occur only in one place, but
+  for now the contents of this file consists first of the initial CSS work as
+  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
+  commented changes found necssary during the development of the v3
+  formatters.
+
+*/
+
+/* fonts */
+@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
+@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
+@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */
+
+@viewport {
+  zoom: 1.0;
+  width: extend-to-zoom;
+}
+@-ms-viewport {
+  width: extend-to-zoom;
+  zoom: 1.0;
+}
+/* general and mobile first */
+html {
+}
+body {
+  max-width: 90%;
+  margin: 1.5em auto;
+  color: #222;
+  background-color: #fff;
+  font-size: 14px;
+  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
+  line-height: 1.6;
+  scroll-behavior: smooth;
+}
+.ears {
+  display: none;
+}
+
+/* headings */
+#title, h1, h2, h3, h4, h5, h6 {
+  margin: 1em 0 0.5em;
+  font-weight: bold;
+  line-height: 1.3;
+}
+#title {
+  clear: both;
+  border-bottom: 1px solid #ddd;
+  margin: 0 0 0.5em 0;
+  padding: 1em 0 0.5em;
+}
+.author {
+  padding-bottom: 4px;
+}
+h1 {
+  font-size: 26px;
+  margin: 1em 0;
+}
+h2 {
+  font-size: 22px;
+  margin-top: -20px;  /* provide offset for in-page anchors */
+  padding-top: 33px;
+}
+h3 {
+  font-size: 18px;
+  margin-top: -36px;  /* provide offset for in-page anchors */
+  padding-top: 42px;
+}
+h4 {
+  font-size: 16px;
+  margin-top: -36px;  /* provide offset for in-page anchors */
+  padding-top: 42px;
+}
+h5, h6 {
+  font-size: 14px;
+}
+#n-copyright-notice {
+  border-bottom: 1px solid #ddd;
+  padding-bottom: 1em;
+  margin-bottom: 1em;
+}
+/* general structure */
+p {
+  padding: 0;
+  margin: 0 0 1em 0;
+  text-align: left;
+}
+div, span {
+  position: relative;
+}
+div {
+  margin: 0;
+}
+.alignRight.art-text {
+  background-color: #f9f9f9;
+  border: 1px solid #eee;
+  border-radius: 3px;
+  padding: 1em 1em 0;
+  margin-bottom: 1.5em;
+}
+.alignRight.art-text pre {
+  padding: 0;
+}
+.alignRight {
+  margin: 1em 0;
+}
+.alignRight > *:first-child {
+  border: none;
+  margin: 0;
+  float: right;
+  clear: both;
+}
+.alignRight > *:nth-child(2) {
+  clear: both;
+  display: block;
+  border: none;
+}
+svg {
+  display: block;
+}
+.alignCenter.art-text {
+  background-color: #f9f9f9;
+  border: 1px solid #eee;
+  border-radius: 3px;
+  padding: 1em 1em 0;
+  margin-bottom: 1.5em;
+}
+.alignCenter.art-text pre {
+  padding: 0;
+}
+.alignCenter {
+  margin: 1em 0;
+}
+.alignCenter > *:first-child {
+  border: none;
+  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
+     support flexbox yet.
+  */
+  display: table;
+  margin: 0 auto;
+}
+
+/* lists */
+ol, ul {
+  padding: 0;
+  margin: 0 0 1em 2em;
+}
+ol ol, ul ul, ol ul, ul ol {
+  margin-left: 1em;
+}
+li {
+  margin: 0 0 0.25em 0;
+}
+.ulCompact li {
+  margin: 0;
+}
+ul.empty, .ulEmpty {
+  list-style-type: none;
+}
+ul.empty li, .ulEmpty li {
+  margin-top: 0.5em;
+}
+ul.compact, .ulCompact,
+ol.compact, .olCompact {
+  line-height: 100%;
+  margin: 0 0 0 2em;
+}
+
+/* definition lists */
+dl {
+}
+dl > dt {
+  float: left;
+  margin-right: 1em;
+}
+/* 
+dl.nohang > dt {
+  float: none;
+}
+*/
+dl > dd {
+  margin-bottom: .8em;
+  min-height: 1.3em;
+}
+dl.compact > dd, .dlCompact > dd {
+  margin-bottom: 0em;
+}
+dl > dd > dl {
+  margin-top: 0.5em;
+  margin-bottom: 0em;
+}
+
+/* links */
+a {
+  text-decoration: none;
+}
+a[href] {
+  color: #22e; /* Arlen: WCAG 2019 */
+}
+a[href]:hover {
+  background-color: #f2f2f2;
+}
+figcaption a[href],
+a[href].selfRef {
+  color: #222;
+}
+/* XXX probably not this:
+a.selfRef:hover {
+  background-color: transparent;
+  cursor: default;
+} */
+
+/* Figures */
+tt, code, pre, code {
+  background-color: #f9f9f9;
+  font-family: 'Roboto Mono', monospace;
+}
+pre {
+  border: 1px solid #eee;
+  margin: 0;
+  padding: 1em;
+}
+img {
+  max-width: 100%;
+}
+figure {
+  margin: 0;
+}
+figure blockquote {
+  margin: 0.8em 0.4em 0.4em;
+}
+figcaption {
+  font-style: italic;
+  margin: 0 0 1em 0;
+}
+@media screen {
+  pre {
+    overflow-x: auto;
+    max-width: 100%;
+    max-width: calc(100% - 22px);
+  }
+}
+
+/* aside, blockquote */
+aside, blockquote {
+  margin-left: 0;
+  padding: 1.2em 2em;
+}
+blockquote {
+  background-color: #f9f9f9;
+  color: #111; /* Arlen: WCAG 2019 */
+  border: 1px solid #ddd;
+  border-radius: 3px;
+  margin: 1em 0;
+}
+cite {
+  display: block;
+  text-align: right;
+  font-style: italic;
+}
+
+/* tables */
+table {
+  width: 100%;
+  margin: 0 0 1em;
+  border-collapse: collapse;
+  border: 1px solid #eee;
+}
+th, td {
+  text-align: left;
+  vertical-align: top;
+  padding: 0.5em 0.75em;
+}
+th {
+  text-align: left;
+  background-color: #e9e9e9;
+}
+tr:nth-child(2n+1) > td {
+  background-color: #f5f5f5;
+}
+table caption {
+  font-style: italic;
+  margin: 0;
+  padding: 0;
+  text-align: left;
+}
+table p {
+  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
+     be allowed within tables more generally, it would be far better to select on a class. */
+  margin: 0;
+}
+
+/* pilcrow */
+a.pilcrow {
+  color: #666; /* Arlen: AHDJ 2019 */
+  text-decoration: none;
+  visibility: hidden;
+  user-select: none;
+  -ms-user-select: none;
+  -o-user-select:none;
+  -moz-user-select: none;
+  -khtml-user-select: none;
+  -webkit-user-select: none;
+  -webkit-touch-callout: none;
+}
+@media screen {
+  aside:hover > a.pilcrow,
+  p:hover > a.pilcrow,
+  blockquote:hover > a.pilcrow,
+  div:hover > a.pilcrow,
+  li:hover > a.pilcrow,
+  pre:hover > a.pilcrow {
+    visibility: visible;
+  }
+  a.pilcrow:hover {
+    background-color: transparent;
+  }
+}
+
+/* misc */
+hr {
+  border: 0;
+  border-top: 1px solid #eee;
+}
+.bcp14 {
+  font-variant: small-caps;
+}
+
+.role {
+  font-variant: all-small-caps;
+}
+
+/* info block */
+#identifiers {
+  margin: 0;
+  font-size: 0.9em;
+}
+#identifiers dt {
+  width: 3em;
+  clear: left;
+}
+#identifiers dd {
+  float: left;
+  margin-bottom: 0;
+}
+#identifiers .authors .author {
+  display: inline-block;
+  margin-right: 1.5em;
+}
+#identifiers .authors .org {
+  font-style: italic;
+}
+
+/* The prepared/rendered info at the very bottom of the page */
+.docInfo {
+  color: #666; /* Arlen: WCAG 2019 */
+  font-size: 0.9em;
+  font-style: italic;
+  margin-top: 2em;
+}
+.docInfo .prepared {
+  float: left;
+}
+.docInfo .prepared {
+  float: right;
+}
+
+/* table of contents */
+#toc  {
+  padding: 0.75em 0 2em 0;
+  margin-bottom: 1em;
+}
+nav.toc ul {
+  margin: 0 0.5em 0 0;
+  padding: 0;
+  list-style: none;
+}
+nav.toc li {
+  line-height: 1.3em;
+  margin: 0.75em 0;
+  padding-left: 1.2em;
+  text-indent: -1.2em;
+}
+/* references */
+.references dt {
+  text-align: right;
+  font-weight: bold;
+  min-width: 7em;
+}
+.references dd {
+  margin-left: 8em;
+  overflow: auto;
+}
+
+.refInstance {
+  margin-bottom: 1.25em;
+}
+
+.references .ascii {
+  margin-bottom: 0.25em;
+}
+
+/* index */
+.index ul {
+  margin: 0 0 0 1em;
+  padding: 0;
+  list-style: none;
+}
+.index ul ul {
+  margin: 0;
+}
+.index li {
+  margin: 0;
+  text-indent: -2em;
+  padding-left: 2em;
+  padding-bottom: 5px;
+}
+.indexIndex {
+  margin: 0.5em 0 1em;
+}
+.index a {
+  font-weight: 700;
+}
+/* make the index two-column on all but the smallest screens */
+@media (min-width: 600px) {
+  .index ul {
+    -moz-column-count: 2;
+    -moz-column-gap: 20px;
+  }
+  .index ul ul {
+    -moz-column-count: 1;
+    -moz-column-gap: 0;
+  }
+}
+
+/* authors */
+address.vcard {
+  font-style: normal;
+  margin: 1em 0;
+}
+
+address.vcard .nameRole {
+  font-weight: 700;
+  margin-left: 0;
+}
+address.vcard .label {
+  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
+  margin: 0.5em 0;
+}
+address.vcard .type {
+  display: none;
+}
+.alternative-contact {
+  margin: 1.5em 0 1em;
+}
+hr.addr {
+  border-top: 1px dashed;
+  margin: 0;
+  color: #ddd;
+  max-width: calc(100% - 16px);
+}
+
+/* temporary notes */
+.rfcEditorRemove::before {
+  position: absolute;
+  top: 0.2em;
+  right: 0.2em;
+  padding: 0.2em;
+  content: "The RFC Editor will remove this note";
+  color: #9e2a00; /* Arlen: WCAG 2019 */
+  background-color: #ffd; /* Arlen: WCAG 2019 */
+}
+.rfcEditorRemove {
+  position: relative;
+  padding-top: 1.8em;
+  background-color: #ffd; /* Arlen: WCAG 2019 */
+  border-radius: 3px;
+}
+.cref {
+  background-color: #ffd; /* Arlen: WCAG 2019 */
+  padding: 2px 4px;
+}
+.crefSource {
+  font-style: italic;
+}
+/* alternative layout for smaller screens */
+@media screen and (max-width: 1023px) {
+  body {
+    padding-top: 2em;
+  }
+  #title {
+    padding: 1em 0;
+  }
+  h1 {
+    font-size: 24px;
+  }
+  h2 {
+    font-size: 20px;
+    margin-top: -18px;  /* provide offset for in-page anchors */
+    padding-top: 38px;
+  }
+  #identifiers dd {
+    max-width: 60%;
+  }
+  #toc {
+    position: fixed;
+    z-index: 2;
+    top: 0;
+    right: 0;
+    padding: 0;
+    margin: 0;
+    background-color: inherit;
+    border-bottom: 1px solid #ccc;
+  }
+  #toc h2 {
+    margin: -1px 0 0 0;
+    padding: 4px 0 4px 6px;
+    padding-right: 1em;
+    min-width: 190px;
+    font-size: 1.1em;
+    text-align: right;
+    background-color: #444;
+    color: white;
+    cursor: pointer;
+  }
+  #toc h2::before { /* css hamburger */
+    float: right;
+    position: relative;
+    width: 1em;
+    height: 1px;
+    left: -164px;
+    margin: 6px 0 0 0;
+    background: white none repeat scroll 0 0;
+    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
+    content: "";
+  }
+  #toc nav {
+    display: none;
+    padding: 0.5em 1em 1em;
+    overflow: auto;
+    height: calc(100vh - 48px);
+    border-left: 1px solid #ddd;
+  }
+}
+
+/* alternative layout for wide screens */
+@media screen and (min-width: 1024px) {
+  body {
+    max-width: 724px;
+    margin: 42px auto;
+    padding-left: 1.5em;
+    padding-right: 29em;
+  }
+  #toc {
+    position: fixed;
+    top: 42px;
+    right: 42px;
+    width: 25%;
+    margin: 0;
+    padding: 0 1em;
+    z-index: 1;
+  }
+  #toc h2 {
+    border-top: none;
+    border-bottom: 1px solid #ddd;
+    font-size: 1em;
+    font-weight: normal;
+    margin: 0;
+    padding: 0.25em 1em 1em 0;
+  }
+  #toc nav {
+    display: block;
+    height: calc(90vh - 84px);
+    bottom: 0;
+    padding: 0.5em 0 0;
+    overflow: auto;
+  }
+  img { /* future proofing */
+    max-width: 100%;
+    height: auto;
+  }
+}
+
+/* pagination */
+@media print {
+  body {
+
+    width: 100%;
+  }
+  p {
+    orphans: 3;
+    widows: 3;
+  }
+  #n-copyright-notice {
+    border-bottom: none;
+  }
+  #toc, #n-introduction {
+    page-break-before: always;
+  }
+  #toc {
+    border-top: none;
+    padding-top: 0;
+  }
+  figure, pre {
+    page-break-inside: avoid;
+  }
+  figure {
+    overflow: scroll;
+  }
+  h1, h2, h3, h4, h5, h6 {
+    page-break-after: avoid;
+  }
+  h2+*, h3+*, h4+*, h5+*, h6+* {
+    page-break-before: avoid;
+  }
+  pre {
+    white-space: pre-wrap;
+    word-wrap: break-word;
+    font-size: 10pt;
+  }
+  table {
+    border: 1px solid #ddd;
+  }
+  td {
+    border-top: 1px solid #ddd;
+  }
+}
+
+/* This is commented out here, as the string-set: doesn't
+   pass W3C validation currently */
+/*
+.ears thead .left {
+  string-set: ears-top-left content();
+}
+
+.ears thead .center {
+  string-set: ears-top-center content();
+}
+
+.ears thead .right {
+  string-set: ears-top-right content();
+}
+
+.ears tfoot .left {
+  string-set: ears-bottom-left content();
+}
+
+.ears tfoot .center {
+  string-set: ears-bottom-center content();
+}
+
+.ears tfoot .right {
+  string-set: ears-bottom-right content();
+}
+*/
+
+@page :first {
+  padding-top: 0;
+  @top-left {
+    content: normal;
+    border: none;
+  }
+  @top-center {
+    content: normal;
+    border: none;
+  }
+  @top-right {
+    content: normal;
+    border: none;
+  }
+}
+
+@page {
+  size: A4;
+  margin-bottom: 45mm;
+  padding-top: 20px;
+  /* The follwing is commented out here, but set appropriately by in code, as
+     the content depends on the document */
+  /*
+  @top-left {
+    content: 'Internet-Draft';
+    vertical-align: bottom;
+    border-bottom: solid 1px #ccc;
+  }
+  @top-left {
+    content: string(ears-top-left);
+    vertical-align: bottom;
+    border-bottom: solid 1px #ccc;
+  }
+  @top-center {
+    content: string(ears-top-center);
+    vertical-align: bottom;
+    border-bottom: solid 1px #ccc;
+  }
+  @top-right {
+    content: string(ears-top-right);
+    vertical-align: bottom;
+    border-bottom: solid 1px #ccc;
+  }
+  @bottom-left {
+    content: string(ears-bottom-left);
+    vertical-align: top;
+    border-top: solid 1px #ccc;
+  }
+  @bottom-center {
+    content: string(ears-bottom-center);
+    vertical-align: top;
+    border-top: solid 1px #ccc;
+  }
+  @bottom-right {
+      content: '[Page ' counter(page) ']';
+      vertical-align: top;
+      border-top: solid 1px #ccc;
+  }
+  */
+
+}
+
+/* Changes introduced to fix issues found during implementation */
+/* Make sure links are clickable even if overlapped by following H* */
+a {
+  z-index: 2;
+}
+/* Separate body from document info even without intervening H1 */
+section {
+  clear: both;
+}
+
+
+/* Top align author divs, to avoid names without organization dropping level with org names */
+.author {
+  vertical-align: top;
+}
+
+/* Leave room in document info to show Internet-Draft on one line */
+#identifiers dt {
+  width: 8em;
+}
+
+/* Don't waste quite as much whitespace between label and value in doc info */
+#identifiers dd {
+  margin-left: 1em;
+}
+
+/* Give floating toc a background color (needed when it's a div inside section */
+#toc {
+  background-color: white;
+}
+
+/* Make the collapsed ToC header render white on gray also when it's a link */
+@media screen and (max-width: 1023px) {
+  #toc h2 a,
+  #toc h2 a:link,
+  #toc h2 a:focus,
+  #toc h2 a:hover,
+  #toc a.toplink,
+  #toc a.toplink:hover {
+    color: white;
+    background-color: #444;
+    text-decoration: none;
+  }
+}
+
+/* Give the bottom of the ToC some whitespace */
+@media screen and (min-width: 1024px) {
+  #toc {
+    padding: 0 0 1em 1em;
+  }
+}
+
+/* Style section numbers with more space between number and title */
+.section-number {
+  padding-right: 0.5em;
+}
+
+/* prevent monospace from becoming overly large */
+tt, code, pre, code {
+  font-size: 95%;
+}
+
+/* Fix the height/width aspect for ascii art*/
+pre.sourcecode,
+.art-text pre {
+  line-height: 1.12;
+}
+
+
+/* Add styling for a link in the ToC that points to the top of the document */
+a.toplink {
+  float: right;
+  margin-right: 0.5em;
+}
+
+/* Fix the dl styling to match the RFC 7992 attributes */
+dl > dt,
+dl.dlParallel > dt {
+  float: left;
+  margin-right: 1em;
+}
+dl.dlNewline > dt {
+  float: none;
+}
+
+/* Provide styling for table cell text alignment */
+table td.text-left,
+table th.text-left {
+  text-align: left;
+}
+table td.text-center,
+table th.text-center {
+  text-align: center;
+}
+table td.text-right,
+table th.text-right {
+  text-align: right;
+}
+
+/* Make the alternative author contact informatio look less like just another
+   author, and group it closer with the primary author contact information */
+.alternative-contact {
+  margin: 0.5em 0 0.25em 0;
+}
+address .non-ascii {
+  margin: 0 0 0 2em;
+}
+
+/* With it being possible to set tables with alignment
+  left, center, and right, { width: 100%; } does not make sense */
+table {
+  width: auto;
+}
+
+/* Avoid reference text that sits in a block with very wide left margin,
+   because of a long floating dt label.*/
+.references dd {
+  overflow: visible;
+}
+
+/* Control caption placement */
+caption {
+  caption-side: bottom;
+}
+
+/* Limit the width of the author address vcard, so names in right-to-left
+   script don't end up on the other side of the page. */
+
+address.vcard {
+  max-width: 30em;
+  margin-right: auto;
+}
+
+/* For address alignment dependent on LTR or RTL scripts */
+address div.left {
+  text-align: left;
+}
+address div.right {
+  text-align: right;
+}
+
+/* Provide table alignment support.  We can't use the alignX classes above
+   since they do unwanted things with caption and other styling. */
+table.right {
+ margin-left: auto;
+ margin-right: 0;
+}
+table.center {
+ margin-left: auto;
+ margin-right: auto;
+}
+table.left {
+ margin-left: 0;
+ margin-right: auto;
+}
+
+/* Give the table caption label the same styling as the figcaption */
+caption a[href] {
+  color: #222;
+}
+
+@media print {
+  .toplink {
+    display: none;
+  }
+
+  /* avoid overwriting the top border line with the ToC header */
+  #toc {
+    padding-top: 1px;
+  }
+
+  /* Avoid page breaks inside dl and author address entries */
+  .vcard {
+    page-break-inside: avoid;
+  }
+
+}
+/* Avoid wrapping of URLs in references */
+@media screen {
+  .references a {
+    white-space: nowrap;
+  }
+}
+/* Tweak the bcp14 keyword presentation */
+.bcp14 {
+  font-variant: small-caps;
+  font-weight: bold;
+  font-size: 0.9em;
+}
+/* Tweak the invisible space above H* in order not to overlay links in text above */
+ h2 {
+  margin-top: -18px;  /* provide offset for in-page anchors */
+  padding-top: 31px;
+ }
+ h3 {
+  margin-top: -18px;  /* provide offset for in-page anchors */
+  padding-top: 24px;
+ }
+ h4 {
+  margin-top: -18px;  /* provide offset for in-page anchors */
+  padding-top: 24px;
+ }
+/* Float artwork pilcrow to the right */
+@media screen {
+  .artwork a.pilcrow {
+    display: block;
+    line-height: 0.7;
+    margin-top: 0.15em;
+  }
+}
+/* Make pilcrows on dd visible */
+@media screen {
+  dd:hover > a.pilcrow {
+    visibility: visible;
+  }
+}
+/* Make the placement of figcaption match that of a table's caption
+   by removing the figure's added bottom margin */
+.alignLeft.art-text,
+.alignCenter.art-text,
+.alignRight.art-text {
+   margin-bottom: 0;
+}
+.alignLeft,
+.alignCenter,
+.alignRight {
+  margin: 1em 0 0 0;
+}
+/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
+   possibly even requiring a new line */
+@media print {
+  a.pilcrow {
+    display: none;
+  }
+}
+/* Styling for the external metadata */
+div#external-metadata {
+  background-color: #eee;
+  padding: 0.5em;
+  margin-bottom: 0.5em;
+  display: none;
+}
+div#internal-metadata {
+  padding: 0.5em;                       /* to match the external-metadata padding */
+}
+/* Styling for title RFC Number */
+h1#rfcnum {
+  clear: both;
+  margin: 0 0 -1em;
+  padding: 1em 0 0 0;
+}
+/* Make .olPercent look the same as <ol><li> */
+dl.olPercent > dd {
+  margin: 0 0 0.25em 0;
+  min-height: initial;
+}
+/* Give aside some styling to set it apart */
+aside {
+  border-left: 1px solid #ddd;
+  margin: 1em 0 1em 2em;
+  padding: 0.2em 2em;
+}
+aside > dl,
+aside > ol,
+aside > ul,
+aside > table,
+aside > p {
+  margin-bottom: 0.5em;
+}
+/* Additional page break settings */
+@media print {
+  figcaption, table caption {
+    page-break-before: avoid;
+  }
+}
+/* Font size adjustments for print */
+@media print {
+  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
+  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
+  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
+  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
+  h4    { font-size: 1em;       padding-top: 1.5em; }
+  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
+}
+/* Sourcecode margin in print, when there's no pilcrow */
+@media print {
+  .artwork,
+  .sourcecode {
+    margin-bottom: 1em;
+  }
+}
+/*
+  The margin-left: 0 on <dd> removes all distinction
+  between levels from nested <dl>s.  Undo that.
+*/
+dl.olPercent > dd,
+dd {
+  margin-left: revert;
+}
+/* Avoid narrow tables forcing too narrow table captions, which may render badly */
+table {
+  min-width: 20em;
+}
+/* ol type a */
+ol.type-a { list-style-type: lower-alpha; }
+ol.type-A { list-style-type: upper-alpha; }
+ol.type-i { list-style-type: lower-roman; }
+ol.type-I { list-style-type: lower-roman; }
+/* Apply the print table and row borders in general, on request from the RPC,
+and increase the contrast between border and odd row background sligthtly */
+table {
+  border: 1px solid #ddd;
+}
+td {
+  border-top: 1px solid #ddd;
+}
+tr:nth-child(2n+1) > td {
+  background-color: #f8f8f8;
+}
+/* Use style rules to govern display of the TOC. */
+@media screen and (max-width: 1023px) {
+  #toc nav { display: none; }
+  #toc.active nav { display: block; }
+}
+</style>
+<link href="rfc-local.css" rel="stylesheet" type="text/css">
+</head>
+<body>
+<script src="metadata.min.js"></script>
+<table class="ears">
+<thead><tr>
+<td class="left"></td>
+<td class="center">OBB-FAPI-1-DCR-ID2</td>
+<td class="right">November 2021</td>
+</tr></thead>
+<tfoot><tr>
+<td class="left">Bragg & Security</td>
+<td class="center">Standards Track</td>
+<td class="right">[Page]</td>
+</tr></tfoot>
+</table>
+<div id="external-metadata" class="document-information"></div>
+<div id="internal-metadata" class="document-information">
+<dl id="identifiers">
+<dt class="label-workgroup">Workgroup:</dt>
+<dd class="workgroup">Open Banking Brasil GT Security</dd>
+<dt class="label-internet-draft">Internet-Draft:</dt>
+<dd class="internet-draft">open-banking-brasil-dynamic-client-registration-1_ID2</dd>
+<dt class="label-published">Published:</dt>
+<dd class="published">
+<time datetime="2021-11-11" class="published">11 November 2021</time>
+    </dd>
+<dt class="label-intended-status">Intended Status:</dt>
+<dd class="intended-status">Standards Track</dd>
+<dt class="label-authors">Authors:</dt>
+<dd class="authors">
+<div class="author">
+      <div class="author-name">R. Bragg</div>
+<div class="org">Raidiam</div>
+</div>
+<div class="author">
+      <div class="author-name">GT. Security</div>
+<div class="org">OBBIS</div>
+</div>
+</dd>
+</dl>
+</div>
+<h1 id="title">Open Banking Brasil Financial-grade API Dynamic Client Registration 1.0 Implementers Draft 2</h1>
+<section class="note" id="section-note.1">
+      <h2 id="name-foreword">
+<a href="#name-foreword" class="section-name selfRef">Foreword</a>
+      </h2>
+<p id="section-note.1-1">Este documento tamb&#233;m est&#225; dispon&#237;vel em <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html">portugu&#234;s</a><a href="#section-note.1-1" class="pilcrow">¶</a></p>
+<p id="section-note.1-2">The Open Banking Brasil Initial Structure is responsible for creating standards and specifications necessary to meet the requirements and obligations of the Brasil Open Banking Legislation as originally outlined by the <a href="https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf">Brasil Central Bank</a>. There is a possibility that some of the elements of this document may be the subject to patent rights. OBBIS shall not be held responsible for identifying any or all such patent rights.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
+<p id="section-note.1-3">Open Banking Brasil Financial-grade API Security Profile 1.0 consists of the following parts:<a href="#section-note.1-3" class="pilcrow">¶</a></p>
+<ul class="note">
+<li class="note" id="section-note.1-4.1">
+          <p id="section-note.1-4.1.1"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">Open Banking Brasil Financial-grade API Security Profile 1.0</a><a href="#section-note.1-4.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="note" id="section-note.1-4.2">
+          <p id="section-note.1-4.2.1">Open Banking Brasil Dynamic Client Registration Profile 1.0<a href="#section-note.1-4.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+<p id="section-note.1-5">These parts are intended to be used with <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>, <a href="https://tools.ietf.org/html/rfc6750">RFC6750</a>, <a href="https://tools.ietf.org/html/rfc7636">RFC7636</a>, <a href="https://openid.net/specs/openid-connect-core-1_0.html">OIDC</a>, <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OIDR</a>, <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a>, <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a>, <a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">FAPI-1-Baseline</a> and <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">FAPI-1-Advanced</a><a href="#section-note.1-5" class="pilcrow">¶</a></p>
+</section>
+<section class="note" id="section-note.2">
+      <h2 id="name-introduction">
+<a href="#name-introduction" class="section-name selfRef">Introduction</a>
+      </h2>
+<p id="section-note.2-1">The Open Banking Brasil Financial-grade API Dynamic Client Registration Profile is a profile of <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a>, <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a> and <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OIDR</a> that aims to provide specific implementation guidelines for security and interoperability which can be applied to the identification, registration and management of OAuth Clients operating in the Brasil Open Banking ecosystem.
+Although it is possible to code an OpenID Provider and Relying Party from first principles using this specification, the main audience for this specification is parties who already have a certified implementation of <a href="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect</a> and want to achieve certification for the Brasil Open Banking programme.<a href="#section-note.2-1" class="pilcrow">¶</a></p>
+</section>
+<section class="note" id="section-note.3">
+      <h2 id="name-notational-conventions">
+<a href="#name-notational-conventions" class="section-name selfRef">Notational Conventions</a>
+      </h2>
+<p id="section-note.3-1">The key words "shall", "shall not",
+"should", "should not", "may", and
+"can" in this document are to be interpreted as described in
+<a href="https://www.iso.org/sites/directives/current/part2/index.xhtml">ISO Directive Part 2</a>.
+These key words are not used as dictionary terms such that
+any occurrence of them shall be interpreted as key words
+and are not to be interpreted with their natural language meanings.<a href="#section-note.3-1" class="pilcrow">¶</a></p>
+</section>
+<div id="toc">
+<section id="section-toc.1">
+        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
+<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
+        </h2>
+<nav class="toc"><ul class="toc ulEmpty">
+<li class="toc ulEmpty" id="section-toc.1-1.1">
+            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-scope" class="xref">Scope</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.2">
+            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-normative-references" class="xref">Normative references</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.3">
+            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-terms-and-definitions" class="xref">Terms and definitions</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.4">
+            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-symbols-and-abbreviated-ter" class="xref">Symbols and Abbreviated terms</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.5">
+            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-introduction-2" class="xref">Introduction</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.6">
+            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-open-banking-brasil-openid-" class="xref">Open Banking Brasil OpenID Connect Discovery provisions</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
+<ul class="toc ulEmpty">
+<li class="toc ulEmpty" id="section-toc.1-1.6.2.1">
+                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-authorization-server" class="xref">Authorization server</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.6.2.2">
+                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-client" class="xref">Client</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.7">
+            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-open-banking-brasil-openid-c" class="xref">Open Banking Brasil OpenID Connect Registration Provisions</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
+<ul class="toc ulEmpty">
+<li class="toc ulEmpty" id="section-toc.1-1.7.2.1">
+                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-authorization-server-2" class="xref">Authorization server</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
+<ul class="toc ulEmpty">
+<li class="toc ulEmpty" id="section-toc.1-1.7.2.1.2.1">
+                    <p id="section-toc.1-1.7.2.1.2.1.1"><a href="#section-7.1.1" class="xref">7.1.1</a>.  <a href="#name-applying-server-defaults" class="xref">Applying Server Defaults</a><a href="#section-toc.1-1.7.2.1.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.7.2.1.2.2">
+                    <p id="section-toc.1-1.7.2.1.2.2.1"><a href="#section-7.1.2" class="xref">7.1.2</a>.  <a href="#name-certificate-distinguished-n" class="xref">Certificate Distinguished Name Parsing</a><a href="#section-toc.1-1.7.2.1.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.7.2.2">
+                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-regulatory-roles-to-openid-" class="xref">Regulatory Roles to OpenID and OAuth 2.0 Mappings</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
+<ul class="toc ulEmpty">
+<li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.1">
+                    <p id="section-toc.1-1.7.2.2.2.1.1"><a href="#section-7.2.1" class="xref">7.2.1</a>.  <a href="#name-implementers-note" class="xref">Implementers Note</a><a href="#section-toc.1-1.7.2.2.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.7.2.3">
+                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-regulatory-roles-to-dynamic" class="xref">Regulatory Roles to dynamic OAuth 2.0 scope Mappings</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.8">
+            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-software-statement" class="xref">Software Statement</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
+<ul class="toc ulEmpty">
+<li class="toc ulEmpty" id="section-toc.1-1.8.2.1">
+                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-software-statement-claims" class="xref">Software Statement Claims</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.9">
+            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-dynamic-client-registration" class="xref">Dynamic Client Registration Request Processing</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
+<ul class="toc ulEmpty">
+<li class="toc ulEmpty" id="section-toc.1-1.9.2.1">
+                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-posting-a-request-with-a-so" class="xref">Posting a request with a software statement</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.9.2.2">
+                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-open-banking-brasil-ssa-key" class="xref">Open Banking Brasil SSA Key Store and Issuer Details</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.9.2.3">
+                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-about-authentication-and-au" class="xref">About authentication and authorization mechanisms for DCR and DCM services</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
+<ul class="toc ulEmpty">
+<li class="toc ulEmpty" id="section-toc.1-1.9.2.3.2.1">
+                    <p id="section-toc.1-1.9.2.3.2.1.1"><a href="#section-9.3.1" class="xref">9.3.1</a>.  <a href="#name-client-registration-post-re" class="xref">Client registration - POST /register</a><a href="#section-toc.1-1.9.2.3.2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.9.2.3.2.2">
+                    <p id="section-toc.1-1.9.2.3.2.2.1"><a href="#section-9.3.2" class="xref">9.3.2</a>.  <a href="#name-client-maintenance-get-regi" class="xref">Client Maintenance - GET /register - PUT /register - DELETE /register</a><a href="#section-toc.1-1.9.2.3.2.2.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.10">
+            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-acknowledgement" class="xref">Acknowledgement</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.11">
+            <p id="section-toc.1-1.11.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-notices" class="xref">Notices</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
+<ul class="toc ulEmpty">
+<li class="toc ulEmpty" id="section-toc.1-1.11.2.1">
+                <p id="section-toc.1-1.11.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-appendix-a-example-software" class="xref">Appendix A. Example Software Statement Assertion</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</li>
+<li class="toc ulEmpty" id="section-toc.1-1.12">
+            <p id="section-toc.1-1.12.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</nav>
+</section>
+</div>
+<div id="scope">
+<section id="section-1">
+      <h2 id="name-scope">
+<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-scope" class="section-name selfRef">Scope</a>
+      </h2>
+<p id="section-1-1">This document specifies the method of<a href="#section-1-1" class="pilcrow">¶</a></p>
+<ul>
+<li id="section-1-2.1">
+          <p id="section-1-2.1.1">applications registered in the <a href="https://web.directory.openbankingbrasil.org.br">Open Banking Directory of Participants</a> to discover OpenID Providers offering services in the Open Banking Brasil ecosystem;<a href="#section-1-2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-1-2.2">
+          <p id="section-1-2.2.1">applications to use <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Registration</a> to onboard their applications with Bank OpenID Providers; and<a href="#section-1-2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-1-2.3">
+          <p id="section-1-2.3.1">applications to use <a href="https://tools.ietf.org/html/rfc7592">OAuth 2.0 Dynamic Client Registration Management Protocol</a> to manage their applications with OpenID Providers;<a href="#section-1-2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+<p id="section-1-3">This document is applicable to all participants engaging in Open Banking in Brasil.<a href="#section-1-3" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="normative-references">
+<section id="section-2">
+      <h2 id="name-normative-references">
+<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-normative-references" class="section-name selfRef">Normative references</a>
+      </h2>
+<p id="section-2-1">The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applied. For undated references, the latest edition of the referenced document (including any amendments) applies.<a href="#section-2-1" class="pilcrow">¶</a></p>
+<p id="section-2-2"><a href="https://www.iso.org/sites/directives/current/part2/index.xhtml">ISODIR2</a> - ISO/IEC Directives Part 2<a href="#section-2-2" class="pilcrow">¶</a></p>
+<p id="section-2-3"><a href="https://tools.ietf.org/html/rfc6749">RFC6749</a> - The OAuth 2.0 Authorization Framework<a href="#section-2-3" class="pilcrow">¶</a></p>
+<p id="section-2-4"><a href="https://tools.ietf.org/html/rfc6750">RFC6750</a> - The OAuth 2.0 Authorization Framework: Bearer Token Usage<a href="#section-2-4" class="pilcrow">¶</a></p>
+<p id="section-2-5"><a href="https://tools.ietf.org/html/rfc7636">RFC7636</a> - Proof Key for Code Exchange by OAuth Public Clients<a href="#section-2-5" class="pilcrow">¶</a></p>
+<p id="section-2-6"><a href="https://tools.ietf.org/html/rfc6819">RFC6819</a> - OAuth 2.0 Threat Model and Security Considerations<a href="#section-2-6" class="pilcrow">¶</a></p>
+<p id="section-2-7"><a href="https://tools.ietf.org/html/rfc7519">RFC7519</a> - JSON Web Token (JWT)<a href="#section-2-7" class="pilcrow">¶</a></p>
+<p id="section-2-8"><a href="https://tools.ietf.org/html/rfc7591">RFC7591</a> - OAuth 2.0 Dynamic Client Registration Protocol<a href="#section-2-8" class="pilcrow">¶</a></p>
+<p id="section-2-9"><a href="https://tools.ietf.org/html/rfc7592">RFC7592</a> - OAuth 2.0 Dynamic Client Registration Management Protocol<a href="#section-2-9" class="pilcrow">¶</a></p>
+<p id="section-2-10"><a href="https://tools.ietf.org/html/bcp195">BCP195</a> - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)<a href="#section-2-10" class="pilcrow">¶</a></p>
+<p id="section-2-11"><a href="https://openid.net/specs/openid-connect-core-1_0.html">OIDC</a> - OpenID Connect Core 1.0 incorporating errata set 1<a href="#section-2-11" class="pilcrow">¶</a></p>
+<p id="section-2-12"><a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md">FAPI-CIBA</a> - Financial-grade API: Client Initiated Backchannel Authentication Profile<a href="#section-2-12" class="pilcrow">¶</a></p>
+<p id="section-2-13"><a href="https://www.rfc-editor.org/rfc/rfc4514">RFC4514</a> - Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names<a href="#section-2-13" class="pilcrow">¶</a></p>
+<p id="section-2-14"><a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> -  OpenID Connect Discovery 1.0 incorporating errata set 1<a href="#section-2-14" class="pilcrow">¶</a></p>
+<p id="section-2-15"><a href="https://openid.net/specs/openid-connect-registration-1_0.html">OIDR</a> -  OpenID Connect Registration 1.0 incorporating errata set 1<a href="#section-2-15" class="pilcrow">¶</a></p>
+<p id="section-2-16"><a href="https://tools.ietf.org/html/rfc8705">RFC8705</a> - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens<a href="#section-2-16" class="pilcrow">¶</a></p>
+<p id="section-2-17"><a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_JWT_Secured_Authorization_Response_Mode.md">JARM</a> - Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)<a href="#section-2-17" class="pilcrow">¶</a></p>
+<p id="section-2-18"><a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a> - OAuth 2.0 Pushed Authorization Requests<a href="#section-2-18" class="pilcrow">¶</a></p>
+<p id="section-2-19"><a href="https://tools.ietf.org/html/draft-ietf-oauth-jwsreq">JAR</a> - OAuth 2.0 JWT Secured Authorization Request<a href="#section-2-19" class="pilcrow">¶</a></p>
+<p id="section-2-20"><a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">FAPI-1-Baseline</a> - Financial-grade API Security Profile 1.0 - Part 1: Baseline<a href="#section-2-20" class="pilcrow">¶</a></p>
+<p id="section-2-21"><a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">FAPI-1-Advanced</a> - Financial-grade API Security Profile 1.0 - Part 2: Advanced<a href="#section-2-21" class="pilcrow">¶</a></p>
+<p id="section-2-22"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">OBB-FAPI</a> - Open Banking Brasil Financial-grade API Security Profile 1.0<a href="#section-2-22" class="pilcrow">¶</a></p>
+<p id="section-2-23"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">OBB-Cert-Standards</a> - Open Banking Brasil x.509 Certificate Standards<a href="#section-2-23" class="pilcrow">¶</a></p>
+<p id="section-2-24"><a href="https://raw.githubusercontent.com/OpenBanking-Brasil/specs-seguranca/main/dcr_review/dcr-dcm-swagger.yaml">OBB-DCR/DCM-Swagger</a> - DCR & DCM Swagger<a href="#section-2-24" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="terms-and-definitions">
+<section id="section-3">
+      <h2 id="name-terms-and-definitions">
+<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-terms-and-definitions" class="section-name selfRef">Terms and definitions</a>
+      </h2>
+<p id="section-3-1">For the purpose of this document, the terms defined in <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>, <a href="https://tools.ietf.org/html/rfc6750">RFC6750</a>, <a href="https://tools.ietf.org/html/rfc7636">RFC7636</a>, <a href="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core</a> and ISO29100 apply.<a href="#section-3-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="symbols-and-abbreviated-terms">
+<section id="section-4">
+      <h2 id="name-symbols-and-abbreviated-ter">
+<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-symbols-and-abbreviated-ter" class="section-name selfRef">Symbols and Abbreviated terms</a>
+      </h2>
+<p id="section-4-1"><strong>SSA</strong> - Software Statement Assertion<a href="#section-4-1" class="pilcrow">¶</a></p>
+<p id="section-4-2"><strong>SS</strong> - Software Statement<a href="#section-4-2" class="pilcrow">¶</a></p>
+<p id="section-4-3"><strong>DCR</strong> - Dynamic Client Registration<a href="#section-4-3" class="pilcrow">¶</a></p>
+<p id="section-4-4"><strong>API</strong> - Application Programming Interface<a href="#section-4-4" class="pilcrow">¶</a></p>
+<p id="section-4-5"><strong>FAPI</strong> - Financial-grade API<a href="#section-4-5" class="pilcrow">¶</a></p>
+<p id="section-4-6"><strong>HTTP</strong> - Hyper Text Transfer Protocol<a href="#section-4-6" class="pilcrow">¶</a></p>
+<p id="section-4-7"><strong>OIDF</strong> - OpenID Foundation<a href="#section-4-7" class="pilcrow">¶</a></p>
+<p id="section-4-8"><strong>REST</strong> - Representational State Transfer<a href="#section-4-8" class="pilcrow">¶</a></p>
+<p id="section-4-9"><strong>TLS</strong> - Transport Layer Security<a href="#section-4-9" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="introduction">
+<section id="section-5">
+      <h2 id="name-introduction-2">
+<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-introduction-2" class="section-name selfRef">Introduction</a>
+      </h2>
+<p id="section-5-1">Brasil Open Bankings ecosystem leverages a federation trust provider or <em>directory of participants</em> as the golden source of information on accredited participants and software that are authorized to partake in the Open Banking Brasil ecosystem.<a href="#section-5-1" class="pilcrow">¶</a></p>
+<p id="section-5-2">The services by the Directory include<a href="#section-5-2" class="pilcrow">¶</a></p>
+<ul>
+<li id="section-5-3.1">
+          <p id="section-5-3.1.1">Software registration and management.<a href="#section-5-3.1.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-5-3.2">
+          <p id="section-5-3.2.1">Software credential registration and management using ICP Certificates.<a href="#section-5-3.2.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-5-3.3">
+          <p id="section-5-3.3.1">Software Statement Assertion (SSA) generation<a href="#section-5-3.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+<p id="section-5-4">Participants within the ecosystem must leverage these services to facilitate API driven OAuth client registration using the process outlined in clause 3.1.1 of <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a> with additional metadata necessary to support OpenID Connect defined in <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Registration</a>.<a href="#section-5-4" class="pilcrow">¶</a></p>
+<p id="section-5-5">It's important to remember that the client registration payload has most of its non-mandatory attributes, and that assigned values; that conflict with the present in the assertion software declaration <em>will be overridden by the values of the software statement assertion issued by the Directory of Participants</em>. Not all metadata that a client wishes to provide may be contained in a software statement, e.g alternative <a href="https://openid.net/specs/openid-connect-registration-1_0.html#LanguagesAndScripts">Metadata Languages and Script values</a>. There are some cases when the client metadata are subset os the existing values in the SSA, such as redirect_URIs.<a href="#section-5-5" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="open-banking-brasil-openid-connect-discovery-provisions">
+<section id="section-6">
+      <h2 id="name-open-banking-brasil-openid-">
+<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-open-banking-brasil-openid-" class="section-name selfRef">Open Banking Brasil OpenID Connect Discovery provisions</a>
+      </h2>
+<div id="authorization-server">
+<section id="section-6.1">
+        <h3 id="name-authorization-server">
+<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-authorization-server" class="section-name selfRef">Authorization server</a>
+        </h3>
+<p id="section-6.1-1">The Authorization Server shall support <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery</a> as required by <a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">Financial-grade API Security Profile 1.0 - Part 1: Baseline</a>.
+This support shall be explicit in Participant Directory configurations, and in the declaration of its attributes in the Discovery file (well-known), respecting the authentication mechanisms certified by the institution through the Open Banking Brazil compliance tests.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
+<p id="section-6.1-2">In addition, the Authorization Server<a href="#section-6.1-2" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal type-1" id="section-6.1-3">
+          <li id="section-6.1-3.1">
+            <p id="section-6.1-3.1.1">shall advertise its presence in the Open Banking Brasil ecosystem by being listed on the Directory of Participants;<a href="#section-6.1-3.1.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-6.1-3.2">
+            <p id="section-6.1-3.2.1">shall advertise all Open Banking Brasil REST API resources protected by the OpenID Provider on the Directory of Participants;<a href="#section-6.1-3.2.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-6.1-3.3">
+            <p id="section-6.1-3.3.1">shall advertise support for all signing, encryption, authentication mechanisms and standards required to support <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">Open Banking Brasil Financial API</a>;<a href="#section-6.1-3.3.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-6.1-3.4">
+            <p id="section-6.1-3.4.1">shall advertise support for <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Dynamic Client Registration</a>;<a href="#section-6.1-3.4.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-6.1-3.5">
+            <p id="section-6.1-3.5.1">shall advertise <code>mtls_endpoint_aliases</code> as per clause 5 <a href="https://tools.ietf.org/html/rfc8705">RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens</a> the <code>token_endpoint</code>, <code>registration_endpoint</code> and <code>userinfo_endpoint</code>;<a href="#section-6.1-3.5.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-6.1-3.6">
+            <p id="section-6.1-3.6.1">if supporting <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">OAuth 2.0 Pushed Authorization Requests</a> shall advertise through <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> <code>mtls_endpoint_aliases</code> the <code>pushed_authorization_request_endpoint</code>;<a href="#section-6.1-3.6.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-6.1-3.7">
+            <p id="section-6.1-3.7.1">if supporting <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md">Financial API - Client Initiated Back Channel Authentication</a> shall advertise through <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> <code>mtls_endpoint_aliases</code> the <code>backchannel_authentication_endpoint</code>;<a href="#section-6.1-3.7.1" class="pilcrow">¶</a></p>
+</li>
+</ol>
+</section>
+</div>
+<div id="client">
+<section id="section-6.2">
+        <h3 id="name-client">
+<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-client" class="section-name selfRef">Client</a>
+        </h3>
+<p id="section-6.2-1">The Client shall support <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery</a> as required by <a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">Financial-grade API Security Profile 1.0 - Part 1: Baseline</a><a href="#section-6.2-1" class="pilcrow">¶</a></p>
+<p id="section-6.2-2">In addition, the Client<a href="#section-6.2-2" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal type-1" id="section-6.2-3">
+          <li id="section-6.2-3.1">
+            <p id="section-6.2-3.1.1">shall rely on ecosystem discovery services provided by Directory of Participants only;<a href="#section-6.2-3.1.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-6.2-3.2">
+            <p id="section-6.2-3.2.1">shall derive necessary Authorisation Server metadata by relying on an Authorization Servers OpenID Connect Discovery services only;<a href="#section-6.2-3.2.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-6.2-3.3">
+            <p id="section-6.2-3.3.1">where present, shall use endpoints advertised in <code>mtls_endpoint_aliases</code> as per clause 5 <a href="https://tools.ietf.org/html/rfc8705">RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens</a>;<a href="#section-6.2-3.3.1" class="pilcrow">¶</a></p>
+</li>
+</ol>
+</section>
+</div>
+</section>
+</div>
+<div id="open-banking-brasil-openid-connect-registration-provisions">
+<section id="section-7">
+      <h2 id="name-open-banking-brasil-openid-c">
+<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-open-banking-brasil-openid-c" class="section-name selfRef">Open Banking Brasil OpenID Connect Registration Provisions</a>
+      </h2>
+<div id="authorization-server-1">
+<section id="section-7.1">
+        <h3 id="name-authorization-server-2">
+<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-authorization-server-2" class="section-name selfRef">Authorization server</a>
+        </h3>
+<p id="section-7.1-1">The Authorization Server shall support the RFC RFCs Dynamic Client Registration (DCR) <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a>,  Dynamic Client Management (DCM) <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a> and <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Registration</a><a href="#section-7.1-1" class="pilcrow">¶</a></p>
+<p id="section-7.1-2">In addition, the Authorization Server<a href="#section-7.1-2" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal type-1" id="section-7.1-3">
+          <li id="section-7.1-3.1">
+            <p id="section-7.1-3.1.1">shall reject dynamic client registration requests not performed over a connection secured with mutual tls using certificates issued by Brazil ICP (production) or the Directory of Participants (sandbox);<a href="#section-7.1-3.1.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1-3.2">
+            <p id="section-7.1-3.2.1">shall validate that the request contains software_statement JWT signed using the <code>PS256</code> algorithim issued by the Open Banking Brasil directory of participants;<a href="#section-7.1-3.2.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1-3.3">
+            <p id="section-7.1-3.3.1">shall validate that the <code>software_statement</code> was issued (iat) not more than 5 minutes prior to the request being received;<a href="#section-7.1-3.3.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1-3.4">
+            <p id="section-7.1-3.4.1">shall validate that the attribute <code>jwks</code> (key set by value) was <strong>not</strong> included; but declared as a reference in the <code>jwks_uri</code> attribute;<a href="#section-7.1-3.4.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1-3.5">
+            <p id="section-7.1-3.5.1">when the <code>jwks_uri</code> was informed, shall validate that matches the <code>software_jwks_uri</code> provided in the <code>software_statement</code>;<a href="#section-7.1-3.5.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1-3.6">
+            <p id="section-7.1-3.6.1">shall require and validate that <code>redirect_uris</code> match or contain a sub set of software<em>redirect</em>uris provided in the <code>software_statement</code>;<a href="#section-7.1-3.6.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1-3.7">
+            <p id="section-7.1-3.7.1">shall require and validate that all client authentication mechanism adhere to the requirements defined in <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a> and <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a>, validating the <code>registration_access_token</code> and using a secure connection, protected by certificate Issued from chain of certificates linked to ICP-Brasil;<a href="#section-7.1-3.7.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1-3.8">
+            <p id="section-7.1-3.8.1"><em>removed</em>;<a href="#section-7.1-3.8.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1-3.9">
+            <p id="section-7.1-3.9.1">shall validate that the requested scopes are adequate for accredited institutions and their regulatory roles and contained in the <code>software_statement</code>. The list of regulatory permissions and the corresponding scopes are described in the following sections;<a href="#section-7.1-3.9.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1-3.10">
+            <p id="section-7.1-3.10.1">where possible, shall compare client metadata asserted by a client toward the metadata provided into  <code>software_statement</code>, choosing the values present in the SSA with precedence;<a href="#section-7.1-3.10.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1-3.11">
+            <p id="section-7.1-3.11.1">shall accept all x.500 AttributeType name strings defined in the Distinguished Name of the x.509 Certificate Profiles defined in <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a>;<a href="#section-7.1-3.11.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1-3.12">
+            <p id="section-7.1-3.12.1">if supporting <code>tls_client_auth</code> client authentication mechanism as defined in <a href="https://tools.ietf.org/html/rfc8705">RFC8705</a> shall only accept <code>tls_client_auth_subject_dn</code>  as an indication of the certificate subject value as defined in clause 2.1.2 <a href="https://tools.ietf.org/html/rfc8705">RFC8705</a>;<a href="#section-7.1-3.12.1" class="pilcrow">¶</a></p>
+</li>
+</ol>
+<p id="section-7.1-4">These provisions apply equally to the processing of <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a>, <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a> and <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Registration</a> requests<a href="#section-7.1-4" class="pilcrow">¶</a></p>
+<div id="applying-server-defaults">
+<section id="section-7.1.1">
+          <h4 id="name-applying-server-defaults">
+<a href="#section-7.1.1" class="section-number selfRef">7.1.1. </a><a href="#name-applying-server-defaults" class="section-name selfRef">Applying Server Defaults</a>
+          </h4>
+<p id="section-7.1.1-1">Where properties of a DCR request are not included and are not mandatory in the specification the Authorisation Server shall apply client defaults in the following manner<a href="#section-7.1.1-1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="normal type-1" id="section-7.1.1-2">
+            <li id="section-7.1.1-2.1">
+              <p id="section-7.1.1-2.1.1">shall select and apply the encryption algorithm and cipher choice from the most recommended of the IANA cipher suites that is supported by the Authorisation Server;<a href="#section-7.1.1-2.1.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1.1-2.2">
+              <p id="section-7.1.1-2.2.1">shall populate defaults from values within the <code>software_statement</code> assertion where possible;<a href="#section-7.1.1-2.2.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1.1-2.3">
+              <p id="section-7.1.1-2.3.1">shall grant the client permission to the complete set of potential scopes based on the softwares regulatory permissions included in the <code>software_statement</code>;<a href="#section-7.1.1-2.3.1" class="pilcrow">¶</a></p>
+</li>
+</ol>
+</section>
+</div>
+<div id="certificate-distinguished-name-parsing">
+<section id="section-7.1.2">
+          <h4 id="name-certificate-distinguished-n">
+<a href="#section-7.1.2" class="section-number selfRef">7.1.2. </a><a href="#name-certificate-distinguished-n" class="section-name selfRef">Certificate Distinguished Name Parsing</a>
+          </h4>
+<p id="section-7.1.2-1">Clause 3 of <a href="https://www.rfc-editor.org/rfc/rfc4514">Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names</a> defines the mandatory OIDs whose AttributeType strings (descriptors) must be recognized by implementers. This mandatory list does not include several of the OIDs defined in <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a> nor is there a defined mechanism for Authorisation Servers to publish  information regarding the format that they would expect a Dynamic Client Registration request that includes a <code>tls_client_auth_subject_dn</code> to be presented in.<a href="#section-7.1.2-1" class="pilcrow">¶</a></p>
+<p id="section-7.1.2-2">To address this ambiguity, the Authorization Server must accept only the AttributeTypes name strings (descriptors) defined in the last paragraph of clause 3 <a href="https://www.rfc-editor.org/rfc/rfc4514">RFC4514</a> in string format, it shall also accept in OID format, with their values in ASN.1, all the AttributeTypes defined in Distinguished Name <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a> or added by the Certificate Authority.<a href="#section-7.1.2-2" class="pilcrow">¶</a></p>
+<p id="section-7.1.2-3">In case of non-compliance with these requirements, the Authorization Server shall reject the registration.<a href="#section-7.1.2-3" class="pilcrow">¶</a></p>
+<p id="section-7.1.2-4">In terms of format, follow below how decoding should be done:<a href="#section-7.1.2-4" class="pilcrow">¶</a></p>
+<ul>
+<li id="section-7.1.2-5.1">
+              <p id="section-7.1.2-5.1.1">Start backwards, the order is reversed from what is entered.<a href="#section-7.1.2-5.1.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1.2-5.2">
+              <p id="section-7.1.2-5.2.1">Append each RDN (RelativeDistinguishedName) segment with a comma ','.<a href="#section-7.1.2-5.2.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-7.1.2-5.3">
+              <p id="section-7.1.2-5.3.1">Use the RFC strings (CN, L, ST, O, OR, C, Street, DC, UID) with the value of their attributes in "printable string", ie human-readable + the OIDs of the attributes defined in this specification for use in Distinguished Name <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a> (businessCategory=OID 2.5.4.15,jurisdictionCountryName=OID: 1.3.6.1.4.1.311.60.2.1.3, serialNumber=OID:2.5.4.5) with the value of your attributes in ASN.1 format.<a href="#section-7.1.2-5.3.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+<p id="section-7.1.2-6">Examples:<a href="#section-7.1.2-6" class="pilcrow">¶</a></p>
+<table class="center" id="table-1">
+            <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
+<thead>
+              <tr>
+                <th class="text-left" rowspan="1" colspan="1">subject_dn</th>
+                <th class="text-left" rowspan="1" colspan="1">Issuer</th>
+              </tr>
+            </thead>
+            <tbody>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839, CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L= BRASILIA, ST=DF, C=BR</td>
+                <td class="text-left" rowspan="1" colspan="1">issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, CN=mycn.bank.gov.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L=BRASILIA, ST=DF, C=BR</td>
+                <td class="text-left" rowspan="1" colspan="1">issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, UID=67c57882-043b-11ec-9a03-0242ac130003, CN=openbanking.mybank.com.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Goiania, ST=GO, O=MyBank SA, C=BR</td>
+                <td class="text-left" rowspan="1" colspan="1">issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR</td>
+              </tr>
+              <tr>
+                <td class="text-left" rowspan="1" colspan="1">CN=mycn.bank.com.br, UID=67c57882-043b-11ec-9a03-0242ac130003, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Sao Paulo, ST=SP, O=MyBank SA, C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e</td>
+                <td class="text-left" rowspan="1" colspan="1">issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR</td>
+              </tr>
+            </tbody>
+          </table>
+</section>
+</div>
+</section>
+</div>
+<div id="regulatory-roles-to-openid-and-oauth-2-0-mappings">
+<section id="section-7.2">
+        <h3 id="name-regulatory-roles-to-openid-">
+<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-regulatory-roles-to-openid-" class="section-name selfRef">Regulatory Roles to OpenID and OAuth 2.0 Mappings</a>
+        </h3>
+<p id="section-7.2-1">To participate in the Open Banking ecosystem, accredited institutions must register themselves in the directory of participants according to their regulatory roles. Those roles reflect the institutions' authorization from the Central Bank and, consequently, the APIs they are allowed to use.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
+<p id="section-7.2-2">The following table describes the regulatory roles for Open Banking and the related OAuth 2.0 scopes mapping. If the scopes are omitted during the DCR process, the authorization server shall grant the complete set of potential scopes based on the registering bank's regulatory roles, as described in the Server Defaults section.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
+<table class="center" id="table-2">
+          <caption><a href="#table-2" class="selfRef">Table 2</a></caption>
+<thead>
+            <tr>
+              <th class="text-left" rowspan="1" colspan="1">Regulatory Role</th>
+              <th class="text-left" rowspan="1" colspan="1">Description</th>
+              <th class="text-left" rowspan="1" colspan="1">Allowed Scopes</th>
+              <th class="text-left" rowspan="1" colspan="1">Target Phase</th>
+            </tr>
+          </thead>
+          <tbody>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">DADOS</td>
+              <td class="text-left" rowspan="1" colspan="1">Institui&#231;&#227;o transmissora ou receptora de dados (AISP)</td>
+              <td class="text-left" rowspan="1" colspan="1">openid accounts credit-cards-accounts consents customers invoice-financings financings loans unarranged-accounts-overdraft resources</td>
+              <td class="text-left" rowspan="1" colspan="1">Phase 2</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">PAGTO</td>
+              <td class="text-left" rowspan="1" colspan="1">Institui&#231;&#227;o prestadora de servi&#231;o de inicia&#231;&#227;o de pagamentos (PISP)</td>
+              <td class="text-left" rowspan="1" colspan="1">openid payments consents resources</td>
+              <td class="text-left" rowspan="1" colspan="1">Phase 3</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">CONTA</td>
+              <td class="text-left" rowspan="1" colspan="1">Institui&#231;&#227;o detentora de conta (ASPSP)</td>
+              <td class="text-left" rowspan="1" colspan="1">openid</td>
+              <td class="text-left" rowspan="1" colspan="1">Phase 3</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">CCORR</td>
+              <td class="text-left" rowspan="1" colspan="1">Correspondente de cr&#233;dito</td>
+              <td class="text-left" rowspan="1" colspan="1">openid</td>
+              <td class="text-left" rowspan="1" colspan="1">Phase 3*</td>
+            </tr>
+          </tbody>
+        </table>
+<div id="implementers-note">
+<section id="section-7.2.1">
+          <h4 id="name-implementers-note">
+<a href="#section-7.2.1" class="section-number selfRef">7.2.1. </a><a href="#name-implementers-note" class="section-name selfRef">Implementers Note</a>
+          </h4>
+<p id="section-7.2.1-1">In line with guidance from the IETF and the direction of travel for fine-grained consent management. The obligation falls to the Authorisation Server to ensure that there is sufficient scope conveyed in an access token necessary to fulfill the Permissions conveyed in the Consent Request. This principle and requirement is reflected in the forthcoming Grant Management API.<a href="#section-7.2.1-1" class="pilcrow">¶</a></p>
+</section>
+</div>
+</section>
+</div>
+<div id="regulatory-roles-to-dynamic-oauth-2-0-scope-mappings">
+<section id="section-7.3">
+        <h3 id="name-regulatory-roles-to-dynamic">
+<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-regulatory-roles-to-dynamic" class="section-name selfRef">Regulatory Roles to dynamic OAuth 2.0 scope Mappings</a>
+        </h3>
+<table class="center" id="table-3">
+          <caption><a href="#table-3" class="selfRef">Table 3</a></caption>
+<thead>
+            <tr>
+              <th class="text-left" rowspan="1" colspan="1">Regulatory Role</th>
+              <th class="text-left" rowspan="1" colspan="1">Allowed Scopes</th>
+            </tr>
+          </thead>
+          <tbody>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">DADOS</td>
+              <td class="text-left" rowspan="1" colspan="1">consent:{ConsentId}</td>
+            </tr>
+            <tr>
+              <td class="text-left" rowspan="1" colspan="1">PAGTO</td>
+              <td class="text-left" rowspan="1" colspan="1">consent:{ConsentId}</td>
+            </tr>
+          </tbody>
+        </table>
+</section>
+</div>
+</section>
+</div>
+<div id="software-statement">
+<section id="section-8">
+      <h2 id="name-software-statement">
+<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-software-statement" class="section-name selfRef">Software Statement</a>
+      </h2>
+<blockquote id="section-8-1">
+        <p id="section-8-1.1">A software statement is a JSON Web Token (JWT) <a href="https://tools.ietf.org/html/rfc7519">RFC7519</a> that asserts metadata values about the client software as a bundle.<a href="#section-8-1.1" class="pilcrow">¶</a></p>
+</blockquote>
+<div id="software-statement-claims">
+<section id="section-8.1">
+        <h3 id="name-software-statement-claims">
+<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-software-statement-claims" class="section-name selfRef">Software Statement Claims</a>
+        </h3>
+<p id="section-8.1-1">The following example contains all of the claims currently included in a software statement<a href="#section-8.1-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-8.1-2">
+<pre>{
+  "software_mode": "Live",
+  "software_redirect_uris": [
+    "https://www.raidiam.com/accounting/cb"
+  ],
+  "software_statement_roles": [
+    {
+      "role": "DADOS",
+      "authorisation_domain": "Open Banking",
+      "status": "Active"
+    },
+    {
+      "role": "PAGTO",
+      "authorisation_domain": "Open Banking",
+      "status": "Active"
+    }
+  ],
+  "software_client_name": "Raidiam Accounting",
+  "org_status": "Active",
+  "software_client_id": "Cki1EbvjwyhPB12NGLlz2",
+  "iss": "Open Banking Open Banking Brasil prod SSA issuer",
+  "software_tos_uri": "https://www.raidiam.com/accounting/tos.html",
+  "software_client_description": "Raidiam Accounting leverage cutting edge open banking access to bring you real time up to date views of your finances",
+  "software_jwks_uri": "https://keystore.directory.openbankingbrasil.org.br/b961c4eb-509d-4edf-afeb-35642b38185d/25556d5a-b9dd-4e27-aa1a-cce732fe74de/application.jwks",
+  "software_policy_uri": "https://www.raidiam.com/accounting/policy.html",
+  "software_id": "25556d5a-b9dd-4e27-aa1a-cce732fe74de",
+  "software_client_uri": "https://www.raidiam.com/accounting.html",
+  "software_jwks_inactive_uri": "https://keystore.directory.openbankingbrasil.org.br/b961c4eb-509d-4edf-afeb-35642b38185d/25556d5a-b9dd-4e27-aa1a-cce732fe74de/inactive/application.jwks",
+  "software_jwks_transport_inactive_uri": "https://keystore.directory.openbankingbrasil.org.br/b961c4eb-509d-4edf-afeb-35642b38185d/25556d5a-b9dd-4e27-aa1a-cce732fe74de/inactive/transport.jwks",
+  "software_jwks_transport_uri": "https://keystore.directory.openbankingbrasil.org.br/b961c4eb-509d-4edf-afeb-35642b38185d/25556d5a-b9dd-4e27-aa1a-cce732fe74de/transport.jwks",
+  "software_logo_uri": "https://www.raidiam.com/accounting/logo.png",
+  "org_id": "b961c4eb-509d-4edf-afeb-35642b38185d",
+  "org_number": "112233445566",
+  "software_environment": "production",
+  "software_version": "1.1",
+  "software_roles": [
+    "DADOS",
+    "PAGTO"
+  ],
+  "org_name": "Open Banking Brasil",
+  "iat": 1620060821,
+  "organisation_competent_authority_claims": [
+    {
+      "authorisation_domain": "Open Banking",
+      "authorisations": [],
+      "registration_id": "13353236-OBB-CONTA",
+      "authority_id": "687a1c94-b360-4e04-9589-0fa5cb16451b",
+      "authority_name": "Banco Central",
+      "authorisation_role": "CONTA",
+      "authority_code": "BCB",
+      "status": "Active"
+    },
+    {
+      "authorisation_domain": "Open Banking",
+      "authorisations": [],
+      "registration_id": "13353236-OBB-DADOS",
+      "authority_id": "687a1c94-b360-4e04-9589-0fa5cb16451b",
+      "authority_name": "Banco Central",
+      "authorisation_role": "DADOS",
+      "authority_code": "BCB",
+      "status": "Active"
+    },
+    {
+      "authorisation_domain": "Open Banking",
+      "authorisations": [],
+      "registration_id": "13353236-OBB-PAGTO",
+      "authority_id": "687a1c94-b360-4e04-9589-0fa5cb16451b",
+      "authority_name": "Banco Central",
+      "authorisation_role": "PAGTO",
+      "authority_code": "BCB",
+      "status": "Active"
+    }
+  ]
+}
+</pre><a href="#section-8.1-2" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="dynamic-client-registration-request-processing">
+<section id="section-9">
+      <h2 id="name-dynamic-client-registration">
+<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-dynamic-client-registration" class="section-name selfRef">Dynamic Client Registration Request Processing</a>
+      </h2>
+	  	  	  <p><img src="images/dynamic-client-registration.png" alt="Dynamic Client Registration Request Processing" /></p>
+<div id="posting-a-request-with-a-software-statement">
+<section id="section-9.1">
+        <h3 id="name-posting-a-request-with-a-so">
+<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-posting-a-request-with-a-so" class="section-name selfRef">Posting a request with a software statement</a>
+        </h3>
+<p id="section-9.1-1">This example includes various optional fields, some of which may not be applicable to some deployments. For a complete guide to the attributes and their requirements, consult the Swagger DCR/DCM link: <a href="https://raw.githubusercontent.com/OpenBanking-Brasil/specs-seguranca/main/dcr_review/dcr-dcm-swagger.yaml">OBB-DCR/DCM-Swagger</a> .
+Line wraps within values are for display purposes only.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
+<div class="artwork art-text alignLeft" id="section-9.1-2">
+<pre>POST /reg HTTP/1.1
+Host: auth.raidiam.com
+Content-Type: application/json
+{
+"application_type": "web",
+"grant_types": [
+    "client_credentials",
+    "authorization_code",
+    "refresh_token",
+    "implicit"
+],
+"id_token_signed_response_alg": "PS256",
+"require_auth_time": false,
+"response_types": [
+    "code id_token",
+    "id_token"
+],
+"software_statement": "eyJraWQiOiJzaWduZXIiLCJ0eXAiOiJKV1QiLCJhbGciOiJQUzI1NiJ9.eyJzb2Z0d2FyZV9tb2RlIjoiTGl2ZSIsInNvZnR3YXJlX3JlZGlyZWN0X3VyaXMiOlsiaHR0cHM6XC9cL3d3dy5yYWlkaWFtLmNvbVwvYWNjb3VudGluZ1wvY2IiXSwic29mdHdhcmVfc3RhdGVtZW50X3JvbGVzIjpbeyJyb2xlIjoiREFET1MiLCJhdXRob3Jpc2F0aW9uX2RvbWFpbiI6Ik9wZW4gQmFua2luZyIsInN0YXR1cyI6IkFjdGl2ZSJ9LHsicm9sZSI6IlBBR1RPIiwiYXV0aG9yaXNhdGlvbl9kb21haW4iOiJPcGVuIEJhbmtpbmciLCJzdGF0dXMiOiJBY3RpdmUifV0sInNvZnR3YXJlX2NsaWVudF9uYW1lIjoiUmFpZGlhbSBBY2NvdW50aW5nIiwib3JnX3N0YXR1cyI6IkFjdGl2ZSIsInNvZnR3YXJlX2NsaWVudF9pZCI6IkNraTFFYnZqd3loUEIxMk5HTGx6MiIsImlzcyI6Ik9wZW4gQmFua2luZyBPcGVuIEJhbmtpbmcgQnJhc2lsIHByb2QgU1NBIGlzc3VlciIsInNvZnR3YXJlX3Rvc191cmkiOiJodHRwczpcL1wvd3d3LnJhaWRpYW0uY29tXC9hY2NvdW50aW5nXC90b3MuaHRtbCIsInNvZnR3YXJlX2NsaWVudF9kZXNjcmlwdGlvbiI6IlJhaWRpYW0gQWNjb3VudGluZyBsZXZlcmFnZSBjdXR0aW5nIGVkZ2Ugb3BlbiBiYW5raW5nIGFjY2VzcyB0byBicmluZyB5b3UgcmVhbCB0aW1lIHVwIHRvIGRhdGUgdmlld3Mgb2YgeW91ciBmaW5hbmNlcyIsInNvZnR3YXJlX2p3a3NfZW5kcG9pbnQiOiJodHRwczpcL1wva2V5c3RvcmUuZGlyZWN0b3J5Lm9wZW5iYW5raW5nYnJhc2lsLm9yZy5iclwvYjk2MWM0ZWItNTA5ZC00ZWRmLWFmZWItMzU2NDJiMzgxODVkXC8yNTU1NmQ1YS1iOWRkLTRlMjctYWExYS1jY2U3MzJmZTc0ZGVcL2FwcGxpY2F0aW9uLmp3a3MiLCJzb2Z0d2FyZV9wb2xpY3lfdXJpIjoiaHR0cHM6XC9cL3d3dy5yYWlkaWFtLmNvbVwvYWNjb3VudGluZ1wvcG9saWN5Lmh0bWwiLCJzb2Z0d2FyZV9pZCI6IjI1NTU2ZDVhLWI5ZGQtNGUyNy1hYTFhLWNjZTczMmZlNzRkZSIsInNvZnR3YXJlX2NsaWVudF91cmkiOiJodHRwczpcL1wvd3d3LnJhaWRpYW0uY29tXC9hY2NvdW50aW5nLmh0bWwiLCJzb2Z0d2FyZV9qd2tzX2luYWN0aXZlX2VuZHBvaW50IjoiaHR0cHM6XC9cL2tleXN0b3JlLmRpcmVjdG9yeS5vcGVuYmFua2luZ2JyYXNpbC5vcmcuYnJcL2I5NjFjNGViLTUwOWQtNGVkZi1hZmViLTM1NjQyYjM4MTg1ZFwvMjU1NTZkNWEtYjlkZC00ZTI3LWFhMWEtY2NlNzMyZmU3NGRlXC9pbmFjdGl2ZVwvYXBwbGljYXRpb24uandrcyIsInNvZnR3YXJlX2p3a3NfdHJhbnNwb3J0X2luYWN0aXZlX2VuZHBvaW50IjoiaHR0cHM6XC9cL2tleXN0b3JlLmRpcmVjdG9yeS5vcGVuYmFua2luZ2JyYXNpbC5vcmcuYnJcL2I5NjFjNGViLTUwOWQtNGVkZi1hZmViLTM1NjQyYjM4MTg1ZFwvMjU1NTZkNWEtYjlkZC00ZTI3LWFhMWEtY2NlNzMyZmU3NGRlXC9pbmFjdGl2ZVwvdHJhbnNwb3J0Lmp3a3MiLCJzb2Z0d2FyZV9qd2tzX3RyYW5zcG9ydF9lbmRwb2ludCI6Imh0dHBzOlwvXC9rZXlzdG9yZS5kaXJlY3Rvcnkub3BlbmJhbmtpbmdicmFzaWwub3JnLmJyXC9iOTYxYzRlYi01MDlkLTRlZGYtYWZlYi0zNTY0MmIzODE4NWRcLzI1NTU2ZDVhLWI5ZGQtNGUyNy1hYTFhLWNjZTczMmZlNzRkZVwvdHJhbnNwb3J0Lmp3a3MiLCJzb2Z0d2FyZV9sb2dvX3VyaSI6Imh0dHBzOlwvXC93d3cucmFpZGlhbS5jb21cL2FjY291bnRpbmdcL2xvZ28ucG5nIiwib3JnX2lkIjoiYjk2MWM0ZWItNTA5ZC00ZWRmLWFmZWItMzU2NDJiMzgxODVkIiwic29mdHdhcmVfZW52aXJvbm1lbnQiOiJwcm9kdWN0aW9uIiwic29mdHdhcmVfdmVyc2lvbiI6MS4xMCwic29mdHdhcmVfcm9sZXMiOlsiREFET1MiLCJQQUdUTyJdLCJvcmdfbmFtZSI6Ik9wZW4gQmFua2luZyBCcmFzaWwiLCJpYXQiOjE2MTgzMzYyNjIsIm9yZ2FuaXNhdGlvbl9jb21wZXRlbnRfYXV0aG9yaXR5X2NsYWltcyI6W3siYXV0aG9yaXNhdGlvbl9kb21haW4iOiJPcGVuIEJhbmtpbmciLCJhdXRob3Jpc2F0aW9ucyI6W10sInJlZ2lzdHJhdGlvbl9pZCI6IjEzMzUzMjM2LU9CQi1DT05UQSIsImF1dGhvcml0eV9pZCI6IjY4N2ExYzk0LWIzNjAtNGUwNC05NTg5LTBmYTVjYjE2NDUxYiIsImF1dGhvcmlzYXRpb25fcm9sZSI6IkNPTlRBIiwiYXV0aG9yaXR5X2NvZGUiOiJCQ0IiLCJzdGF0dXMiOiJBY3RpdmUifSx7ImF1dGhvcmlzYXRpb25fZG9tYWluIjoiT3BlbiBCYW5raW5nIiwiYXV0aG9yaXNhdGlvbnMiOltdLCJyZWdpc3RyYXRpb25faWQiOiIxMzM1MzIzNi1PQkItREFET1MiLCJhdXRob3JpdHlfaWQiOiI2ODdhMWM5NC1iMzYwLTRlMDQtOTU4OS0wZmE1Y2IxNjQ1MWIiLCJhdXRob3Jpc2F0aW9uX3JvbGUiOiJEQURPUyIsImF1dGhvcml0eV9jb2RlIjoiQkNCIiwic3RhdHVzIjoiQWN0aXZlIn0seyJhdXRob3Jpc2F0aW9uX2RvbWFpbiI6Ik9wZW4gQmFua2luZyIsImF1dGhvcmlzYXRpb25zIjpbXSwicmVnaXN0cmF0aW9uX2lkIjoiMTMzNTMyMzYtT0JCLVBBR1RPIiwiYXV0aG9yaXR5X2lkIjoiNjg3YTFjOTQtYjM2MC00ZTA0LTk1ODktMGZhNWNiMTY0NTFiIiwiYXV0aG9yaXNhdGlvbl9yb2xlIjoiUEFHVE8iLCJhdXRob3JpdHlfY29kZSI6IkJDQiIsInN0YXR1cyI6IkFjdGl2ZSJ9XX0.W6hUAYhjT6I61rxEIVMKYKre93LTbRdzKnk9dJvUdzVgAz5B9KxZNutf27oO3k0hrjYVWBdWq23o_e4Y_AaKdpS9-rtU84JiHtmqV0wcFYIM8nqcUVWqQ-Ux6Nq9L2G-s2YNd3PcJ1e3yGg9h8553Gr7iJusKEgApzXUpkM2rBELQuumktUE_JBiuIkXmWxoRnO1cW-Osbk3MT3bxG43SPcxii07Q5S8qXI6PjCPA3fYlnaUAygwZM3O0oa7jqmSr7d9UsHuDMJfYhIKdq2wyQQKORCN-D2UopmMX-lHMvAVkkrAO08T0-7odjr4PJk-PrwuoCxeAfa7440ZDOrlmQ",
+"subject_type": "public",
+"token_endpoint_auth_method": "private_key_jwt",
+"introspection_endpoint_auth_method": "private_key_jwt",
+"revocation_endpoint_auth_method": "private_key_jwt",
+"request_object_signing_alg": "PS256",
+"require_signed_request_object": true,
+"require_pushed_authorization_requests": false,
+"tls_client_certificate_bound_access_tokens": true,
+"client_id": "aCnBHjZBvD6ku3KVBaslL",
+"client_name": "Raidiam Accounting",
+"client_uri": "https://www.raidiam.com/accounting.html",
+"request_object_encryption_alg": "RSA-OAEP",
+"request_object_encryption_enc": "A256GCM"
+"jwks_uri": "https://keystore.directory.openbankingbrasil.org.br/b961c4eb-509d-4edf-afeb-35642b38185d/25556d5a-b9dd-4e27-aa1a-cce732fe74de/application.jwks",
+"redirect_uris": [
+    "https://www.raidiam.com/accounting/cb"
+]
+}
+</pre><a href="#section-9.1-2" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+<div id="open-banking-brasil-ssa-key-store-and-issuer-details">
+<section id="section-9.2">
+        <h3 id="name-open-banking-brasil-ssa-key">
+<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-open-banking-brasil-ssa-key" class="section-name selfRef">Open Banking Brasil SSA Key Store and Issuer Details</a>
+        </h3>
+<p id="section-9.2-1"><strong>Production</strong><a href="#section-9.2-1" class="pilcrow">¶</a></p>
+<p id="section-9.2-2"><a href="https://keystore.directory.openbankingbrasil.org.br/openbanking.jwks">https://keystore.directory.openbankingbrasil.org.br/openbanking.jwks</a><a href="#section-9.2-2" class="pilcrow">¶</a></p>
+<p id="section-9.2-3">Open Banking Open Banking Brasil production SSA issuer<a href="#section-9.2-3" class="pilcrow">¶</a></p>
+<p id="section-9.2-4"><strong>Sandbox</strong><a href="#section-9.2-4" class="pilcrow">¶</a></p>
+<p id="section-9.2-5"><a href="https://keystore.sandbox.directory.openbankingbrasil.org.br/openbanking.jwks">https://keystore.sandbox.directory.openbankingbrasil.org.br/openbanking.jwks</a><a href="#section-9.2-5" class="pilcrow">¶</a></p>
+<p id="section-9.2-6">Open Banking Open Banking Brasil sandbox SSA issuer<a href="#section-9.2-6" class="pilcrow">¶</a></p>
+</section>
+</div>
+<div id="about-authentication-and-authorization-mechanisms-for-dcr-and-dcm-services">
+<section id="section-9.3">
+        <h3 id="name-about-authentication-and-au">
+<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-about-authentication-and-au" class="section-name selfRef">About authentication and authorization mechanisms for DCR and DCM services</a>
+        </h3>
+<p id="section-9.3-1">As they are auxiliary services to the main flow of Open Banking Brasil, the dynamic registration and maintenance services for clients cannot use the exact access control mechanisms.  For example, it is not possible to require an OAuth 2.0 <em>access_token</em> from a client application that isn't registered yet with the transmitting institution.<a href="#section-9.3-1" class="pilcrow">¶</a></p>
+<p id="section-9.3-2">To extend <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a> and <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a>, which recommend minimum mechanisms for authentication of their services, institutions that support the registration flows and dynamic maintenance of clients must implement the following controls:<a href="#section-9.3-2" class="pilcrow">¶</a></p>
+<div id="client-registration-post-register">
+<section id="section-9.3.1">
+          <h4 id="name-client-registration-post-re">
+<a href="#section-9.3.1" class="section-number selfRef">9.3.1. </a><a href="#name-client-registration-post-re" class="section-name selfRef">Client registration - POST /register</a>
+          </h4>
+<ol start="1" type="1" class="normal type-1" id="section-9.3.1-1">
+            <li id="section-9.3.1-1.1">
+              <p id="section-9.3.1-1.1.1">validate that the certificate presented by the client application is subordinate to the ICP-Brasil chains defined in the Open Banking Brasil Certificates Standard;<a href="#section-9.3.1-1.1.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-9.3.1-1.2">
+              <p id="section-9.3.1-1.2.1">ensure that the signature of the <code>software_statement</code>_ presented by the client application during registration has been made by the Directory of Participants using the public keys described in the previous section;<a href="#section-9.3.1-1.2.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-9.3.1-1.3">
+              <p id="section-9.3.1-1.3.1">ensure that the <code>software_statement</code> presented by the client application during registration corresponds to the same institution as the client certificate presented, validating it through the attributes that bring <code>organization_id</code> in the X.509 certificate.<a href="#section-9.3.1-1.3.1" class="pilcrow">¶</a></p>
+</li>
+</ol>
+</section>
+</div>
+<div id="client-maintenance-get-register-put-register-delete-register">
+<section id="section-9.3.2">
+          <h4 id="name-client-maintenance-get-regi">
+<a href="#section-9.3.2" class="section-number selfRef">9.3.2. </a><a href="#name-client-maintenance-get-regi" class="section-name selfRef">Client Maintenance - GET /register - PUT /register - DELETE /register</a>
+          </h4>
+<ol start="1" type="1" class="normal type-1" id="section-9.3.2-1">
+            <li id="section-9.3.2-1.1">
+              <p id="section-9.3.2-1.1.1">validate that the certificate presented by the client application is subordinate to the ICP-Brasil chains defined in the Open Banking Brasil Certificates Standard;<a href="#section-9.3.2-1.1.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-9.3.2-1.2">
+              <p id="section-9.3.2-1.2.1">Validate the presence and matching of the Bearer header <code>Authorization</code> containing the value of the <code>registration_access_token</code> attribute returned during registration of the corresponding client.<a href="#section-9.3.2-1.2.1" class="pilcrow">¶</a></p>
+</li>
+</ol>
+</section>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="acknowledgement">
+<section id="section-10">
+      <h2 id="name-acknowledgement">
+<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-acknowledgement" class="section-name selfRef">Acknowledgement</a>
+      </h2>
+<p id="section-10-1">With thanks to all who have set the foundations for secure and safe data sharing through the formation of the OpenID Foundation FAPI Working Group, the Open Banking Brasil GT Security and to the pioneers who will stand on their shoulders.<a href="#section-10-1" class="pilcrow">¶</a></p>
+<p id="section-10-2">The following people contributed to this document:<a href="#section-10-2" class="pilcrow">¶</a></p>
+<ul>
+<li id="section-10-3.1">
+          <p id="section-10-3.1.1">Ralph Bragg (Raidiam)<a href="#section-10-3.1.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-10-3.2">
+          <p id="section-10-3.2.1">Alexandre Siqueira (Mercado Pago)<a href="#section-10-3.2.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-10-3.3">
+          <p id="section-10-3.3.1">Bernardo Vale (Banco Inter)<a href="#section-10-3.3.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-10-3.4">
+          <p id="section-10-3.4.1">Andr&#233; Borges (Banco Fibra)<a href="#section-10-3.4.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-10-3.5">
+          <p id="section-10-3.5.1">Danilo Sasaki (Banco Ita&#250;)<a href="#section-10-3.5.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-10-3.6">
+          <p id="section-10-3.6.1">Jo&#227;o Rodolfo Vieira da Silva (Banco Ita&#250;)<a href="#section-10-3.6.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-10-3.7">
+          <p id="section-10-3.7.1">Michelle Bandarra (Chicago)<a href="#section-10-3.7.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-10-3.8">
+          <p id="section-10-3.8.1">Alexandre Daniel Dalabrida (Cooperativa Central Ailos)<a href="#section-10-3.8.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-10-3.9">
+          <p id="section-10-3.9.1">Rafael Gonzalez Hashimoto - (Banco C6)<a href="#section-10-3.9.1" class="pilcrow">¶</a></p>
+</li>
+</ul>
+</section>
+</div>
+<div id="notices">
+<section id="section-appendix.a">
+      <h2 id="name-notices">
+<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-notices" class="section-name selfRef">Notices</a>
+      </h2>
+<p id="section-appendix.a-1">Copyright (c) 2021 Open Banking Brasil Initial Structure.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
+<p id="section-appendix.a-2">The Open Banking Brasil Initial Structure (OBBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OBBIS as the source of the material, but that such attribution does not indicate an endorsement by the OBBIS.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
+<p id="section-appendix.a-3">The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation, the Open Banking Brasil GT Security Working Group and others. Although the Open Banking Brasil Initial Structure has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The Open Banking Brasil Initial Structure and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The Open Banking Brasil Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The Open Banking Brasil Initial Structure invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
+<div id="appendix-a-example-software-statement-assertion">
+<section id="section-a.1">
+        <h2 id="name-appendix-a-example-software">
+<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-appendix-a-example-software" class="section-name selfRef">Appendix A. Example Software Statement Assertion</a>
+        </h2>
+<div class="artwork art-text alignLeft" id="section-a.1-1">
+<pre>eyJraWQiOiJzaWduZXIiLCJ0eXAiOiJKV1QiLCJhbGciOiJQUzI1NiJ9.eyJzb2Z0d2FyZV9tb2RlIjoiTGl2ZSIsInNvZnR3YXJlX3JlZGlyZWN0X3VyaXMiOlsiaHR0cHM6XC9cL3d3dy5yYWlkaWFtLmNvbVwvYWNjb3VudGluZ1wvY2IiXSwic29mdHdhcmVfc3RhdGVtZW50X3JvbGVzIjpbeyJyb2xlIjoiREFET1MiLCJhdXRob3Jpc2F0aW9uX2RvbWFpbiI6Ik9wZW4gQmFua2luZyIsInN0YXR1cyI6IkFjdGl2ZSJ9LHsicm9sZSI6IlBBR1RPIiwiYXV0aG9yaXNhdGlvbl9kb21haW4iOiJPcGVuIEJhbmtpbmciLCJzdGF0dXMiOiJBY3RpdmUifV0sInNvZnR3YXJlX2NsaWVudF9uYW1lIjoiUmFpZGlhbSBBY2NvdW50aW5nIiwib3JnX3N0YXR1cyI6IkFjdGl2ZSIsInNvZnR3YXJlX2NsaWVudF9pZCI6IkNraTFFYnZqd3loUEIxMk5HTGx6MiIsImlzcyI6Ik9wZW4gQmFua2luZyBPcGVuIEJhbmtpbmcgQnJhc2lsIHByb2QgU1NBIGlzc3VlciIsInNvZnR3YXJlX3Rvc191cmkiOiJodHRwczpcL1wvd3d3LnJhaWRpYW0uY29tXC9hY2NvdW50aW5nXC90b3MuaHRtbCIsInNvZnR3YXJlX2NsaWVudF9kZXNjcmlwdGlvbiI6IlJhaWRpYW0gQWNjb3VudGluZyBsZXZlcmFnZSBjdXR0aW5nIGVkZ2Ugb3BlbiBiYW5raW5nIGFjY2VzcyB0byBicmluZyB5b3UgcmVhbCB0aW1lIHVwIHRvIGRhdGUgdmlld3Mgb2YgeW91ciBmaW5hbmNlcyIsInNvZnR3YXJlX2p3a3NfZW5kcG9pbnQiOiJodHRwczpcL1wva2V5c3RvcmUuZGlyZWN0b3J5Lm9wZW5iYW5raW5nYnJhc2lsLm9yZy5iclwvYjk2MWM0ZWItNTA5ZC00ZWRmLWFmZWItMzU2NDJiMzgxODVkXC8yNTU1NmQ1YS1iOWRkLTRlMjctYWExYS1jY2U3MzJmZTc0ZGVcL2FwcGxpY2F0aW9uLmp3a3MiLCJzb2Z0d2FyZV9wb2xpY3lfdXJpIjoiaHR0cHM6XC9cL3d3dy5yYWlkaWFtLmNvbVwvYWNjb3VudGluZ1wvcG9saWN5Lmh0bWwiLCJzb2Z0d2FyZV9pZCI6IjI1NTU2ZDVhLWI5ZGQtNGUyNy1hYTFhLWNjZTczMmZlNzRkZSIsInNvZnR3YXJlX2NsaWVudF91cmkiOiJodHRwczpcL1wvd3d3LnJhaWRpYW0uY29tXC9hY2NvdW50aW5nLmh0bWwiLCJzb2Z0d2FyZV9qd2tzX2luYWN0aXZlX2VuZHBvaW50IjoiaHR0cHM6XC9cL2tleXN0b3JlLmRpcmVjdG9yeS5vcGVuYmFua2luZ2JyYXNpbC5vcmcuYnJcL2I5NjFjNGViLTUwOWQtNGVkZi1hZmViLTM1NjQyYjM4MTg1ZFwvMjU1NTZkNWEtYjlkZC00ZTI3LWFhMWEtY2NlNzMyZmU3NGRlXC9pbmFjdGl2ZVwvYXBwbGljYXRpb24uandrcyIsInNvZnR3YXJlX2p3a3NfdHJhbnNwb3J0X2luYWN0aXZlX2VuZHBvaW50IjoiaHR0cHM6XC9cL2tleXN0b3JlLmRpcmVjdG9yeS5vcGVuYmFua2luZ2JyYXNpbC5vcmcuYnJcL2I5NjFjNGViLTUwOWQtNGVkZi1hZmViLTM1NjQyYjM4MTg1ZFwvMjU1NTZkNWEtYjlkZC00ZTI3LWFhMWEtY2NlNzMyZmU3NGRlXC9pbmFjdGl2ZVwvdHJhbnNwb3J0Lmp3a3MiLCJzb2Z0d2FyZV9qd2tzX3RyYW5zcG9ydF9lbmRwb2ludCI6Imh0dHBzOlwvXC9rZXlzdG9yZS5kaXJlY3Rvcnkub3BlbmJhbmtpbmdicmFzaWwub3JnLmJyXC9iOTYxYzRlYi01MDlkLTRlZGYtYWZlYi0zNTY0MmIzODE4NWRcLzI1NTU2ZDVhLWI5ZGQtNGUyNy1hYTFhLWNjZTczMmZlNzRkZVwvdHJhbnNwb3J0Lmp3a3MiLCJzb2Z0d2FyZV9sb2dvX3VyaSI6Imh0dHBzOlwvXC93d3cucmFpZGlhbS5jb21cL2FjY291bnRpbmdcL2xvZ28ucG5nIiwib3JnX2lkIjoiYjk2MWM0ZWItNTA5ZC00ZWRmLWFmZWItMzU2NDJiMzgxODVkIiwic29mdHdhcmVfZW52aXJvbm1lbnQiOiJwcm9kdWN0aW9uIiwic29mdHdhcmVfdmVyc2lvbiI6MS4xMCwic29mdHdhcmVfcm9sZXMiOlsiREFET1MiLCJQQUdUTyJdLCJvcmdfbmFtZSI6Ik9wZW4gQmFua2luZyBCcmFzaWwiLCJpYXQiOjE2MTgzMzYyNjIsIm9yZ2FuaXNhdGlvbl9jb21wZXRlbnRfYXV0aG9yaXR5X2NsYWltcyI6W3siYXV0aG9yaXNhdGlvbl9kb21haW4iOiJPcGVuIEJhbmtpbmciLCJhdXRob3Jpc2F0aW9ucyI6W10sInJlZ2lzdHJhdGlvbl9pZCI6IjEzMzUzMjM2LU9CQi1DT05UQSIsImF1dGhvcml0eV9pZCI6IjY4N2ExYzk0LWIzNjAtNGUwNC05NTg5LTBmYTVjYjE2NDUxYiIsImF1dGhvcmlzYXRpb25fcm9sZSI6IkNPTlRBIiwiYXV0aG9yaXR5X2NvZGUiOiJCQ0IiLCJzdGF0dXMiOiJBY3RpdmUifSx7ImF1dGhvcmlzYXRpb25fZG9tYWluIjoiT3BlbiBCYW5raW5nIiwiYXV0aG9yaXNhdGlvbnMiOltdLCJyZWdpc3RyYXRpb25faWQiOiIxMzM1MzIzNi1PQkItREFET1MiLCJhdXRob3JpdHlfaWQiOiI2ODdhMWM5NC1iMzYwLTRlMDQtOTU4OS0wZmE1Y2IxNjQ1MWIiLCJhdXRob3Jpc2F0aW9uX3JvbGUiOiJEQURPUyIsImF1dGhvcml0eV9jb2RlIjoiQkNCIiwic3RhdHVzIjoiQWN0aXZlIn0seyJhdXRob3Jpc2F0aW9uX2RvbWFpbiI6Ik9wZW4gQmFua2luZyIsImF1dGhvcmlzYXRpb25zIjpbXSwicmVnaXN0cmF0aW9uX2lkIjoiMTMzNTMyMzYtT0JCLVBBR1RPIiwiYXV0aG9yaXR5X2lkIjoiNjg3YTFjOTQtYjM2MC00ZTA0LTk1ODktMGZhNWNiMTY0NTFiIiwiYXV0aG9yaXNhdGlvbl9yb2xlIjoiUEFHVE8iLCJhdXRob3JpdHlfY29kZSI6IkJDQiIsInN0YXR1cyI6IkFjdGl2ZSJ9XX0.W6hUAYhjT6I61rxEIVMKYKre93LTbRdzKnk9dJvUdzVgAz5B9KxZNutf27oO3k0hrjYVWBdWq23o_e4Y_AaKdpS9-rtU84JiHtmqV0wcFYIM8nqcUVWqQ-Ux6Nq9L2G-s2YNd3PcJ1e3yGg9h8553Gr7iJusKEgApzXUpkM2rBELQuumktUE_JBiuIkXmWxoRnO1cW-Osbk3MT3bxG43SPcxii07Q5S8qXI6PjCPA3fYlnaUAygwZM3O0oa7jqmSr7d9UsHuDMJfYhIKdq2wyQQKORCN-D2UopmMX-lHMvAVkkrAO08T0-7odjr4PJk-PrwuoCxeAfa7440ZDOrlmQ
+</pre><a href="#section-a.1-1" class="pilcrow">¶</a>
+</div>
+</section>
+</div>
+</section>
+</div>
+<div id="authors-addresses">
+<section id="section-appendix.b">
+      <h2 id="name-authors-addresses">
+<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
+      </h2>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">Ralph Bragg</span></div>
+<div dir="auto" class="left"><span class="org">Raidiam</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:ralph.bragg@raidiam.com" class="email">ralph.bragg@raidiam.com</a>
+</div>
+<div class="url">
+<span>URI:</span>
+<a href="https://www.raidiam.com/" class="url">https://www.raidiam.com/</a>
+</div>
+</address>
+<address class="vcard">
+        <div dir="auto" class="left"><span class="fn nameRole">OBBIS GT Security</span></div>
+<div dir="auto" class="left"><span class="org">Open Banking Brasil Initial Structure</span></div>
+<div class="email">
+<span>Email:</span>
+<a href="mailto:gt-seguranca@openbankingbr.org" class="email">gt-seguranca@openbankingbr.org</a>
+</div>
+<div class="url">
+<span>URI:</span>
+<a href="https://openbankingbrasil.org.br/" class="url">https://openbankingbrasil.org.br/</a>
+</div>
+</address>
+</section>
+</div>
+<script>const toc = document.getElementById("toc");
+toc.querySelector("h2").addEventListener("click", e => {
+  toc.classList.toggle("active");
+});
+toc.querySelector("nav").addEventListener("click", e => {
+  toc.classList.remove("active");
+});
+</script>
+</body>
+</html>

From 56bc3f00a9f213179c20de1b3d58a2e878ded68b Mon Sep 17 00:00:00 2001
From: ediemerson-br <60996132+ediemerson-br@users.noreply.github.com>
Date: Thu, 11 Nov 2021 18:20:42 -0300
Subject: [PATCH 29/59] Rename
 open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html to
 versions/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html

---
 ...pen-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html => versions/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html (100%)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html b/versions/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html
similarity index 100%
rename from open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html
rename to versions/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html

From 065fbce87d752469f686d23cd76a46a872348dad Mon Sep 17 00:00:00 2001
From: ediemerson-br <60996132+ediemerson-br@users.noreply.github.com>
Date: Thu, 11 Nov 2021 18:21:28 -0300
Subject: [PATCH 30/59] Rename
 open-banking-brasil-dynamic-client-registration-1_ID1.html to
 versions/open-banking-brasil-dynamic-client-registration-1_ID1.html

---
 .../open-banking-brasil-dynamic-client-registration-1_ID1.html    | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename open-banking-brasil-dynamic-client-registration-1_ID1.html => versions/open-banking-brasil-dynamic-client-registration-1_ID1.html (100%)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID1.html b/versions/open-banking-brasil-dynamic-client-registration-1_ID1.html
similarity index 100%
rename from open-banking-brasil-dynamic-client-registration-1_ID1.html
rename to versions/open-banking-brasil-dynamic-client-registration-1_ID1.html

From 41c34164333a3d92fced0771cc8c606380f6ce7e Mon Sep 17 00:00:00 2001
From: JOAO RODOLFO <joao.rodolfo+github@gmail.com>
Date: Thu, 11 Nov 2021 20:52:34 -0300
Subject: [PATCH 31/59] Update the table with consents #213

---
 open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
index 2daff27..3a4aa53 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
@@ -281,7 +281,7 @@ A tabela a seguir descreve as funções regulatórias do Open Banking e o mapeam
 | Papel Regulador | Descrição | Escopos Permitidos | Fase-alvo |
 | --- | --- | --- | --- |
 | DADOS | Instituição transmissora / receptora de dados (AISP) | openid accounts credit-cards-accounts consents customers invoice-financings financings loans unarranged-accounts-overdraft resources | Phase 2 |
-| PAGTO | Instituição prestadora de serviço de iniciação de pagamentos (PISP) | openid payments consents resources | Phase 3 |
+| PAGTO | Instituição prestadora de serviço de iniciação de pagamentos (PISP) | openid payments | Phase 3 |
 | CONTA | Instituição detentora de conta (ASPSP) | openid | Phase 3 |
 | CCORR | Correspondente de crédito | openid | Phase 3* |
 

From 086e3c05f21261974af3c0327f439dc58893ba0f Mon Sep 17 00:00:00 2001
From: JOAO RODOLFO <joao.rodolfo+github@gmail.com>
Date: Thu, 11 Nov 2021 20:58:42 -0300
Subject: [PATCH 32/59] Update the Consents Table

---
 open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html
index 550905a..01aced9 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html
@@ -1557,7 +1557,7 @@ <h3 id="name-fun231245es-regulat243rias-">
             <tr>
               <td class="text-left" rowspan="1" colspan="1">PAGTO</td>
               <td class="text-left" rowspan="1" colspan="1">Institui&#231;&#227;o prestadora de servi&#231;o de inicia&#231;&#227;o de pagamentos (PISP)</td>
-              <td class="text-left" rowspan="1" colspan="1">openid payments consents resources</td>
+              <td class="text-left" rowspan="1" colspan="1">openid payments </td>
               <td class="text-left" rowspan="1" colspan="1">Phase 3</td>
             </tr>
             <tr>

From f12e87e450a5ae9b8798c50ecb888ab5a614bfb7 Mon Sep 17 00:00:00 2001
From: JOAO RODOLFO <joao.rodolfo+github@gmail.com>
Date: Thu, 11 Nov 2021 21:13:50 -0300
Subject: [PATCH 33/59] Update table #213

Remove Consents and Resources from required scopes for PAGTO DCR Clients.
#213
---
 open-banking-brasil-dynamic-client-registration-1_ID2.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.html b/open-banking-brasil-dynamic-client-registration-1_ID2.html
index 64ee7b2..68cec05 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.html
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.html
@@ -1552,7 +1552,7 @@ <h3 id="name-regulatory-roles-to-openid-">
             <tr>
               <td class="text-left" rowspan="1" colspan="1">PAGTO</td>
               <td class="text-left" rowspan="1" colspan="1">Institui&#231;&#227;o prestadora de servi&#231;o de inicia&#231;&#227;o de pagamentos (PISP)</td>
-              <td class="text-left" rowspan="1" colspan="1">openid payments consents resources</td>
+              <td class="text-left" rowspan="1" colspan="1">openid payments </td>
               <td class="text-left" rowspan="1" colspan="1">Phase 3</td>
             </tr>
             <tr>

From 6a9b56e0c2197c0ea687504d828891d25e1d399c Mon Sep 17 00:00:00 2001
From: JOAO RODOLFO <joao.rodolfo+github@gmail.com>
Date: Thu, 11 Nov 2021 21:16:29 -0300
Subject: [PATCH 34/59]  Update table #213

 Remove Consents and Resources from required scopes for PAGTO DCR Clients. #213
---
 open-banking-brasil-dynamic-client-registration-1_ID2.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.md b/open-banking-brasil-dynamic-client-registration-1_ID2.md
index 99df93e..8995218 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.md
@@ -280,7 +280,7 @@ The following table describes the regulatory roles for Open Banking and the rela
 | Regulatory Role | Description | Allowed Scopes | Target Phase|
 | --- | --- | --- | --- |
 | DADOS | Instituição transmissora ou receptora de dados (AISP) | openid accounts credit-cards-accounts consents customers invoice-financings financings loans unarranged-accounts-overdraft resources | Phase 2 |
-| PAGTO | Instituição prestadora de serviço de iniciação de pagamentos (PISP) | openid payments consents resources | Phase 3 |
+| PAGTO | Instituição prestadora de serviço de iniciação de pagamentos (PISP) | openid payments | Phase 3 |
 | CONTA | Instituição detentora de conta (ASPSP) | openid | Phase 3 |
 | CCORR | Correspondente de crédito | openid | Phase 3* |
 

From 3f3d04f927ec94aabfa0368d4e2dbdb46e9efa02 Mon Sep 17 00:00:00 2001
From: JOAO RODOLFO <joao.rodolfo+github@gmail.com>
Date: Thu, 11 Nov 2021 21:19:21 -0300
Subject: [PATCH 35/59] Included the link  [OBB-DCR/DCM-Swagger] - DCR & DCM
 Swagger

IIncluded the link: [OBB-DCR/DCM-Swagger]: <https://raw.githubusercontent.com/OpenBanking-Brasil/specs-seguranca/main/dcr_review/dcr-dcm-swagger.yaml
---
 ...-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
index 3a4aa53..c34cbbf 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
@@ -151,6 +151,9 @@ Os seguintes documentos referenciados são indispensáveis para a aplicação de
 [OBB-Cert-Standards] - Open Banking Brasil x.509 Certificate Standards
 [OBB-Cert-Standards]: <https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html
 
+[OBB-DCR/DCM-Swagger] - DCR & DCM Swagger 
+[OBB-DCR/DCM-Swagger]: <https://raw.githubusercontent.com/OpenBanking-Brasil/specs-seguranca/main/dcr_review/dcr-dcm-swagger.yaml
+
 # Termos e definições  {#Definitions}
 
 Para efeitos deste documento, aplicam-se os termos definidos em [RFC6749], [RFC6750], [RFC7636], [OpenID Connect Core][OIDC] e ISO29100.
@@ -382,7 +385,7 @@ O exemplo a seguir contém todos os atributos atualmente incluídos em um _softw
 
 ## Enviar uma solicitação com uma declaração de software  {#exampleDcr}
 
-Este exemplo inclui vários campos opcionais, alguns dos quais podem não ser aplicáveis a algumas implantações. Para um guia completo dos atributos e sua obrigatoriedade, consultar o Swagger DCR --link aqui--.
+Este exemplo inclui vários campos opcionais, alguns dos quais podem não ser aplicáveis a algumas implantações. Para um guia completo dos atributos e sua obrigatoriedade, consultar o Swagger DCR [OBB-DCR/DCM-Swagger].
 A quebra de linha dentro dos valores são apenas para fins de exibição.
 
 ```

From b4e143a2f52f86eedc339138dcd1ddb369095307 Mon Sep 17 00:00:00 2001
From: ediemerson-br <60996132+ediemerson-br@users.noreply.github.com>
Date: Fri, 12 Nov 2021 09:42:28 -0300
Subject: [PATCH 36/59] =?UTF-8?q?Atualiza=C3=A7=C3=A3o=20item=207.2.2?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Alterações feitas conforme solicitação do GT Segurança
---
 open-banking-brasil-financial-api-1_ID3-ptbr.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.md b/open-banking-brasil-financial-api-1_ID3-ptbr.md
index 7a83bde..30436fa 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.md
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.md
@@ -411,7 +411,9 @@ Além dos requisitos descritos nas disposições de segurança do Open Banking B
 8. deve retornar falha na autenticação e o código de retorno _access_denied_ no parâmetro _erro_ (como especificado na seção 4.1.2.1 da [RFC6749]) caso o CPF do usuário autenticado não seja o mesmo indicado no elemento _loggedUser_ do Consentimento (Consent Resource Object);
 9. deve retornar falha na autenticação e o código de retorno _access_denied_ no parâmetro _erro_ (como especificado na seção 4.1.2.1 da [RFC6749]) caso o elemento _businessEntity_ não tenha sido preenchido no Consentimento (Consent Resource Object) relacionado e o usuário tenha selecionado ou se autenticado por meio de credencial relacionada à conta do tipo Pessoa Jurídica (PJ);
 10. deve condicionar a autenticação ou seleção de contas do tipo PJ à consistência entre o CNPJ relacionado à(s) conta(s) e o valor presente no elemento _businessEntity_ do Consentimento (Consent Resource Object). Em caso de divergência deve retornar falha na autenticação e o código de retorno _access_denied_ no parâmetro _erro_ (como especificado na seção 4.1.2.1 da [RFC6749]);
-11. deve emitir _refresh_token_ com validade não inferior à validade do consentimento ao qual está relacionado, respeitado os demais critérios acima.
+11. deve emitir _refresh_token_ com validade não inferior à validade do consentimento ao qual está relacionado, respeitado os demais critérios acima;
+12. a claim _iat_ deve ser numérica no formato Unix Time GMT+0 com tolerância de +/- 60 segundos;
+13. A claim do _jti_ deve ser única para um _clientId_ dentro de um intervalo de tempo de 86.400 segundos (24h), não podendo ser reutilizada neste período. Em caso de reutilização, deverá ser retornado o código de erro HTTP 403.
 
 ### Cliente confidencial  {#clientconfidential}
 

From 0440d9b87b930c2e19bdc90271156790b8ef6370 Mon Sep 17 00:00:00 2001
From: ediemerson-br <60996132+ediemerson-br@users.noreply.github.com>
Date: Fri, 12 Nov 2021 09:48:07 -0300
Subject: [PATCH 37/59] =?UTF-8?q?Atualiza=C3=A7=C3=A3o=20item=207.2.2?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Alterações feitas conforme solicitação do GT Segurança
---
 open-banking-brasil-financial-api-1_ID3.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/open-banking-brasil-financial-api-1_ID3.md b/open-banking-brasil-financial-api-1_ID3.md
index ff7bff6..019784a 100644
--- a/open-banking-brasil-financial-api-1_ID3.md
+++ b/open-banking-brasil-financial-api-1_ID3.md
@@ -424,7 +424,9 @@ In addition to the requirements outlined in Open Banking Brasil security provisi
 8. shall return authentication failure and return code _access_denied_ in the _error_ parameter (as specified in section 4.1.2.1 of [RFC6749]) if the CPF of the authenticated user is not the same as indicated in the _loggedUser_ element of the Consent Resource Object;
 9. shall return authentication failure and return code _access_denied_ in the _error_ parameter (as specified in section 4.1.2.1 of [RFC6749]) if the _businessEntity_ element has not been populated in the related Consent Resource Object and the user has selected or authenticated by using a credential related to a business account;
 10. an autenticated or selected business account´s CNPJ must match the value present in the _businessEntity_ element of the Consent Resource Object. In case of divergence authorization server shall return authentication failure and return code _access_denied_ in the _error_ parameter (as specified in section 4.1.2.1 of [RFC6749]);
-11. shall ensure _refresh_tokens_ expiration time is at least equal to the linked consent resource expiration time.
+11. shall ensure _refresh_tokens_ expiration time is at least equal to the linked consent resource expiration time;
+12. the _iat_ claim must be numeric in Unix Time format GMT+0 with a tolerance of +/- 60 seconds;
+13. The _jti_ claim must be unique for a _clientId_ within a time frame of 86,400 seconds (24h), and cannot be reused within this period. In case of reuse, the HTTP error code 403 shall be returned.
 
 ### Confidential Client
 

From 06f10c2772ed3ac6f1a029c9ebdbf2717cb8c1ca Mon Sep 17 00:00:00 2001
From: Alexandre Daniel Dalabrida <alexandre.dalabrida@ailos.coop.br>
Date: Fri, 12 Nov 2021 14:40:49 -0300
Subject: [PATCH 38/59] =?UTF-8?q?Inclus=C3=A3o=20da=20documenta=C3=A7?=
 =?UTF-8?q?=C3=A3o=20da=20proibi=C3=A7=C3=A3o=20da=20rota=C3=A7=C3=A3o=20d?=
 =?UTF-8?q?o=20refresh=20token=20em=20ingles?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...banking-brasil-financial-api-1_ID3-ptbr.md | 416 +++++++++---------
 1 file changed, 214 insertions(+), 202 deletions(-)

diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.md b/open-banking-brasil-financial-api-1_ID3-ptbr.md
index c03a885..fc27f9f 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.md
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.md
@@ -1,4 +1,3 @@
-
 %%%
 
     #
@@ -16,7 +15,7 @@
     [seriesInfo]
     name = "Internet-Draft"
     status = "standard"
-    value = "open-banking-brasil-financial-api-1_ID3-ptbr"
+    value = "open-banking-brasil-financial-api-1_ID3"
 
     [[author]]
     initials = "R."
@@ -39,51 +38,50 @@
       uri = "https://openbankingbrasil.org.br/"
 %%%
 
-.# Prefácio  {#Foreword}
+.# Foreword
 
-The normative version in [English](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html)
+Este documento também está disponível em [português](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3-ptbr.html)
 
-A Estrutura Inicial do Open Banking Brasil (EIOBB) é responsável por criar padrões e especificações necessárias para atender aos requisitos e obrigações da Legislação do Open Banking do Brasil, conforme originalmente delineado pelo [Banco Central do Brasil](https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf). É possível que alguns dos elementos deste documento estejam sujeitos a direitos autorais ou patenteados. O EIOBB não se responsabiliza pela identificação de qualquer ou todos esses direitos.
+The Open Banking Brasil Initial Structure is responsible for creating standards and specifications necessary to meet the requirements and obligations of the Brasil Open Banking Legislation as originally outlined by the [Brasil Central Bank](https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf). There is a possibility that some of the elements of this document may be the subject to patent rights. OBBIS shall not be held responsible for identifying any or all such patent rights.
 
-O Financial-grade API 1.0 do Open Banking Brasil consiste nas seguintes partes:
+Open Banking Brasil Financial-grade API Security Profile 1.0 consists of the following parts:
 
 * Open Banking Brasil Financial-grade API Security Profile 1.0
 * [Open Banking Brasil Dynamic Client Registration Profile 1.0][OBB-FAPI-DCR]
 
-Estas partes são destinados a serem usados com [RFC6749], [RFC6750], [RFC7636], [OIDC], [FAPI-1-Baseline] e [FAPI-1-Advanced]
-
-.# Introdução  {#Introduction}
+These parts are intended to be used with [RFC6749], [RFC6750], [RFC7636], [OIDC], [FAPI-1-Baseline] and [FAPI-1-Advanced]
 
-A Financial-grade API do Open Banking Brasil é um perfil OAuth altamente seguro que visa fornecer diretrizes de implementação específicas para segurança e interoperabilidade que podem ser aplicadas a APIs na área de Open Banking do Brasil que requerem um nível de privacidade superior ao fornecido pelo padrão [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced]. Entre outras melhorias, esta especificação aborda considerações de privacidade identificadas em [FAPI-1-Advanced] que são relevantes nas especificações do Open Banking Brasil, mas não foram, até agora, exigidas por outras jurisdições.
+.# Introduction
 
-Embora seja possível codificar um provedor de OpenID e parte de confiança a partir dos primeiros princípios usando esta especificação, o público principal para esta especificação são as partes que já possuem uma implementação certificada do [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] e deseja obter a certificação para o programa Brasil Open Banking.
+The Open Banking Brasil Financial-grade API is a highly secured OAuth profile that aims to provide specific implementation guidelines for security and interoperability which can be applied to APIs in the Brasil Open Banking area that require a higher level of privacy than provided by standard [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced]. Among other enhancements, this specification addresses privacy considerations identified in [FAPI-1-Advanced] that are relevent in the Open Banking Brasil specifications but have not, so far, been required by other jurisdictions.
 
-.# Convenções Notacionais  {#Notational}
+Although it is possible to code an OpenID Provider and Relying Party from first principles using this specification, the main audience for this specification is parties who already have a certified implementation of [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] and want to achieve certification for the Brasil Open Banking programme.
 
-As palavras-chave "*deve*" (shall), "*não deve*" (shall not), "*deveria*" (should), "*não deveria*" (should not) e "*pode*" (may) presentes nesse documento devem ser interpretadas conforme as diretrizes descritas em [ISO Directive Part 2][ISODIR2] observando  seguinte equivalência:
+.# Notational Conventions
 
-* "deve" => equivalente ao termo "shall" e expressa um requerimento definido no documento (nas traduções é similar ao termo "must", que pode denotar um requerimento externo ao documento);
-* "não deve" => equivalente ao termo "shall not" e também expressa um requerimento definido no documento;
-* "deveria" e "não deveria"=> equivalente ao termo "should" e "should not" e expressa uma recomendação
-* "pode" => equivalente ao termo "may" indica uma permissão
-
-Estas palavras-chave não são usadas como termos de dicionário, de modo que qualquer ocorrência deles deve ser interpretada como palavras-chave e não devem ser interpretados com seus significados de linguagem natural.
+The key words "shall", "shall not",
+"should", "should not", "may", and
+"can" in this document are to be interpreted as described in
+[ISO Directive Part 2][ISODIR2].
+These key words are not used as dictionary terms such that
+any occurrence of them shall be interpreted as key words
+and are not to be interpreted with their natural language meanings.
 
 {mainmatter}
 
-# Escopo  {#Scope}
+# Scope
 
-Este documento especifica o método para os aplicativos
+This document specifies the method of
 
-* obterem de maneira segura os tokens OAuth necessários para acesso a dados críticos de acordo com os requisitos do [Open Banking Brasil](https://www.in.gov.br/en/web/dou/-/resolucao-conjunta-n-1-de-4-de-maio-de-2020-255165055);
-* utilizarem o OpenID Connect para identificação do usuário do Open Banking; e
-* utilizarem o OpenID Connect para afirmar a identidade do cliente.
+* applications to obtain the OAuth tokens in an appropriately secure manner for higher risk access to data in a manner that meets the requirements of [Open Banking Brasil](https://www.in.gov.br/en/web/dou/-/resolucao-conjunta-n-1-de-4-de-maio-de-2020-255165055);
+* applications to use OpenID Connect to identify the customer; and
+* applications to use OpenID Connect to assert identity of the customer;
 
-Este documento é aplicável a todos os participantes do Open Banking no Brasil.
+This document is applicable to all participants engaging in Open Banking in Brasil.
 
-# Referências normativas  {#Normative}
+# Normative references
 
-Os seguintes documentos referenciados são indispensáveis para a adoção das especificações deste documento. Para referências datadas, apenas a edição citada se aplica. Para referências não datadas, deve-se aplicar a última edição do documento referenciado (incluindo quaisquer emendas).
+The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applied. For undated references, the latest edition of the referenced document (including any amendments) applies.
 
 [ISODIR2] - ISO/IEC Directives Part 2
 [ISODIR2]: <https://www.iso.org/sites/directives/current/part2/index.xhtml
@@ -148,6 +146,9 @@ Os seguintes documentos referenciados são indispensáveis para a adoção das e
 [FAPI-2-Baseline] - Financial-grade API Security Profile 2.0 - Part 1: Baseline
 [FAPI-2-Baseline]: <https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md
 
+[FAPI-2-Advanced] - Financial-grade API Security Profile 2.0 - Part 2: Advanced
+[FAPI-2-Advanced]: <https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Advanced_Profile.md
+
 [LIWP] - OIDF FAPI WG Lodging Intent Working Paper
 [LIWP]: <https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md
 
@@ -157,277 +158,288 @@ Os seguintes documentos referenciados são indispensáveis para a adoção das e
 [RFC4648] - The Base16, Base32, and Base64 Data Encodings
 [RFC4648]: <https://tools.ietf.org/html/rfc4648
 
-# Termos e definições  {#definitions}
+# Terms and definitions
 
-Para efeitos deste documento, os termos definidos em [RFC6749], [RFC6750], [RFC7636], [OpenID Connect Core][OIDC] e ISO29100 se aplicam.
+For the purpose of this document, the terms defined in [RFC6749], [RFC6750], [RFC7636], [OpenID Connect Core][OIDC] and ISO29100 apply.
 
-# Símbolos e termos abreviados  {#terms}
+# Symbols and Abbreviated terms
 
-**API** - Application Programming Interface (Interface de programação de aplicativo)
+**API** – Application Programming Interface
 
-**EIOBB** - Estrutura Inicial do Open Banking Brasil
+**OBBIS** – Open Banking Brasil Initial Structure
 
 **CSRF** - Cross Site Request Forgery
 
-**DCR** - Registro de cliente dinâmico
+**DCR** – Dynamic Client Registration
 
 **FAPI** - Financial-grade API
 
-**HTTP** - Protocolo de transferência de hipertexto
+**HTTP** – Hyper Text Transfer Protocol
 
 **OIDF** - OpenID Foundation
 
-**REST** - Representational State Transfer (Transferência de Estado Representacional)
-
-**TLS** - Transport Layer Security (Segurança da Camada de Transporte)
-
-**MFA** - Multi-Factor Authentication (Autenticação por Múltiplos Fatores)
-
-# Profile de Segurança para o Open Banking Brasil {#securityprofile}
+**REST** – Representational State Transfer
 
-## Introdução  {#secintroduction}
+**TLS** – Transport Layer Security
 
-O perfil de segurança do Open Banking Brasil especifica requisitos adicionais de segurança e de  identificação para o acesso a API´s com recursos críticos protegidas pelo OAuth 2.0 Authorization Framework, que consiste em [RFC6749], [RFC6750], [RFC7636], [FAPI-1-Baseline], [FAPI-1-Advanced] e outras especificações.
+**MFA** - Multi-Factor Authentication
 
-Este perfil descreve as capacidades e os recursos de segurança que devem ser oferecidos por servidores e clientes que são necessários para o Programa do Open Banking Brasil, definindo as medidas para mitigar ou endereçar:
+# Brasil Open Banking Security Profile
 
-* ataques que abordam considerações de privacidade identificadas na cláusula 9.1 de [FAPI-1 Advanced].
-* o requisito de concessão de acesso granular a recursos, com vistas à minimização de dados;
-* o requisito de informar sobre o contexto da autenticação do usuário (claim Authentication Context Request - acr) que foi realizada por um Provedor OpenID, com vistas a favorecer o adequado gerenciamento do risco decorrente do acesso do usuário;
-* o requisito para que os clientes de API declarem um relacionamento prévio com o usuário, afirmando em uma `claim` de identificação do usuário como parte do fluxo de autorização.
+## Introduction
 
-## Disposições de segurança do Open Banking Brasil  {#authserver}
+The Brasil Open Banking Security profile specifies additional security and identity requirements for high risk API resources protected by the OAuth 2.0 Authorization Framework that consists of [RFC6749], [RFC6750], [RFC7636], [FAPI-1-Baseline], [FAPI-1-Advanced] and other specifications.
 
-### Introdução  {#authintrod}
+This profile describes security and features provisions for a server and client that are necessary for the Brasil Open Banking Programme by defining the measures to mitigate or address:
 
-O Open Banking Brasil tem um requisito para endereçar considerações de privacidade que foram identificadas, mas não abordadas na especificação final [FAPI-1-Advanced], sem impor requisitos adicionais aos Servidores de Autorização que estão sendo propostos em [FAPI-2-Baseline].
+* attacks that address privacy considerations identified in clause 9.1 of [FAPI1 Advanced]
+* the requirement to support fine-grained access to resources for data minimisation purposes
+* the requirement to convey the Authentication Context Request that was performed by an OpenID Provider to a Client to enable a appropriate client management of customer conduct risk.
+* the requirement for clients to assert a pre-existing customer relationship by asserting a customer identity claim as part of the authorization flow.
 
-Os participantes desse ecossistema precisam que os clientes de API solicitem a um provedor openid a confirmação dos valores das `claims` de identificação do usuário como parte de uma solicitação de autorização usando o mecanismo definido na cláusula 5.5.1 de [OIDC].
+## Open Banking Brasil security provisions
 
-O uso do parâmetro `claims` para solicitar a validação de valores de identificação explícitos requer que os clientes de API protejam com criptografia o Request Object para evitar vazamento de informações. Este risco é identificado na cláusula 7.4.1 do [FAPI-1-Baseline].
+### Introduction
 
-Além disso, este perfil descreve o escopo específico, valores de `acr` e requisitos de gerenciamento de clientes necessários para dar suporte ao ecossistema Open Banking Brasil mais amplo.
+Open Banking Brasil has a requirement to address privacy considerations that were identified but not addressed in the [FAPI-1-Advanced] final specification without imposing additional requirements on Authorisation Servers being proposed in [FAPI-2-Baseline].
+Participants in this ecosystem have a need for clients to request an openid provider to confirm values of identity claims as part of an authorization request using the mechanism defined in clause 5.5.1 of [OIDC].
+The use of the claims parameter to request explicit claims values requires clients to ensure that they encrypt the request object to avoid information leakage. This risk is identified in clause 7.4.1 of [FAPI-1-Baseline].
+In addition this profile describes the specific scope, acr and client management requirements necessary to support the wider Open Banking Brasil ecosystem.
 
-Como um perfil do OAuth 2.0 Authorization Framework, este documento exige o seguinte para o perfil de segurança do Open Banking Brasil.
+As a profile of the OAuth 2.0 Authorization Framework, this document mandates the following for the Brasil Open Banking Security profile.
 
-### Servidor de Autorização  {#authprovisions}
+### Authorization server
 
-O Servidor de Autorização **deve** suportar as disposições especificadas na cláusula 5.2.2 de [Financial-grade API Security Profile 1.0 - Parte 2: Advanced] [FAPI-1-Advanced].
+The Authorization Server shall support the provisions specified in clause 5.2.2 of [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced]
 
-Além disso, ele deve:
+In addition, the Authorization Server
 
-1. deve suportar Request Objects JWE assinados e criptografados passados por valor ou deve exigir requisições do tipo "pushed authorization requests" [PAR]
-2. deve publicar metadados de descoberta (incluindo a do endpoint de autorização) por meio do documento de metadado especificado em [OIDD] e [RFC8414] (".well-known")
-3. deve suportar os parâmetros `claims` como definido no item 5.5 do [OpenID Connect Core][OIDC]
-4. deve suportar o atributo `claim` padrão oidc "cpf" conforme definido no item 5.2.2.2 deste documento
-5. deve suportar o atributo `claim` padrão oidc "cnpj" conforme definido no item 5.2.2.3 deste documento, se a instituição for detentora de conta para pessoas jurídicas
-6. deve suportar o atributo `acr` "urn:brasil:openbanking:loa2" como definido no item 5.2.2.4 deste documento
-7. deveria suportar o atributo `acr` "urn:brasil:openbanking:loa3" como definido no item 5.2.2.4 deste documento
-8. deve implementar o endpoint "userinfo" como definido no item 5.3 do [OpenID Connect Core][OIDC]
-9. deve suportar o escopo parametrizável ("parameterized OAuth 2.0 resource scope") _consent_ como definido no item 6.3.1 de [OIDF FAPI WG Lodging Intent Pattern][LIWP]
-10. pode suportar [Financial-grade API: Client Initiated Backchannel Authentication Profile][FAPI-CIBA]
-11. (requisito temporariamente retirado)
-12. deve suportar `refresh tokens`
-13. não deve permitir o recurso de rotação de `refresh tokens`
-14. deve emitir `access tokens` com o tempo de expiração entre 300 (mínimo) e 900 (máximo) segundos
-15. deve sempre incluir a claim `acr` no id_token
-16. deve suportar os valores `code` e `id_token` para o atributo `response_type`
-17. pode suportar o valor `code` para o atributo `response_type`em conjunto com o valor `jwt` para o atributo `response_mode`
+1. shall support a signed and encrypted JWE request object passed by value or shall require pushed authorization requests [PAR];
+2. shall distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in [OIDD] and [RFC8414]
+3. shall support the claims parameter as defined in clause 5.5 [OpenID Connect Core][OIDC]
+4. shall support the oidc standard claim "cpf" as defined in clause 5.2.2.2 of this document
+5. shall support the oidc standard claim "cnpj" as defined in clause 5.2.2.3 of this document if providing access to resources where the resource owner is not a `natural person`
+6. shall support the acr "urn:brasil:openbanking:loa2" as defined in clause 5.2.2.4 of this document
+7. should support the acr "urn:brasil:openbanking:loa3" as defined in clause 5.2.2.4 of this document
+8. shall implement the userinfo endpoint as defined in clause 5.3 [OpenID Connect Core][OIDC]
+9. shall support parameterized OAuth 2.0 resource scope _consent_ as defined in clause 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP]
+10. may support [Financial-grade API: Client Initiated Backchannel Authentication Profile][FAPI-CIBA]
+11. (withdrawn)
+12. shall support refresh tokens
+13. shall not allow `refresh tokens` rotation feature
+14. shall issue access tokens with an expiry no greater than 900 seconds and no less than 300 seconds
+15. shall always include an acr claim in the `id_token`
+16. shall support the `response_type` value `code id_token`
+17. may support `response_type` value `code` in conjunction with the `response_mode` value `jwt`
 
-#### Token de ID como assinatura separada  {#detached}
 
-O Servidor de Autorização *deve* suportar as disposições especificadas na cláusula 5.2.2.1 de [Financial-grade API Security Profile 1.0 - Parte 2: Advanced] [FAPI-1-Advanced]
+#### ID Token as detached signature
 
-Além disso, se o valor `response_type` `code id_token` for usado, o servidor de autorização:
+The Authorization Server shall support the provisions specified in clause 5.2.2.1 of [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced]
 
-1. **não deveria** retornar Informação de Identificação Pessoal (PII) confidenciais no token de ID na resposta de autorização, mas se for necessário, então ele **deve** criptografar o token de ID.
+In addition, if the `response_type` value `code id_token` is used, the Authorization Server
 
-#### Solicitando uma "claim" **cpf**  {#cpf}
+1. should not return sensitive PII in the ID Token in the authorization response, but if it needs to,
+then it shall encrypt the ID Token.
 
-Este perfil define "cpf" como uma nova `claim` padrão de acordo com cláusula 5.1 [OIDC]
+#### Requesting the "cpf" Claim
 
-O número do **CPF** (Cadastro de Pessoas Físicas, [sepeˈɛfi]; português para "Registro de Pessoas Físicas") é o cadastro de pessoa física **brasileira**. Este número é atribuído pela Receita Federal **Brasileira** para brasileiros e estrangeiros residentes que, direta ou indiretamente, pagar impostos no **Brasil**.
+This profile defines "cpf" as a new standard claim as per
+ clause 5.1 [OIDC]
 
-No modelo de identidade do Open Banking Brasil, o cpf é uma string composta por números 11 caracteres de comprimento e podem começar com 0.
+The **CPF** number (Cadastro de Pessoas Físicas, [sepeˈɛfi]; Portuguese for "Natural Persons Register")
+ is the **Brazilian** individual taxpayer registry identification. This number is attributed by
+ the **Brazilian** Federal Revenue to Brazilians and resident aliens who, directly or indirectly,
+  pay taxes in **Brazil**.
+In the Brasil Open Banking identity model, the cpf is a string consisting of numbers that is 11
+characters long and may start with a 0.
+If the cpf Claim is requested as an Essential Claim for the ID Token or UserInfo response with a
+values parameter requesting a specific cpf value, the Authorization Server MUST return a cpf Claim Value
+that matches the requested value. If this is an Essential Claim and the requirement cannot be met,
+ then the Authorization Server MUST treat that outcome as a failed authentication attempt.
 
-Se a Claim **cpf** for solicitada como essencial para constar no ID token ou na resposta ao endpoint de UserInfo e na solicitação constar no parâmetro `value` com determinado **CPF** exigido, o Authorization Server **DEVE** retornar no atributo **cpf** o valor que corresponda ao da solicitação.
+Name: cpf, Type: String, Regex: '^\d{11}$'
 
-Se a Claim **cpf** for solicitada como essencial para constar no ID Token ou na resposta no endpoint de UserInfo, o Authorization Server deve retornar no atributo **cpf** o valor com o **CPF** do usuário autenticado.
+#### Requesting the "cnpj" Claim
 
-Se a Claim **cpf** indicada como essencial não puder ser preenchida ou não for compatível com o requisito, o Authorization Server deve tratar a solicitação como uma tentativa de autenticação com falha.
+This profile defines "cnpj" as a new standard claim as per
+ clause 5.1[OIDC]
 
-Nome: cpf, Tipo: String, Regex: '^\d{11}$'
+**CNPJ**, short for Cadastro Nacional de Pessoas Jurídicas, is an identification number
+ of **Brazilian** companies issued by the **Brazilian** Ministry of Revenue, **in**
+ Portuguese "Secretaria da Receita Federal" or "Ministério da Fazenda". In the Brasil Open Banking identity model,
+ individuals can associated with 0 or more CNPJs. A CNPJ is a string consisting of numbers that is 14 digits long and may start with a 0,
+ the first eight digits identify the company, the four digits after the slash identify the branch or
+  subsidiary ("0001" defaults to the headquarters), and the last two are checksum digits.
+   For this profile, the cnpj claim must be requested and supplied as the 14 digit number.
 
-#### Solicitando a "claim" **cnpj**  {#cnpj}
+If the cnpj Claim is requested as an Essential Claim for the ID Token or UserInfo response with a
+values parameter requesting a specific cnpj value, the Authorization Server MUST return a cnpj
+Claim Value that contains a **set** of CNPJs one of which must match the requested value. If this
+ is an Essential Claim and the requirement cannot be met, then the Authorization Server MUST treat
+ that outcome as a failed authentication attempt.
 
-Este perfil define "cnpj" como uma nova reivindicação padrão de acordo com cláusula 5.1 [OIDC]
+Name: cnpj, Type: Array of Strings, Array Element Regex: '^\d{14}$'
 
-**CNPJ**, abreviação de Cadastro Nacional de Pessoas Jurídicas, é um número de identificação de empresas **brasileiras** emitidas pelo Ministério da Fazenda **brasileira**, **na** "Secretaria da Receita Federal" ou "Ministério da Fazenda" do Brasil. No modelo de identidade do Open Banking Brasil, pessoas físicas podem se associar a 0 ou mais CNPJs. Um CNPJ é uma string que consiste em números de 14 dígitos e pode começar com 0, os primeiros oito dígitos identificam a empresa, os quatro dígitos após a barra identificam a filial ou subsidiária ("0001" padrão para a sede), e os dois últimos são dígitos de soma de verificação. Para este perfil, o pedido de cnpj deve ser solicitado e fornecido como o número de 14 dígitos.
+#### Requesting the "urn:brasil:openbanking:loa2" or "urn:brasil:openbanking:loa3" Authentication Context Request
 
-Se a Claim **cnpj** for solicitada como essencial para constar no ID Token ou na resposta ao endpoint UserInfo e na solicitação constar, no parâmetro `value`, determinado **CNPJ** exigido, o Authorization Server **DEVE** retornar no atributo **cnpj** um **conjunto** de **CNPJs** relacionado com o usuário, um dos quais deve incluir valor que corresponda ao da solicitação.
+This profile defines "urn:brasil:openbanking:loa2" and "urn:brasil:openbanking:loa3" as
+ new Authentication Context Request classes.
 
-Se a Claim **cnpj** for solicitada como essencial para constar no ID Token ou na resposta ao endpoint UserInfo, o Authorization Server deve incluir no ID Token ou na resposta ao endpoint UserInfo um **conjunto** que inclua um elemento com o número do **CNPJ** relacionado à conta utilizada na autenticação do usuário.
+* **LoA2:** Authentication performed using single factor;
+* **LoA3:** Authentication performed using multi factor (MFA)
 
-Se a Claim **cnpj** indicada como essencial não puder ser preenchida ou validada, o Authorization Server deve tratar a solicitação como uma tentativa de autenticação com falha.
+The following rules are applicable to **access control to Open Banking Brazil API´s:**
 
-Nome: cnpj, Tipo: Array of Strings, Array Element Regex: '^\d{14}$'
+* In accordance to Art. 17 of [Joint Resolution nº 01 - Open Banking Brasil](https://www.in.gov.br/en/web/dou/-/resolucao-conjunta-n-1-de-4-de-maio-de-2020-255165055), institutions must adopt procedures and controls for client authentication **compatible with those applicable in their electronic service channels**.
+* So, in compliance with the regulation, it is suggested that:
+   * **For Read-Only APIs  (Phase 2)**: the _Authorization Servers_ **should** adopt, at least, an authentication method compatible with `LoA2`; and
+   * **For Read-Write API´s (subsequent phases)**: the _Authorization Servers_ **should** adopt an authentication method compatible with `LoA3` or higher.
 
-#### Solicitando o "urn:brasil:openbanking:loa2" ou "urn:brasil:openbanking:loa3" Solicitação de contexto de autenticação  {#loa}
+In all cases, the adoption of a more rigorous authentication mechanism (`LoA3` or higher) is at the discretion of the Bank (ASPSP), according to its risk assessment and in a manner compatible with the mechanisms usually used.
 
-* **LoA2**: mecanismo de autenticação com a adoção de um único fator
-* **LoA3**: mecanismo de autenticação com múltiplos fatores de autenticação
+**Authentication factors clarification**
 
-A seguinte orientação deve ser observada para o mecanismo de autenticação:
-* De acordo com o Art. 17 da Resolução Conjunta nº 01, as instituições devem adotar  procedimentos e controles para autenticação de cliente **compatíveis com os aplicáveis ao acesso a seus canais de atendimento eletrônicos**.
-* Em observância à regulação em vigor, sugere-se que:
-  * **Para a autenticação do usuário em autorizações de acessos às APIs de compartilhamento de dados (Fase 2)**, os _Authorization Servers_ **deveriam** adotar, no mínimo, método compatível com `LoA2`; e
-  * **Para a autenticação do usuário em autorizações de acessos às API´s das fases subsequentes**, os _Authorization Servers_ **deveriam** adotar método de autenticação compatível com `LoA3` ou superior.
+The authentication methods are:
 
-Em todos os casos, a adoção de mecanismo de autenticação mais rigoroso (`LoA3` ou superior) fica a critério da instituição transmissora ou detentora de conta, de acordo com sua avaliação de riscos e de forma compatível com os mecanismos habitualmente utilizados.
+* Something you know, such as password or phrase
+* Something you have, such as token or smartcard;
+* Something you are, such as biometric validation.
 
-**Esclarecimentos adicionais sobre fatores de autenticação**
+To performe a MFA authentication is necessary the end user to present at least two different methods as listed above. A unique method used more than once is not accepted as MFA.
 
-São fatores de autenticação:
+### Confidential client
 
-* Aquilo que **você conhece**, como uma senha ou frase secreta
-* Aquilo que **você tem**, como um token, smartcard ou dispositivo
-* Aquilo que **"você é"**, ou seja, autenticação condicionada a apresentação de uma característica física exclusivamente sua, como a validação por biometria
-
-Para realizar autenticação por múltiplos fatores (MFA) é necessário que o usuário apresente, ao menos, dois diferentes  fatores dos listados acima. Um mesmo fator usado mais de uma vez - por exemplo, a apresentação de suas senhas que ele conhece - não pode ser aceito como MFA.
-
-### Cliente confidencial  {#client}
-
-Um cliente confidencial deve apoiar as disposições especificadas na cláusula 5.2.3 de
+A confidential client shall support the provisions specified in clause 5.2.3 of
 [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced],
 
-Além disso, o cliente confidencial
+In addition, the confidential client
 
-1. deve suportar objetos de solicitação _encrypted_
-2. deve suportar solicitações de autorização push (pushed authorization requests) [PAR]
-3. deve usar objetos de solicitação _encrypted_ se não usar [PAR]
-4. deve suportar o escopo de recurso OAuth 2.0 parametrizado _consent_ conforme definido na cláusula 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP]
-5. deve suportar `refresh tokens`
-6. não deve permitir o recurso de rotação de `refresh tokens`
-7. não deve incluir um valor específico na _claim_ `acr`
-8. deve definir a _claim_ `acr`como _essential_
-9. deve suportar todos os métodos de autenticação especificados no item 14 da seção 5.2.2 da [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] incluindo as diferentes combinações de métodos de encaminhamento dos Requests Objects (usando ou não [PAR] - item 11).
+1. shall support _encrypted_ request objects
+2. shall support Pushed Authorisation Requests [PAR]
+3. shall use _encrypted_ request objects if not using [PAR]
+4. shall support parameterized OAuth 2.0 resource scope _consent_ as defined in clause 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP]
+5. shall support refresh tokens
+6. shall not allow `refresh tokens` rotation feature
+7. shall not populate the `acr` claim with required values
+8. shall require the `acr` claim as an essential claim
+9. shall support all authentication methods specified in clause 5.2.2-14 of [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] including diferent combinations of the methods to send requests (using [PAR] or not - item 11).
 
-# Considerações de segurança  {#authserver}
+# Security considerations
 
-Os participantes devem apoiar todas as considerações de segurança especificadas na cláusula 8 [Financial-grade API Security Profile 1.0 - Parte 2: Advanced] [FAPI-1-Advanced] e o [Manual de Segurança de Banco Central do Brasil] (https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Instru%C3%A7%C3%A3o%20Normativa%20BCB&numero=134). O ICP brasileiro emite certificados RSA x509 somente, portanto, para simplificar, a seção remove o suporte para algoritmos EC e exige que apenas algoritmos de criptografia recomendados pela IANA sejam usados.
+Participants shall support all security considerations specified in clause 8
+ [Financial-grade API Security Profile 1.0 - Part 1: Advanced][FAPI-1-Advanced] and the [Brazilian Central Bank Open Banking Security Manual](https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Instru%C3%A7%C3%A3o%20Normativa%20BCB&numero=134).
+ The Brazilian ICP issues RSA x509 certificates only therefor section removes for simplicity support for EC algorithms
+ and requires that only IANA recommended encryption algorithms be used.
 
-## Considerações sobre assinatura do conteúdo de mensagens (JWS) {#jws}
+## Message Content Signing Considerations (JWS) {#jws}
 
-1. Para garantir a integridade e o não-repúdio das informações tramitadas em **API´s sensíveis e que indicam essa necessidade na sua documentação**, deve ser adotado a estrutura no padrão JWS definida na [RFC7515] e que inclui:
-   * Cabeçalho (_JSON Object Signing and Encryption – JOSE Header_), onde se define o algoritmo utilizado e inclui informações sobre a chave pública ou certificado que podem ser utilizadas para validar a assinatura;
-   * Payload (_JWS Payload_): conteúdo propriamente dito e detalhado na especificação da API;
-   * Assinatura digital (_JWS Signature_): assinatura digital, realizada conforme parâmetros do cabeçalho.
-2. Cada elemento acima deve ser codificado utilizando o padrão Base64url [RFC4648](https://tools.ietf.org/html/rfc4648#section-5) e, feito isso, os elementos devem ser concatenados com “.” (método JWS Compact Serialization, conforme definido na [RFC7515]).
+1. JWS standad defined in [RFC7515] shall be adopted to ensure integrity and non-repudiation of information processed in sensitive **API's (message sign requirement is indicated at API´s documentation/swagger)**, which includes:
+  * Header (_JSON Object Signing and Encryption – JOSE Header_), which defines the algorithm used and includes information about the public key or certificate that can be used to validate the signature;
+  * Payload (_JWS Payload_): content itself as detailed in the API specification;
+  * Digital signature (_JWS Signature_): digital signature, performed according to header parameters.
+2. Each of elements above must be encoded using the Base64url pattern [RFC4648](https://tools.ietf.org/html/rfc4648#section-5) and the elements must be concatenated with “.” (JWS Compact Serialization method as defined in [RFC7515]).
 
-3. O payload das mensagens (requisição _JWT_ e resposta _JWT_) assinadas devem incluir as seguintes `claims` presentes na [RFC7519] (JWT):
-   * **aud** (na requisição _JWT_): o Provedor do Recurso (p. ex. a instituição detentora da conta) deverá validar se o valor do campo **aud** coincide com o endpoint sendo acionado;
-   * **aud** (na resposta _JWT_): o cliente da API (p. e. instituição iniciadora) deverá validar se o valor do campo **aud** coincide com o seu próprio `organisationId` listado no diretório;
-   * **iss** (na requisição _JWT_ e na resposta _JWT_): o receptor da mensagem deverá validar se o valor do campo **iss** coincide com o `organisationId` do emissor;
-   * **jti** (na requisição _JWT_ e na resposta _JWT_): o valor do campo **jti** deverá ser preenchido com o UUID definido pela instituição de acordo com a [RFC4122] usando o versão 4;
-   * **iat** (na requisição _JWT_ e na resposta _JWT_): o valor do campo **iat** deverá ser preenchido com horário da geração da mensagem e de acordo com o padrão  estabelecido na [RFC7519](https://datatracker.ietf.org/doc/html/rfc7519#section-2) para o formato _NumericDate_.
+3. The payload of signed messages (request _JWT_ and response _JWT_) shall include the following claims as defined at [RFC7519] (JWT):
+  * **aud** (in the _JWT_ request): the Resource Provider (eg the institution holding the account) must validate if the value of the **aud** field matches the endpoint being triggered;
+   * **aud** (in _JWT_ response): the API client (eg initiating institution) shall validate if the value of the **aud** field matches its own `organisationId` listed in the directory;
+   * **iss** (in the _JWT_ request and in the _JWT_ response): the receiver of the message shall validate if the value of the **iss** field matches the `organisationId` of the sender;
+   * **jti** (in the _JWT_ request and in the _JWT_ response): the value of the **jti** field shall be filled with the UUID defined by the institution according to [RFC4122] version 4;
+   * **iat** (in the _JWT_ request and in the _JWT_ response): the **iat** field  shall be filled with the message generation time and according to the standard established in [RFC7519](https:// datatracker.ietf.org/doc/html/rfc7519#section-2) to the _NumericDate_ format.
 
-4. O content-type HTTP das requisições e respostas com mensagens JWS deve ser definido como: "application/jwt".
+4. The HTTP content-type of requests and responses with JWS messages shall be defined as: "application/jwt".
 
-5. No cabeçalho JOSE deve constar os seguintes atributos:
-   * **alg** - deve ser preenchido com o valor `PS256`";
-   * **kid** - deve ser obrigatoriamente preenchido com o valor do identificador da chave utilizado para a assinatura;
-   * **typ** - deve ser preenchido com o valor `JWT`.
+5. The JOSE header must contain the following attributes:
+   * **alg** - shall be filled with the value `PS256`";
+   * **kid** - shall be filled with the key identifier value used for the signature;
+   * **typ** - shall be filled with the value `JWT`.
 
-* Em caso de erro na validação da assinatura pelo `Provedor do Recurso` a API deve retornar mensagem de erro HTTP com `status code` **400** e a resposta deve incluir na propriedade `code` do objeto de resposta de erro especificado na API (`ResponseError`) a indicação da falha com o conteúdo `BAD_SIGNATURE`.
-* Erros na validação da mensagem recebida pela aplicação cliente (p. ex. iniciador de pagamento) devem ser registrados e o `Provedor do Recurso` (p. ex. instituição detentora de conta) deve ser notificado.
+* In case of error in signature validation by `Resource Provider` the API provider shall return HTTP error message with `status code` **400** and the `ResponseError` content shall include, in the `code` property, the content `BAD_SIGNATURE`.
+* Errors in validating the signed messages received by the client application (eg payment initiator) must be logged and the `Resource Provider` (eg account holding institution) must be notified.
 
-6. O receptor  deve validar a consistência da assinatura digital da mensagem JWS **exclusivamente com base nas informações obtidas do diretório**, ou seja, com base nas chaves publicadas no JWKS da instituição no diretório.
+6. The receiver shall validate the consistency of the JWS message's digital signature **exclusively based on the information obtained from the directory**, that is, based on the keys published in the institution's JWKS in the directory.
 
-7. As assinaturas devem ser realizadas com uso do certificado digital de assinatura especificado no [Padrão de Certificados Open Banking Brasil](https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-certificate-standards-1_ID1-ptbr.md#certificado-de-assinatura-certificadoassinatura).
+7. Signatures must be performed using the digital signature certificate specified in the [Open Banking Brazil Certificates Standard](https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil -certificate-standards-1_ID1-ptbr.md#certificate-of-signing-certificatesignature).
 
-### Considerações sobre algoritmos de assinatura {#alg}
+## Algorithm considerations
 
-Para JWS, clientes e servidores de autorização
+For JWS, both clients and Authorization Servers
 
-1. devem usar o algoritmo PS256;
+1. shall use PS256 algorithm;
 
-### Considerações de algoritmo de criptografia  {#cipher}
+### Encryption algorithm considerations
 
-Para JWE, clientes e servidores de autorização
+For JWE, both clients and Authorization Servers
 
-1. devem usar RSA-OAEP com A256GCM
+1. shall use RSA-OAEP with A256GCM
 
-### Considerações sobre o uso seguro do Transport Layer Security  {#tls}
+### Secure Use of Transport Layer Security considerations
 
-Para TLS, endpoints do Servidor de Autenticação e endpoints do Servidor de Recursos usados diretamente pelo cliente:
+For TLS, Authorization Server endpoints and Resource Server endpoints used directly by the Client
 
-1. devem suportar `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
-2. devem suportar `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
+1. shall support `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
+2. shall support `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
 
-# Considerações sobre compartilhamento de dados  {#dados}
+# Data Sharing Considerations
 
-## Mecanismo de Autorização  {#authmech}
+## Authorisation Mechanism
 
-### Introdução  {#authmechintro}
+### Introduction
 
-Os mecanismos existentes para gerenciar adequadamente o acesso aos recursos definidos em [RFC6749] são insuficientes para atender aos requisitos de um ecossistema de compartilhamento de dados moderno. Aproveitar strings de escopo estático não fornece aos consumidores controle de granularidade suficiente para compartilhar com terceiros. O Open Banking Brasil optou por implementar uma [API de consentimento](https://openbanking-brasil.github.io/areadesenvolvedor/swagger/swagger_consents_apis.yaml) como um recurso protegido OAuth 2.0 que pode ser usado para gerenciar o acesso granular aos recursos. A referência ao recurso de consentimento será transmitida como parte de um escopo de recurso dinâmico OAuth 2.0.
+Existing mechanisms for appropriately managing access to resources defined in [RFC6749] are insufficient to meet the requirements for a modern data sharing ecosystem. Leveraging static scope strings does not provide consumers control of sufficient granularity to share with third parties. Open Banking Brasil have elected to implement a [Consent API](https://openbanking-brasil.github.io/areadesenvolvedor/swagger/swagger_consents_apis.yaml) as a OAuth 2.0 protected resource that can be used to manage fine grain access to resources. The reference to the Consent Resource will be conveyed as part of an OAuth 2.0 dynamic resource scope.
 
-### Definição de Escopo de Consentimento Dinâmico  {#consent}
+### Dynamic Consent Scope Definition
 
-Este perfil define o escopo dinâmico do OAuth 2.0 "consentimento" da seguinte maneira:
+This profile defines OAuth 2.0 dynamic scope "consent" as follows:
 
-* string 'consent'; e
-* delimitador de dois pontos ":"; e
-* Consent API REST Resource Id retornado por uma criação bem-sucedida de [Open Banking Consent Resource](https://openbanking-brasil.github.io/areadesenvolvedor/#fase-2-apis-do-open-banking-brasil-api-consentimento);
+* string 'consent'; and
+* delimiter of a colon ":"; and
+* Consent API REST Resource Id as returned by a successful creation of [Open Banking Consent Resource](https://openbanking-brasil.github.io/areadesenvolvedor/#fase-2-apis-do-open-banking-brasil-api-consentimento);
 
-Adicionalmente:
+In addition:
 
-* Consent Resource Id deve incluir caracteres seguros para url;
-* Consent Resource Id deve ser "namespaced";
-* Consent Resource Id deve ter propriedades de um `nonce` [Nonce](https://openid.net/specs/openid-connect-core-1_0.html#NonceNotes);
-
-### Dynamic Consent Scope Example  {#consentexample}
-
-consent:urn:bancoex:C1DD33123
+* the Consent Resource Id must include url safe characters only;
+* the Consent Resource Id must be namespaced;
+* the Consent Resource Id must have the properties of a nonce;
 
-### Exemplo de escopo de consentimento dinâmico  {#consentid}
+### Dynamic Consent Scope Example
 
 consent:urn:bancoex:C1DD33123
 
-## Ciclo de vida da autorização  {#lifecycle}
+## Authorisation Life Cycle
 
-### Introdução  {#lifecycleintro}
+### Introduction
 
-O recurso de consentimento tem um ciclo de vida gerenciado separada e distintamente da estrutura de autorização OAuth 2.0. As transições de estado e comportamentos esperados e condições de erro esperados dos Recursos REST protegidos com este perfil são definidos nas especificações funcionais da API publicadas pelo Open Banking Brasil.
+The Consent Resource has a life cycle that is managed seperately and distinctly from the OAuth 2.0 Authorisation Framework. The state transitions and expected behaviours and error conditions expected of REST Resources protected with this profile are defined in the functional API specifications published by Open Banking Brasil.
 
-### Servidor de autorização  {#lifecycleauth}
+### Authorization server
 
-Além dos requisitos descritos nas disposições de segurança do Open Banking Brasil, o Servidor de Autorização
+In addition to the requirements outlined in Open Banking Brasil security provisions the Authorization Server
 
-1. deve apenas emitir _refresh_tokens_ quando vinculados a um consentimento ativo e válido;
-2. só deve compartilhar o acesso aos recursos quando apresentado _access_token_ vinculado a um consentimento ativo e válido;
-3. deve revogar os _refresh tokens_ e, quando aplicável, os _access tokens_ quando o Consentimento (Consent Resource) relacionado for apagado;
-4. deve garantir que os _access tokens_ são emitidos com os _scopes_ necessários para permitir acesso aos dados especificados em elemento _Permission_ do Consentimento (Consent Resource Object) relacionado;
-5. não deve rejeitar pedido de autorização com _scopes_ além do necessário para permitir acesso a dados definidos em elemento _Permission_ do Consentimento (Consent Resource Object) relacionado;
-6. pode reduzir o escopo solicitado para um nível que seja suficiente para permitir o acesso aos dados definidos em elemento _Permission_ do Consentimento (Consent Resource Object) relacionado;
-7. deve manter registros sobre o histórico dos consentimento para permitir a adequada formação de trilhas de auditoria em conformidade com a regulação em vigor;
-8. deve retornar falha na autenticação e o código de retorno _access_denied_ no parâmetro _erro_ (como especificado na seção 4.1.2.1 da [RFC6749]) caso o CPF do usuário autenticado não seja o mesmo indicado no elemento _loggedUser_ do Consentimento (Consent Resource Object);
-9. deve retornar falha na autenticação e o código de retorno _access_denied_ no parâmetro _erro_ (como especificado na seção 4.1.2.1 da [RFC6749]) caso o elemento _businessEntity_ não tenha sido preenchido no Consentimento (Consent Resource Object) relacionado e o usuário tenha selecionado ou se autenticado por meio de credencial relacionada à conta do tipo Pessoa Jurídica (PJ);
-10. deve condicionar a autenticação ou seleção de contas do tipo PJ à consistência entre o CNPJ relacionado à(s) conta(s) e o valor presente no elemento _businessEntity_ do Consentimento (Consent Resource Object). Em caso de divergência deve retornar falha na autenticação e o código de retorno _access_denied_ no parâmetro _erro_ (como especificado na seção 4.1.2.1 da [RFC6749]);
-11. deve emitir _refresh_token_ com validade não inferior à validade do consentimento ao qual está relacionado, respeitado os demais critérios acima.
+1. shall only issue tokens on presentation of a refresh token when the consent resource the refresh token is bound to is active and valid;
+2. shall only share access to resources when presented with an access token linked to an active and valid consent;
+3. shall revoke refresh tokens and where practicable access tokens when the linked Consent Resource is deleted;
+4. shall ensure Access Tokens are issued with sufficient scope necessary for access to data specified in the Permissions element of a linked Consent Resource object;
+5. shall not reject an authorisation request requesting more scope than is necessary to access data specified in the Permissions element of a linked Consent Resource object;
+6. may reduce requested scope to a level sufficient to enable access to data resources specified in the Permissions element of a linked Consent Resource object;
+7. shall retain a complete audit history of the consent resource in accordance with current Central Bank brazilian regulation;
+8. shall return authentication failure and return code _access_denied_ in the _error_ parameter (as specified in section 4.1.2.1 of [RFC6749]) if the CPF of the authenticated user is not the same as indicated in the _loggedUser_ element of the Consent Resource Object;
+9. shall return authentication failure and return code _access_denied_ in the _error_ parameter (as specified in section 4.1.2.1 of [RFC6749]) if the _businessEntity_ element has not been populated in the related Consent Resource Object and the user has selected or authenticated by using a credential related to a business account;
+10. an autenticated or selected business account´s CNPJ must match the value present in the _businessEntity_ element of the Consent Resource Object. In case of divergence authorization server shall return authentication failure and return code _access_denied_ in the _error_ parameter (as specified in section 4.1.2.1 of [RFC6749]);
+11. shall ensure _refresh_tokens_ expiration time is at least equal to the linked consent resource expiration time.
 
-### Cliente confidencial  {#clientconfidential}
+### Confidential Client
 
-Além dos requisitos descritos nas disposições de segurança do Open Banking Brasil, o Cliente Confidencial
+In addition to the requirements outlined in Open Banking Brasil security provisions the Confidential Client
 
-1. deve, sempre que possível, revogar e cessar o uso de _refresh_ e de _access tokens_  vinculados a um consentimento (Consent Resource Object) que foi excluído;
-2. deve excluir consentimentos (Consent Resource Objects) que estão expirados;
+1. shall revoke where possible and cease usage of refresh and access tokens that are bound to a Consent Resource that has been deleted;
+1. shall delete Consent Resource that are expired;
 
-# Reconhecimentos  {#acknowledgement}
+# Acknowledgements
 
-Agradecemos a todos que estabeleceram as bases para o compartilhamento seguro e seguro de dados por meio da formação do Grupo de Trabalho FAPI da OpenID Foundation, o GT de Segurança do Open Banking Brasil e aos pioneiros que ficarão em seus ombros.
+With thanks to all who have set the foundations for secure and safe data sharing through the formation of the OpenID Foundation FAPI Working Group, the Open Banking Brasil GT Security and to the pioneers who will stand on their shoulders.
 
-As seguintes pessoas contribuíram para este documento:
+The following people contributed to this document:
 
 * Ralph Bragg (Raidiam)
 * Joseph Heenan (Authlete)
@@ -437,10 +449,10 @@ As seguintes pessoas contribuíram para este documento:
 
 {backmatter}
 
-# Avisos  {#disclaimer}
+# Notices
 
-Copyright (c) 2021 Estrutura Inicial do Open Banking Brasil
+Copyright (c) 2021 Open Banking Brasil Initial Structure.
 
-A Estrutura Inicial do Open Banking Brasil (EIOBB) concede a qualquer Colaborador, desenvolvedor, implementador ou outra parte interessada uma licença de direitos autorais mundial não exclusiva, livre de royalties para reproduzir, preparar trabalhos derivados, distribuir, executar e exibir, estes Implementadores Rascunho ou Especificação Final exclusivamente para fins de (i) desenvolver especificações e (ii) implementar Rascunhos de Implementadores e Especificações Finais com base em tais documentos, desde que a atribuição seja feita ao EIOBB como a fonte do material, mas que tal atribuição o faça não indica endosso do EIOBB.
+The Open Banking Brasil Initial Structure (OBBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OBBIS as the source of the material, but that such attribution does not indicate an endorsement by the OBBIS.
 
-A tecnologia descrita nesta especificação foi disponibilizada a partir de contribuições de várias fontes, incluindo membros da OpenID Foundation, do Grupo de Trabalho de Segurança do Open Banking Brasil e outros. Embora a Estrutura Inicial do Open Banking Brasil tenha tomado medidas para ajudar a garantir que a tecnologia esteja disponível para distribuição, ela não toma posição quanto à validade ou escopo de qualquer propriedade intelectual ou outros direitos que possam ser reivindicados como pertencentes à implementação ou uso do tecnologia descrita nesta especificação ou até que ponto qualquer licença sob tais direitos pode ou não estar disponível; nem representa que fez qualquer esforço independente para identificar tais direitos. A Estrutura Inicial do Open Banking Brasil e os contribuidores desta especificação não oferecem (e por meio deste expressamente se isentam de quaisquer) garantias (expressas, implícitas ou de outra forma), incluindo garantias implícitas de comercialização, não violação, adequação a uma finalidade específica ou título, relacionados a esta especificação, e todo o risco quanto à implementação desta especificação é assumido pelo implementador. A política de Direitos de Propriedade Intelectual do Open Banking Brasil exige que os contribuidores ofereçam uma promessa de patente de não fazer valer certas reivindicações de patentes contra outros contribuidores e implementadores. A Estrutura Inicial do Open Banking Brasil convida qualquer parte interessada a trazer à sua atenção quaisquer direitos autorais, patentes, pedidos de patentes ou outros direitos de propriedade que possam abranger a tecnologia que possa ser necessária para praticar esta especificação.
\ No newline at end of file
+The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation, the Open Banking Brasil GT Security Working Group and others. Although the Open Banking Brasil Initial Structure has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The Open Banking Brasil Initial Structure and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The Open Banking Brasil Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The Open Banking Brasil Initial Structure invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.

From 24dc6732e0edebdd7068129dc8d30dd17153950d Mon Sep 17 00:00:00 2001
From: Alexandre Daniel Dalabrida <alexandre.dalabrida@ailos.coop.br>
Date: Fri, 12 Nov 2021 14:47:13 -0300
Subject: [PATCH 39/59] =?UTF-8?q?Ajuste=20na=20documenta=C3=A7=C3=A3o=20da?=
 =?UTF-8?q?=20proibi=C3=A7=C3=A3o=20da=20rota=C3=A7=C3=A3o=20do=20refresh?=
 =?UTF-8?q?=20token=20em=20ingles=20e=20portugues?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...banking-brasil-financial-api-1_ID3-ptbr.md | 415 +++++++++---------
 open-banking-brasil-financial-api-1_ID3.md    |  18 +-
 2 files changed, 211 insertions(+), 222 deletions(-)

diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.md b/open-banking-brasil-financial-api-1_ID3-ptbr.md
index fc27f9f..093caf0 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.md
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.md
@@ -15,7 +15,7 @@
     [seriesInfo]
     name = "Internet-Draft"
     status = "standard"
-    value = "open-banking-brasil-financial-api-1_ID3"
+    value = "open-banking-brasil-financial-api-1_ID3-ptbr"
 
     [[author]]
     initials = "R."
@@ -38,50 +38,51 @@
       uri = "https://openbankingbrasil.org.br/"
 %%%
 
-.# Foreword
+.# Prefácio  {#Foreword}
 
-Este documento também está disponível em [português](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3-ptbr.html)
+The normative version in [English](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html)
 
-The Open Banking Brasil Initial Structure is responsible for creating standards and specifications necessary to meet the requirements and obligations of the Brasil Open Banking Legislation as originally outlined by the [Brasil Central Bank](https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf). There is a possibility that some of the elements of this document may be the subject to patent rights. OBBIS shall not be held responsible for identifying any or all such patent rights.
+A Estrutura Inicial do Open Banking Brasil (EIOBB) é responsável por criar padrões e especificações necessárias para atender aos requisitos e obrigações da Legislação do Open Banking do Brasil, conforme originalmente delineado pelo [Banco Central do Brasil](https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf). É possível que alguns dos elementos deste documento estejam sujeitos a direitos autorais ou patenteados. O EIOBB não se responsabiliza pela identificação de qualquer ou todos esses direitos.
 
-Open Banking Brasil Financial-grade API Security Profile 1.0 consists of the following parts:
+O Financial-grade API 1.0 do Open Banking Brasil consiste nas seguintes partes:
 
 * Open Banking Brasil Financial-grade API Security Profile 1.0
 * [Open Banking Brasil Dynamic Client Registration Profile 1.0][OBB-FAPI-DCR]
 
-These parts are intended to be used with [RFC6749], [RFC6750], [RFC7636], [OIDC], [FAPI-1-Baseline] and [FAPI-1-Advanced]
+Estas partes são destinados a serem usados com [RFC6749], [RFC6750], [RFC7636], [OIDC], [FAPI-1-Baseline] e [FAPI-1-Advanced]
 
-.# Introduction
+.# Introdução  {#Introduction}
 
-The Open Banking Brasil Financial-grade API is a highly secured OAuth profile that aims to provide specific implementation guidelines for security and interoperability which can be applied to APIs in the Brasil Open Banking area that require a higher level of privacy than provided by standard [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced]. Among other enhancements, this specification addresses privacy considerations identified in [FAPI-1-Advanced] that are relevent in the Open Banking Brasil specifications but have not, so far, been required by other jurisdictions.
+A Financial-grade API do Open Banking Brasil é um perfil OAuth altamente seguro que visa fornecer diretrizes de implementação específicas para segurança e interoperabilidade que podem ser aplicadas a APIs na área de Open Banking do Brasil que requerem um nível de privacidade superior ao fornecido pelo padrão [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced]. Entre outras melhorias, esta especificação aborda considerações de privacidade identificadas em [FAPI-1-Advanced] que são relevantes nas especificações do Open Banking Brasil, mas não foram, até agora, exigidas por outras jurisdições.
 
-Although it is possible to code an OpenID Provider and Relying Party from first principles using this specification, the main audience for this specification is parties who already have a certified implementation of [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] and want to achieve certification for the Brasil Open Banking programme.
+Embora seja possível codificar um provedor de OpenID e parte de confiança a partir dos primeiros princípios usando esta especificação, o público principal para esta especificação são as partes que já possuem uma implementação certificada do [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] e deseja obter a certificação para o programa Brasil Open Banking.
 
-.# Notational Conventions
+.# Convenções Notacionais  {#Notational}
 
-The key words "shall", "shall not",
-"should", "should not", "may", and
-"can" in this document are to be interpreted as described in
-[ISO Directive Part 2][ISODIR2].
-These key words are not used as dictionary terms such that
-any occurrence of them shall be interpreted as key words
-and are not to be interpreted with their natural language meanings.
+As palavras-chave "*deve*" (shall), "*não deve*" (shall not), "*deveria*" (should), "*não deveria*" (should not) e "*pode*" (may) presentes nesse documento devem ser interpretadas conforme as diretrizes descritas em [ISO Directive Part 2][ISODIR2] observando  seguinte equivalência:
+
+* "deve" => equivalente ao termo "shall" e expressa um requerimento definido no documento (nas traduções é similar ao termo "must", que pode denotar um requerimento externo ao documento);
+* "não deve" => equivalente ao termo "shall not" e também expressa um requerimento definido no documento;
+* "deveria" e "não deveria"=> equivalente ao termo "should" e "should not" e expressa uma recomendação
+* "pode" => equivalente ao termo "may" indica uma permissão
+
+Estas palavras-chave não são usadas como termos de dicionário, de modo que qualquer ocorrência deles deve ser interpretada como palavras-chave e não devem ser interpretados com seus significados de linguagem natural.
 
 {mainmatter}
 
-# Scope
+# Escopo  {#Scope}
 
-This document specifies the method of
+Este documento especifica o método para os aplicativos
 
-* applications to obtain the OAuth tokens in an appropriately secure manner for higher risk access to data in a manner that meets the requirements of [Open Banking Brasil](https://www.in.gov.br/en/web/dou/-/resolucao-conjunta-n-1-de-4-de-maio-de-2020-255165055);
-* applications to use OpenID Connect to identify the customer; and
-* applications to use OpenID Connect to assert identity of the customer;
+* obterem de maneira segura os tokens OAuth necessários para acesso a dados críticos de acordo com os requisitos do [Open Banking Brasil](https://www.in.gov.br/en/web/dou/-/resolucao-conjunta-n-1-de-4-de-maio-de-2020-255165055);
+* utilizarem o OpenID Connect para identificação do usuário do Open Banking; e
+* utilizarem o OpenID Connect para afirmar a identidade do cliente.
 
-This document is applicable to all participants engaging in Open Banking in Brasil.
+Este documento é aplicável a todos os participantes do Open Banking no Brasil.
 
-# Normative references
+# Referências normativas  {#Normative}
 
-The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applied. For undated references, the latest edition of the referenced document (including any amendments) applies.
+Os seguintes documentos referenciados são indispensáveis para a adoção das especificações deste documento. Para referências datadas, apenas a edição citada se aplica. Para referências não datadas, deve-se aplicar a última edição do documento referenciado (incluindo quaisquer emendas).
 
 [ISODIR2] - ISO/IEC Directives Part 2
 [ISODIR2]: <https://www.iso.org/sites/directives/current/part2/index.xhtml
@@ -146,9 +147,6 @@ The following referenced documents are indispensable for the application of this
 [FAPI-2-Baseline] - Financial-grade API Security Profile 2.0 - Part 1: Baseline
 [FAPI-2-Baseline]: <https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md
 
-[FAPI-2-Advanced] - Financial-grade API Security Profile 2.0 - Part 2: Advanced
-[FAPI-2-Advanced]: <https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Advanced_Profile.md
-
 [LIWP] - OIDF FAPI WG Lodging Intent Working Paper
 [LIWP]: <https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md
 
@@ -158,288 +156,277 @@ The following referenced documents are indispensable for the application of this
 [RFC4648] - The Base16, Base32, and Base64 Data Encodings
 [RFC4648]: <https://tools.ietf.org/html/rfc4648
 
-# Terms and definitions
+# Termos e definições  {#definitions}
 
-For the purpose of this document, the terms defined in [RFC6749], [RFC6750], [RFC7636], [OpenID Connect Core][OIDC] and ISO29100 apply.
+Para efeitos deste documento, os termos definidos em [RFC6749], [RFC6750], [RFC7636], [OpenID Connect Core][OIDC] e ISO29100 se aplicam.
 
-# Symbols and Abbreviated terms
+# Símbolos e termos abreviados  {#terms}
 
-**API** – Application Programming Interface
+**API** - Application Programming Interface (Interface de programação de aplicativo)
 
-**OBBIS** – Open Banking Brasil Initial Structure
+**EIOBB** - Estrutura Inicial do Open Banking Brasil
 
 **CSRF** - Cross Site Request Forgery
 
-**DCR** – Dynamic Client Registration
+**DCR** - Registro de cliente dinâmico
 
 **FAPI** - Financial-grade API
 
-**HTTP** – Hyper Text Transfer Protocol
+**HTTP** - Protocolo de transferência de hipertexto
 
 **OIDF** - OpenID Foundation
 
-**REST** – Representational State Transfer
+**REST** - Representational State Transfer (Transferência de Estado Representacional)
+
+**TLS** - Transport Layer Security (Segurança da Camada de Transporte)
+
+**MFA** - Multi-Factor Authentication (Autenticação por Múltiplos Fatores)
+
+# Profile de Segurança para o Open Banking Brasil {#securityprofile}
 
-**TLS** – Transport Layer Security
+## Introdução  {#secintroduction}
 
-**MFA** - Multi-Factor Authentication
+O perfil de segurança do Open Banking Brasil especifica requisitos adicionais de segurança e de  identificação para o acesso a API´s com recursos críticos protegidas pelo OAuth 2.0 Authorization Framework, que consiste em [RFC6749], [RFC6750], [RFC7636], [FAPI-1-Baseline], [FAPI-1-Advanced] e outras especificações.
 
-# Brasil Open Banking Security Profile
+Este perfil descreve as capacidades e os recursos de segurança que devem ser oferecidos por servidores e clientes que são necessários para o Programa do Open Banking Brasil, definindo as medidas para mitigar ou endereçar:
 
-## Introduction
+* ataques que abordam considerações de privacidade identificadas na cláusula 9.1 de [FAPI-1 Advanced].
+* o requisito de concessão de acesso granular a recursos, com vistas à minimização de dados;
+* o requisito de informar sobre o contexto da autenticação do usuário (claim Authentication Context Request - acr) que foi realizada por um Provedor OpenID, com vistas a favorecer o adequado gerenciamento do risco decorrente do acesso do usuário;
+* o requisito para que os clientes de API declarem um relacionamento prévio com o usuário, afirmando em uma `claim` de identificação do usuário como parte do fluxo de autorização.
 
-The Brasil Open Banking Security profile specifies additional security and identity requirements for high risk API resources protected by the OAuth 2.0 Authorization Framework that consists of [RFC6749], [RFC6750], [RFC7636], [FAPI-1-Baseline], [FAPI-1-Advanced] and other specifications.
+## Disposições de segurança do Open Banking Brasil  {#authserver}
 
-This profile describes security and features provisions for a server and client that are necessary for the Brasil Open Banking Programme by defining the measures to mitigate or address:
+### Introdução  {#authintrod}
 
-* attacks that address privacy considerations identified in clause 9.1 of [FAPI1 Advanced]
-* the requirement to support fine-grained access to resources for data minimisation purposes
-* the requirement to convey the Authentication Context Request that was performed by an OpenID Provider to a Client to enable a appropriate client management of customer conduct risk.
-* the requirement for clients to assert a pre-existing customer relationship by asserting a customer identity claim as part of the authorization flow.
+O Open Banking Brasil tem um requisito para endereçar considerações de privacidade que foram identificadas, mas não abordadas na especificação final [FAPI-1-Advanced], sem impor requisitos adicionais aos Servidores de Autorização que estão sendo propostos em [FAPI-2-Baseline].
 
-## Open Banking Brasil security provisions
+Os participantes desse ecossistema precisam que os clientes de API solicitem a um provedor openid a confirmação dos valores das `claims` de identificação do usuário como parte de uma solicitação de autorização usando o mecanismo definido na cláusula 5.5.1 de [OIDC].
 
-### Introduction
+O uso do parâmetro `claims` para solicitar a validação de valores de identificação explícitos requer que os clientes de API protejam com criptografia o Request Object para evitar vazamento de informações. Este risco é identificado na cláusula 7.4.1 do [FAPI-1-Baseline].
 
-Open Banking Brasil has a requirement to address privacy considerations that were identified but not addressed in the [FAPI-1-Advanced] final specification without imposing additional requirements on Authorisation Servers being proposed in [FAPI-2-Baseline].
-Participants in this ecosystem have a need for clients to request an openid provider to confirm values of identity claims as part of an authorization request using the mechanism defined in clause 5.5.1 of [OIDC].
-The use of the claims parameter to request explicit claims values requires clients to ensure that they encrypt the request object to avoid information leakage. This risk is identified in clause 7.4.1 of [FAPI-1-Baseline].
-In addition this profile describes the specific scope, acr and client management requirements necessary to support the wider Open Banking Brasil ecosystem.
+Além disso, este perfil descreve o escopo específico, valores de `acr` e requisitos de gerenciamento de clientes necessários para dar suporte ao ecossistema Open Banking Brasil mais amplo.
 
-As a profile of the OAuth 2.0 Authorization Framework, this document mandates the following for the Brasil Open Banking Security profile.
+Como um perfil do OAuth 2.0 Authorization Framework, este documento exige o seguinte para o perfil de segurança do Open Banking Brasil.
 
-### Authorization server
+### Servidor de Autorização  {#authprovisions}
 
-The Authorization Server shall support the provisions specified in clause 5.2.2 of [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced]
+O Servidor de Autorização **deve** suportar as disposições especificadas na cláusula 5.2.2 de [Financial-grade API Security Profile 1.0 - Parte 2: Advanced] [FAPI-1-Advanced].
 
-In addition, the Authorization Server
+Além disso, ele deve:
 
-1. shall support a signed and encrypted JWE request object passed by value or shall require pushed authorization requests [PAR];
-2. shall distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in [OIDD] and [RFC8414]
-3. shall support the claims parameter as defined in clause 5.5 [OpenID Connect Core][OIDC]
-4. shall support the oidc standard claim "cpf" as defined in clause 5.2.2.2 of this document
-5. shall support the oidc standard claim "cnpj" as defined in clause 5.2.2.3 of this document if providing access to resources where the resource owner is not a `natural person`
-6. shall support the acr "urn:brasil:openbanking:loa2" as defined in clause 5.2.2.4 of this document
-7. should support the acr "urn:brasil:openbanking:loa3" as defined in clause 5.2.2.4 of this document
-8. shall implement the userinfo endpoint as defined in clause 5.3 [OpenID Connect Core][OIDC]
-9. shall support parameterized OAuth 2.0 resource scope _consent_ as defined in clause 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP]
-10. may support [Financial-grade API: Client Initiated Backchannel Authentication Profile][FAPI-CIBA]
-11. (withdrawn)
-12. shall support refresh tokens
-13. shall not allow `refresh tokens` rotation feature
-14. shall issue access tokens with an expiry no greater than 900 seconds and no less than 300 seconds
-15. shall always include an acr claim in the `id_token`
-16. shall support the `response_type` value `code id_token`
-17. may support `response_type` value `code` in conjunction with the `response_mode` value `jwt`
+1. deve suportar Request Objects JWE assinados e criptografados passados por valor ou deve exigir requisições do tipo "pushed authorization requests" [PAR]
+2. deve publicar metadados de descoberta (incluindo a do endpoint de autorização) por meio do documento de metadado especificado em [OIDD] e [RFC8414] (".well-known")
+3. deve suportar os parâmetros `claims` como definido no item 5.5 do [OpenID Connect Core][OIDC]
+4. deve suportar o atributo `claim` padrão oidc "cpf" conforme definido no item 5.2.2.2 deste documento
+5. deve suportar o atributo `claim` padrão oidc "cnpj" conforme definido no item 5.2.2.3 deste documento, se a instituição for detentora de conta para pessoas jurídicas
+6. deve suportar o atributo `acr` "urn:brasil:openbanking:loa2" como definido no item 5.2.2.4 deste documento
+7. deveria suportar o atributo `acr` "urn:brasil:openbanking:loa3" como definido no item 5.2.2.4 deste documento
+8. deve implementar o endpoint "userinfo" como definido no item 5.3 do [OpenID Connect Core][OIDC]
+9. deve suportar o escopo parametrizável ("parameterized OAuth 2.0 resource scope") _consent_ como definido no item 6.3.1 de [OIDF FAPI WG Lodging Intent Pattern][LIWP]
+10. pode suportar [Financial-grade API: Client Initiated Backchannel Authentication Profile][FAPI-CIBA]
+11. (requisito temporariamente retirado)
+12. deve suportar `refresh tokens`
+13. não deve permitir o recurso de rotação de `refresh tokens`
+14. deve emitir `access tokens` com o tempo de expiração entre 300 (mínimo) e 900 (máximo) segundos
+15. deve sempre incluir a claim `acr` no id_token
+16. deve suportar os valores `code` e `id_token` para o atributo `response_type`
+17. pode suportar o valor `code` para o atributo `response_type`em conjunto com o valor `jwt` para o atributo `response_mode`
 
+#### Token de ID como assinatura separada  {#detached}
 
-#### ID Token as detached signature
+O Servidor de Autorização *deve* suportar as disposições especificadas na cláusula 5.2.2.1 de [Financial-grade API Security Profile 1.0 - Parte 2: Advanced] [FAPI-1-Advanced]
 
-The Authorization Server shall support the provisions specified in clause 5.2.2.1 of [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced]
+Além disso, se o valor `response_type` `code id_token` for usado, o servidor de autorização:
 
-In addition, if the `response_type` value `code id_token` is used, the Authorization Server
+1. **não deveria** retornar Informação de Identificação Pessoal (PII) confidenciais no token de ID na resposta de autorização, mas se for necessário, então ele **deve** criptografar o token de ID.
 
-1. should not return sensitive PII in the ID Token in the authorization response, but if it needs to,
-then it shall encrypt the ID Token.
+#### Solicitando uma "claim" **cpf**  {#cpf}
 
-#### Requesting the "cpf" Claim
+Este perfil define "cpf" como uma nova `claim` padrão de acordo com cláusula 5.1 [OIDC]
 
-This profile defines "cpf" as a new standard claim as per
- clause 5.1 [OIDC]
+O número do **CPF** (Cadastro de Pessoas Físicas, [sepeˈɛfi]; português para "Registro de Pessoas Físicas") é o cadastro de pessoa física **brasileira**. Este número é atribuído pela Receita Federal **Brasileira** para brasileiros e estrangeiros residentes que, direta ou indiretamente, pagar impostos no **Brasil**.
 
-The **CPF** number (Cadastro de Pessoas Físicas, [sepeˈɛfi]; Portuguese for "Natural Persons Register")
- is the **Brazilian** individual taxpayer registry identification. This number is attributed by
- the **Brazilian** Federal Revenue to Brazilians and resident aliens who, directly or indirectly,
-  pay taxes in **Brazil**.
-In the Brasil Open Banking identity model, the cpf is a string consisting of numbers that is 11
-characters long and may start with a 0.
-If the cpf Claim is requested as an Essential Claim for the ID Token or UserInfo response with a
-values parameter requesting a specific cpf value, the Authorization Server MUST return a cpf Claim Value
-that matches the requested value. If this is an Essential Claim and the requirement cannot be met,
- then the Authorization Server MUST treat that outcome as a failed authentication attempt.
+No modelo de identidade do Open Banking Brasil, o cpf é uma string composta por números 11 caracteres de comprimento e podem começar com 0.
 
-Name: cpf, Type: String, Regex: '^\d{11}$'
+Se a Claim **cpf** for solicitada como essencial para constar no ID token ou na resposta ao endpoint de UserInfo e na solicitação constar no parâmetro `value` com determinado **CPF** exigido, o Authorization Server **DEVE** retornar no atributo **cpf** o valor que corresponda ao da solicitação.
 
-#### Requesting the "cnpj" Claim
+Se a Claim **cpf** for solicitada como essencial para constar no ID Token ou na resposta no endpoint de UserInfo, o Authorization Server deve retornar no atributo **cpf** o valor com o **CPF** do usuário autenticado.
 
-This profile defines "cnpj" as a new standard claim as per
- clause 5.1[OIDC]
+Se a Claim **cpf** indicada como essencial não puder ser preenchida ou não for compatível com o requisito, o Authorization Server deve tratar a solicitação como uma tentativa de autenticação com falha.
 
-**CNPJ**, short for Cadastro Nacional de Pessoas Jurídicas, is an identification number
- of **Brazilian** companies issued by the **Brazilian** Ministry of Revenue, **in**
- Portuguese "Secretaria da Receita Federal" or "Ministério da Fazenda". In the Brasil Open Banking identity model,
- individuals can associated with 0 or more CNPJs. A CNPJ is a string consisting of numbers that is 14 digits long and may start with a 0,
- the first eight digits identify the company, the four digits after the slash identify the branch or
-  subsidiary ("0001" defaults to the headquarters), and the last two are checksum digits.
-   For this profile, the cnpj claim must be requested and supplied as the 14 digit number.
+Nome: cpf, Tipo: String, Regex: '^\d{11}$'
 
-If the cnpj Claim is requested as an Essential Claim for the ID Token or UserInfo response with a
-values parameter requesting a specific cnpj value, the Authorization Server MUST return a cnpj
-Claim Value that contains a **set** of CNPJs one of which must match the requested value. If this
- is an Essential Claim and the requirement cannot be met, then the Authorization Server MUST treat
- that outcome as a failed authentication attempt.
+#### Solicitando a "claim" **cnpj**  {#cnpj}
 
-Name: cnpj, Type: Array of Strings, Array Element Regex: '^\d{14}$'
+Este perfil define "cnpj" como uma nova reivindicação padrão de acordo com cláusula 5.1 [OIDC]
 
-#### Requesting the "urn:brasil:openbanking:loa2" or "urn:brasil:openbanking:loa3" Authentication Context Request
+**CNPJ**, abreviação de Cadastro Nacional de Pessoas Jurídicas, é um número de identificação de empresas **brasileiras** emitidas pelo Ministério da Fazenda **brasileira**, **na** "Secretaria da Receita Federal" ou "Ministério da Fazenda" do Brasil. No modelo de identidade do Open Banking Brasil, pessoas físicas podem se associar a 0 ou mais CNPJs. Um CNPJ é uma string que consiste em números de 14 dígitos e pode começar com 0, os primeiros oito dígitos identificam a empresa, os quatro dígitos após a barra identificam a filial ou subsidiária ("0001" padrão para a sede), e os dois últimos são dígitos de soma de verificação. Para este perfil, o pedido de cnpj deve ser solicitado e fornecido como o número de 14 dígitos.
 
-This profile defines "urn:brasil:openbanking:loa2" and "urn:brasil:openbanking:loa3" as
- new Authentication Context Request classes.
+Se a Claim **cnpj** for solicitada como essencial para constar no ID Token ou na resposta ao endpoint UserInfo e na solicitação constar, no parâmetro `value`, determinado **CNPJ** exigido, o Authorization Server **DEVE** retornar no atributo **cnpj** um **conjunto** de **CNPJs** relacionado com o usuário, um dos quais deve incluir valor que corresponda ao da solicitação.
 
-* **LoA2:** Authentication performed using single factor;
-* **LoA3:** Authentication performed using multi factor (MFA)
+Se a Claim **cnpj** for solicitada como essencial para constar no ID Token ou na resposta ao endpoint UserInfo, o Authorization Server deve incluir no ID Token ou na resposta ao endpoint UserInfo um **conjunto** que inclua um elemento com o número do **CNPJ** relacionado à conta utilizada na autenticação do usuário.
 
-The following rules are applicable to **access control to Open Banking Brazil API´s:**
+Se a Claim **cnpj** indicada como essencial não puder ser preenchida ou validada, o Authorization Server deve tratar a solicitação como uma tentativa de autenticação com falha.
 
-* In accordance to Art. 17 of [Joint Resolution nº 01 - Open Banking Brasil](https://www.in.gov.br/en/web/dou/-/resolucao-conjunta-n-1-de-4-de-maio-de-2020-255165055), institutions must adopt procedures and controls for client authentication **compatible with those applicable in their electronic service channels**.
-* So, in compliance with the regulation, it is suggested that:
-   * **For Read-Only APIs  (Phase 2)**: the _Authorization Servers_ **should** adopt, at least, an authentication method compatible with `LoA2`; and
-   * **For Read-Write API´s (subsequent phases)**: the _Authorization Servers_ **should** adopt an authentication method compatible with `LoA3` or higher.
+Nome: cnpj, Tipo: Array of Strings, Array Element Regex: '^\d{14}$'
 
-In all cases, the adoption of a more rigorous authentication mechanism (`LoA3` or higher) is at the discretion of the Bank (ASPSP), according to its risk assessment and in a manner compatible with the mechanisms usually used.
+#### Solicitando o "urn:brasil:openbanking:loa2" ou "urn:brasil:openbanking:loa3" Solicitação de contexto de autenticação  {#loa}
 
-**Authentication factors clarification**
+* **LoA2**: mecanismo de autenticação com a adoção de um único fator
+* **LoA3**: mecanismo de autenticação com múltiplos fatores de autenticação
 
-The authentication methods are:
+A seguinte orientação deve ser observada para o mecanismo de autenticação:
+* De acordo com o Art. 17 da Resolução Conjunta nº 01, as instituições devem adotar  procedimentos e controles para autenticação de cliente **compatíveis com os aplicáveis ao acesso a seus canais de atendimento eletrônicos**.
+* Em observância à regulação em vigor, sugere-se que:
+  * **Para a autenticação do usuário em autorizações de acessos às APIs de compartilhamento de dados (Fase 2)**, os _Authorization Servers_ **deveriam** adotar, no mínimo, método compatível com `LoA2`; e
+  * **Para a autenticação do usuário em autorizações de acessos às API´s das fases subsequentes**, os _Authorization Servers_ **deveriam** adotar método de autenticação compatível com `LoA3` ou superior.
 
-* Something you know, such as password or phrase
-* Something you have, such as token or smartcard;
-* Something you are, such as biometric validation.
+Em todos os casos, a adoção de mecanismo de autenticação mais rigoroso (`LoA3` ou superior) fica a critério da instituição transmissora ou detentora de conta, de acordo com sua avaliação de riscos e de forma compatível com os mecanismos habitualmente utilizados.
 
-To performe a MFA authentication is necessary the end user to present at least two different methods as listed above. A unique method used more than once is not accepted as MFA.
+**Esclarecimentos adicionais sobre fatores de autenticação**
 
-### Confidential client
+São fatores de autenticação:
 
-A confidential client shall support the provisions specified in clause 5.2.3 of
+* Aquilo que **você conhece**, como uma senha ou frase secreta
+* Aquilo que **você tem**, como um token, smartcard ou dispositivo
+* Aquilo que **"você é"**, ou seja, autenticação condicionada a apresentação de uma característica física exclusivamente sua, como a validação por biometria
+
+Para realizar autenticação por múltiplos fatores (MFA) é necessário que o usuário apresente, ao menos, dois diferentes  fatores dos listados acima. Um mesmo fator usado mais de uma vez - por exemplo, a apresentação de suas senhas que ele conhece - não pode ser aceito como MFA.
+
+### Cliente confidencial  {#client}
+
+Um cliente confidencial deve apoiar as disposições especificadas na cláusula 5.2.3 de
 [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced],
 
-In addition, the confidential client
+Além disso, o cliente confidencial
 
-1. shall support _encrypted_ request objects
-2. shall support Pushed Authorisation Requests [PAR]
-3. shall use _encrypted_ request objects if not using [PAR]
-4. shall support parameterized OAuth 2.0 resource scope _consent_ as defined in clause 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP]
-5. shall support refresh tokens
-6. shall not allow `refresh tokens` rotation feature
-7. shall not populate the `acr` claim with required values
-8. shall require the `acr` claim as an essential claim
-9. shall support all authentication methods specified in clause 5.2.2-14 of [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] including diferent combinations of the methods to send requests (using [PAR] or not - item 11).
+1. deve suportar objetos de solicitação _encrypted_
+2. deve suportar solicitações de autorização push (pushed authorization requests) [PAR]
+3. deve usar objetos de solicitação _encrypted_ se não usar [PAR]
+4. deve suportar o escopo de recurso OAuth 2.0 parametrizado _consent_ conforme definido na cláusula 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP]
+5. deve suportar `refresh tokens`
+6. não deve permitir o recurso de rotação de `refresh tokens`
+7. não deve incluir um valor específico na _claim_ `acr`
+8. deve definir a _claim_ `acr`como _essential_
+9. deve suportar todos os métodos de autenticação especificados no item 14 da seção 5.2.2 da [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] incluindo as diferentes combinações de métodos de encaminhamento dos Requests Objects (usando ou não [PAR] - item 11).
 
-# Security considerations
+# Considerações de segurança  {#authserver}
 
-Participants shall support all security considerations specified in clause 8
- [Financial-grade API Security Profile 1.0 - Part 1: Advanced][FAPI-1-Advanced] and the [Brazilian Central Bank Open Banking Security Manual](https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Instru%C3%A7%C3%A3o%20Normativa%20BCB&numero=134).
- The Brazilian ICP issues RSA x509 certificates only therefor section removes for simplicity support for EC algorithms
- and requires that only IANA recommended encryption algorithms be used.
+Os participantes devem apoiar todas as considerações de segurança especificadas na cláusula 8 [Financial-grade API Security Profile 1.0 - Parte 2: Advanced] [FAPI-1-Advanced] e o [Manual de Segurança de Banco Central do Brasil] (https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Instru%C3%A7%C3%A3o%20Normativa%20BCB&numero=134). O ICP brasileiro emite certificados RSA x509 somente, portanto, para simplificar, a seção remove o suporte para algoritmos EC e exige que apenas algoritmos de criptografia recomendados pela IANA sejam usados.
 
-## Message Content Signing Considerations (JWS) {#jws}
+## Considerações sobre assinatura do conteúdo de mensagens (JWS) {#jws}
 
-1. JWS standad defined in [RFC7515] shall be adopted to ensure integrity and non-repudiation of information processed in sensitive **API's (message sign requirement is indicated at API´s documentation/swagger)**, which includes:
-  * Header (_JSON Object Signing and Encryption – JOSE Header_), which defines the algorithm used and includes information about the public key or certificate that can be used to validate the signature;
-  * Payload (_JWS Payload_): content itself as detailed in the API specification;
-  * Digital signature (_JWS Signature_): digital signature, performed according to header parameters.
-2. Each of elements above must be encoded using the Base64url pattern [RFC4648](https://tools.ietf.org/html/rfc4648#section-5) and the elements must be concatenated with “.” (JWS Compact Serialization method as defined in [RFC7515]).
+1. Para garantir a integridade e o não-repúdio das informações tramitadas em **API´s sensíveis e que indicam essa necessidade na sua documentação**, deve ser adotado a estrutura no padrão JWS definida na [RFC7515] e que inclui:
+   * Cabeçalho (_JSON Object Signing and Encryption – JOSE Header_), onde se define o algoritmo utilizado e inclui informações sobre a chave pública ou certificado que podem ser utilizadas para validar a assinatura;
+   * Payload (_JWS Payload_): conteúdo propriamente dito e detalhado na especificação da API;
+   * Assinatura digital (_JWS Signature_): assinatura digital, realizada conforme parâmetros do cabeçalho.
+2. Cada elemento acima deve ser codificado utilizando o padrão Base64url [RFC4648](https://tools.ietf.org/html/rfc4648#section-5) e, feito isso, os elementos devem ser concatenados com “.” (método JWS Compact Serialization, conforme definido na [RFC7515]).
 
-3. The payload of signed messages (request _JWT_ and response _JWT_) shall include the following claims as defined at [RFC7519] (JWT):
-  * **aud** (in the _JWT_ request): the Resource Provider (eg the institution holding the account) must validate if the value of the **aud** field matches the endpoint being triggered;
-   * **aud** (in _JWT_ response): the API client (eg initiating institution) shall validate if the value of the **aud** field matches its own `organisationId` listed in the directory;
-   * **iss** (in the _JWT_ request and in the _JWT_ response): the receiver of the message shall validate if the value of the **iss** field matches the `organisationId` of the sender;
-   * **jti** (in the _JWT_ request and in the _JWT_ response): the value of the **jti** field shall be filled with the UUID defined by the institution according to [RFC4122] version 4;
-   * **iat** (in the _JWT_ request and in the _JWT_ response): the **iat** field  shall be filled with the message generation time and according to the standard established in [RFC7519](https:// datatracker.ietf.org/doc/html/rfc7519#section-2) to the _NumericDate_ format.
+3. O payload das mensagens (requisição _JWT_ e resposta _JWT_) assinadas devem incluir as seguintes `claims` presentes na [RFC7519] (JWT):
+   * **aud** (na requisição _JWT_): o Provedor do Recurso (p. ex. a instituição detentora da conta) deverá validar se o valor do campo **aud** coincide com o endpoint sendo acionado;
+   * **aud** (na resposta _JWT_): o cliente da API (p. e. instituição iniciadora) deverá validar se o valor do campo **aud** coincide com o seu próprio `organisationId` listado no diretório;
+   * **iss** (na requisição _JWT_ e na resposta _JWT_): o receptor da mensagem deverá validar se o valor do campo **iss** coincide com o `organisationId` do emissor;
+   * **jti** (na requisição _JWT_ e na resposta _JWT_): o valor do campo **jti** deverá ser preenchido com o UUID definido pela instituição de acordo com a [RFC4122] usando o versão 4;
+   * **iat** (na requisição _JWT_ e na resposta _JWT_): o valor do campo **iat** deverá ser preenchido com horário da geração da mensagem e de acordo com o padrão  estabelecido na [RFC7519](https://datatracker.ietf.org/doc/html/rfc7519#section-2) para o formato _NumericDate_.
 
-4. The HTTP content-type of requests and responses with JWS messages shall be defined as: "application/jwt".
+4. O content-type HTTP das requisições e respostas com mensagens JWS deve ser definido como: "application/jwt".
 
-5. The JOSE header must contain the following attributes:
-   * **alg** - shall be filled with the value `PS256`";
-   * **kid** - shall be filled with the key identifier value used for the signature;
-   * **typ** - shall be filled with the value `JWT`.
+5. No cabeçalho JOSE deve constar os seguintes atributos:
+   * **alg** - deve ser preenchido com o valor `PS256`";
+   * **kid** - deve ser obrigatoriamente preenchido com o valor do identificador da chave utilizado para a assinatura;
+   * **typ** - deve ser preenchido com o valor `JWT`.
 
-* In case of error in signature validation by `Resource Provider` the API provider shall return HTTP error message with `status code` **400** and the `ResponseError` content shall include, in the `code` property, the content `BAD_SIGNATURE`.
-* Errors in validating the signed messages received by the client application (eg payment initiator) must be logged and the `Resource Provider` (eg account holding institution) must be notified.
+* Em caso de erro na validação da assinatura pelo `Provedor do Recurso` a API deve retornar mensagem de erro HTTP com `status code` **400** e a resposta deve incluir na propriedade `code` do objeto de resposta de erro especificado na API (`ResponseError`) a indicação da falha com o conteúdo `BAD_SIGNATURE`.
+* Erros na validação da mensagem recebida pela aplicação cliente (p. ex. iniciador de pagamento) devem ser registrados e o `Provedor do Recurso` (p. ex. instituição detentora de conta) deve ser notificado.
 
-6. The receiver shall validate the consistency of the JWS message's digital signature **exclusively based on the information obtained from the directory**, that is, based on the keys published in the institution's JWKS in the directory.
+6. O receptor  deve validar a consistência da assinatura digital da mensagem JWS **exclusivamente com base nas informações obtidas do diretório**, ou seja, com base nas chaves publicadas no JWKS da instituição no diretório.
 
-7. Signatures must be performed using the digital signature certificate specified in the [Open Banking Brazil Certificates Standard](https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil -certificate-standards-1_ID1-ptbr.md#certificate-of-signing-certificatesignature).
+7. As assinaturas devem ser realizadas com uso do certificado digital de assinatura especificado no [Padrão de Certificados Open Banking Brasil](https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-certificate-standards-1_ID1-ptbr.md#certificado-de-assinatura-certificadoassinatura).
 
-## Algorithm considerations
+### Considerações sobre algoritmos de assinatura {#alg}
 
-For JWS, both clients and Authorization Servers
+Para JWS, clientes e servidores de autorização
 
-1. shall use PS256 algorithm;
+1. devem usar o algoritmo PS256;
 
-### Encryption algorithm considerations
+### Considerações de algoritmo de criptografia  {#cipher}
 
-For JWE, both clients and Authorization Servers
+Para JWE, clientes e servidores de autorização
 
-1. shall use RSA-OAEP with A256GCM
+1. devem usar RSA-OAEP com A256GCM
 
-### Secure Use of Transport Layer Security considerations
+### Considerações sobre o uso seguro do Transport Layer Security  {#tls}
 
-For TLS, Authorization Server endpoints and Resource Server endpoints used directly by the Client
+Para TLS, endpoints do Servidor de Autenticação e endpoints do Servidor de Recursos usados diretamente pelo cliente:
 
-1. shall support `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
-2. shall support `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
+1. devem suportar `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
+2. devem suportar `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
 
-# Data Sharing Considerations
+# Considerações sobre compartilhamento de dados  {#dados}
 
-## Authorisation Mechanism
+## Mecanismo de Autorização  {#authmech}
 
-### Introduction
+### Introdução  {#authmechintro}
 
-Existing mechanisms for appropriately managing access to resources defined in [RFC6749] are insufficient to meet the requirements for a modern data sharing ecosystem. Leveraging static scope strings does not provide consumers control of sufficient granularity to share with third parties. Open Banking Brasil have elected to implement a [Consent API](https://openbanking-brasil.github.io/areadesenvolvedor/swagger/swagger_consents_apis.yaml) as a OAuth 2.0 protected resource that can be used to manage fine grain access to resources. The reference to the Consent Resource will be conveyed as part of an OAuth 2.0 dynamic resource scope.
+Os mecanismos existentes para gerenciar adequadamente o acesso aos recursos definidos em [RFC6749] são insuficientes para atender aos requisitos de um ecossistema de compartilhamento de dados moderno. Aproveitar strings de escopo estático não fornece aos consumidores controle de granularidade suficiente para compartilhar com terceiros. O Open Banking Brasil optou por implementar uma [API de consentimento](https://openbanking-brasil.github.io/areadesenvolvedor/swagger/swagger_consents_apis.yaml) como um recurso protegido OAuth 2.0 que pode ser usado para gerenciar o acesso granular aos recursos. A referência ao recurso de consentimento será transmitida como parte de um escopo de recurso dinâmico OAuth 2.0.
 
-### Dynamic Consent Scope Definition
+### Definição de Escopo de Consentimento Dinâmico  {#consent}
 
-This profile defines OAuth 2.0 dynamic scope "consent" as follows:
+Este perfil define o escopo dinâmico do OAuth 2.0 "consentimento" da seguinte maneira:
 
-* string 'consent'; and
-* delimiter of a colon ":"; and
-* Consent API REST Resource Id as returned by a successful creation of [Open Banking Consent Resource](https://openbanking-brasil.github.io/areadesenvolvedor/#fase-2-apis-do-open-banking-brasil-api-consentimento);
+* string 'consent'; e
+* delimitador de dois pontos ":"; e
+* Consent API REST Resource Id retornado por uma criação bem-sucedida de [Open Banking Consent Resource](https://openbanking-brasil.github.io/areadesenvolvedor/#fase-2-apis-do-open-banking-brasil-api-consentimento);
 
-In addition:
+Adicionalmente:
 
-* the Consent Resource Id must include url safe characters only;
-* the Consent Resource Id must be namespaced;
-* the Consent Resource Id must have the properties of a nonce;
+* Consent Resource Id deve incluir caracteres seguros para url;
+* Consent Resource Id deve ser "namespaced";
+* Consent Resource Id deve ter propriedades de um `nonce` [Nonce](https://openid.net/specs/openid-connect-core-1_0.html#NonceNotes);
+
+### Dynamic Consent Scope Example  {#consentexample}
+
+consent:urn:bancoex:C1DD33123
 
-### Dynamic Consent Scope Example
+### Exemplo de escopo de consentimento dinâmico  {#consentid}
 
 consent:urn:bancoex:C1DD33123
 
-## Authorisation Life Cycle
+## Ciclo de vida da autorização  {#lifecycle}
 
-### Introduction
+### Introdução  {#lifecycleintro}
 
-The Consent Resource has a life cycle that is managed seperately and distinctly from the OAuth 2.0 Authorisation Framework. The state transitions and expected behaviours and error conditions expected of REST Resources protected with this profile are defined in the functional API specifications published by Open Banking Brasil.
+O recurso de consentimento tem um ciclo de vida gerenciado separada e distintamente da estrutura de autorização OAuth 2.0. As transições de estado e comportamentos esperados e condições de erro esperados dos Recursos REST protegidos com este perfil são definidos nas especificações funcionais da API publicadas pelo Open Banking Brasil.
 
-### Authorization server
+### Servidor de autorização  {#lifecycleauth}
 
-In addition to the requirements outlined in Open Banking Brasil security provisions the Authorization Server
+Além dos requisitos descritos nas disposições de segurança do Open Banking Brasil, o Servidor de Autorização
 
-1. shall only issue tokens on presentation of a refresh token when the consent resource the refresh token is bound to is active and valid;
-2. shall only share access to resources when presented with an access token linked to an active and valid consent;
-3. shall revoke refresh tokens and where practicable access tokens when the linked Consent Resource is deleted;
-4. shall ensure Access Tokens are issued with sufficient scope necessary for access to data specified in the Permissions element of a linked Consent Resource object;
-5. shall not reject an authorisation request requesting more scope than is necessary to access data specified in the Permissions element of a linked Consent Resource object;
-6. may reduce requested scope to a level sufficient to enable access to data resources specified in the Permissions element of a linked Consent Resource object;
-7. shall retain a complete audit history of the consent resource in accordance with current Central Bank brazilian regulation;
-8. shall return authentication failure and return code _access_denied_ in the _error_ parameter (as specified in section 4.1.2.1 of [RFC6749]) if the CPF of the authenticated user is not the same as indicated in the _loggedUser_ element of the Consent Resource Object;
-9. shall return authentication failure and return code _access_denied_ in the _error_ parameter (as specified in section 4.1.2.1 of [RFC6749]) if the _businessEntity_ element has not been populated in the related Consent Resource Object and the user has selected or authenticated by using a credential related to a business account;
-10. an autenticated or selected business account´s CNPJ must match the value present in the _businessEntity_ element of the Consent Resource Object. In case of divergence authorization server shall return authentication failure and return code _access_denied_ in the _error_ parameter (as specified in section 4.1.2.1 of [RFC6749]);
-11. shall ensure _refresh_tokens_ expiration time is at least equal to the linked consent resource expiration time.
+1. deve apenas emitir _refresh_tokens_ quando vinculados a um consentimento ativo e válido;
+2. só deve compartilhar o acesso aos recursos quando apresentado _access_token_ vinculado a um consentimento ativo e válido;
+3. deve revogar os _refresh tokens_ e, quando aplicável, os _access tokens_ quando o Consentimento (Consent Resource) relacionado for apagado;
+4. deve garantir que os _access tokens_ são emitidos com os _scopes_ necessários para permitir acesso aos dados especificados em elemento _Permission_ do Consentimento (Consent Resource Object) relacionado;
+5. não deve rejeitar pedido de autorização com _scopes_ além do necessário para permitir acesso a dados definidos em elemento _Permission_ do Consentimento (Consent Resource Object) relacionado;
+6. pode reduzir o escopo solicitado para um nível que seja suficiente para permitir o acesso aos dados definidos em elemento _Permission_ do Consentimento (Consent Resource Object) relacionado;
+7. deve manter registros sobre o histórico dos consentimento para permitir a adequada formação de trilhas de auditoria em conformidade com a regulação em vigor;
+8. deve retornar falha na autenticação e o código de retorno _access_denied_ no parâmetro _erro_ (como especificado na seção 4.1.2.1 da [RFC6749]) caso o CPF do usuário autenticado não seja o mesmo indicado no elemento _loggedUser_ do Consentimento (Consent Resource Object);
+9. deve retornar falha na autenticação e o código de retorno _access_denied_ no parâmetro _erro_ (como especificado na seção 4.1.2.1 da [RFC6749]) caso o elemento _businessEntity_ não tenha sido preenchido no Consentimento (Consent Resource Object) relacionado e o usuário tenha selecionado ou se autenticado por meio de credencial relacionada à conta do tipo Pessoa Jurídica (PJ);
+10. deve condicionar a autenticação ou seleção de contas do tipo PJ à consistência entre o CNPJ relacionado à(s) conta(s) e o valor presente no elemento _businessEntity_ do Consentimento (Consent Resource Object). Em caso de divergência deve retornar falha na autenticação e o código de retorno _access_denied_ no parâmetro _erro_ (como especificado na seção 4.1.2.1 da [RFC6749]);
+11. deve emitir _refresh_token_ com validade não inferior à validade do consentimento ao qual está relacionado, respeitado os demais critérios acima.
 
-### Confidential Client
+### Cliente confidencial  {#clientconfidential}
 
-In addition to the requirements outlined in Open Banking Brasil security provisions the Confidential Client
+Além dos requisitos descritos nas disposições de segurança do Open Banking Brasil, o Cliente Confidencial
 
-1. shall revoke where possible and cease usage of refresh and access tokens that are bound to a Consent Resource that has been deleted;
-1. shall delete Consent Resource that are expired;
+1. deve, sempre que possível, revogar e cessar o uso de _refresh_ e de _access tokens_  vinculados a um consentimento (Consent Resource Object) que foi excluído;
+2. deve excluir consentimentos (Consent Resource Objects) que estão expirados;
 
-# Acknowledgements
+# Reconhecimentos  {#acknowledgement}
 
-With thanks to all who have set the foundations for secure and safe data sharing through the formation of the OpenID Foundation FAPI Working Group, the Open Banking Brasil GT Security and to the pioneers who will stand on their shoulders.
+Agradecemos a todos que estabeleceram as bases para o compartilhamento seguro e seguro de dados por meio da formação do Grupo de Trabalho FAPI da OpenID Foundation, o GT de Segurança do Open Banking Brasil e aos pioneiros que ficarão em seus ombros.
 
-The following people contributed to this document:
+As seguintes pessoas contribuíram para este documento:
 
 * Ralph Bragg (Raidiam)
 * Joseph Heenan (Authlete)
@@ -449,10 +436,10 @@ The following people contributed to this document:
 
 {backmatter}
 
-# Notices
+# Avisos  {#disclaimer}
 
-Copyright (c) 2021 Open Banking Brasil Initial Structure.
+Copyright (c) 2021 Estrutura Inicial do Open Banking Brasil
 
-The Open Banking Brasil Initial Structure (OBBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OBBIS as the source of the material, but that such attribution does not indicate an endorsement by the OBBIS.
+A Estrutura Inicial do Open Banking Brasil (EIOBB) concede a qualquer Colaborador, desenvolvedor, implementador ou outra parte interessada uma licença de direitos autorais mundial não exclusiva, livre de royalties para reproduzir, preparar trabalhos derivados, distribuir, executar e exibir, estes Implementadores Rascunho ou Especificação Final exclusivamente para fins de (i) desenvolver especificações e (ii) implementar Rascunhos de Implementadores e Especificações Finais com base em tais documentos, desde que a atribuição seja feita ao EIOBB como a fonte do material, mas que tal atribuição o faça não indica endosso do EIOBB.
 
-The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation, the Open Banking Brasil GT Security Working Group and others. Although the Open Banking Brasil Initial Structure has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The Open Banking Brasil Initial Structure and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The Open Banking Brasil Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The Open Banking Brasil Initial Structure invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.
+A tecnologia descrita nesta especificação foi disponibilizada a partir de contribuições de várias fontes, incluindo membros da OpenID Foundation, do Grupo de Trabalho de Segurança do Open Banking Brasil e outros. Embora a Estrutura Inicial do Open Banking Brasil tenha tomado medidas para ajudar a garantir que a tecnologia esteja disponível para distribuição, ela não toma posição quanto à validade ou escopo de qualquer propriedade intelectual ou outros direitos que possam ser reivindicados como pertencentes à implementação ou uso do tecnologia descrita nesta especificação ou até que ponto qualquer licença sob tais direitos pode ou não estar disponível; nem representa que fez qualquer esforço independente para identificar tais direitos. A Estrutura Inicial do Open Banking Brasil e os contribuidores desta especificação não oferecem (e por meio deste expressamente se isentam de quaisquer) garantias (expressas, implícitas ou de outra forma), incluindo garantias implícitas de comercialização, não violação, adequação a uma finalidade específica ou título, relacionados a esta especificação, e todo o risco quanto à implementação desta especificação é assumido pelo implementador. A política de Direitos de Propriedade Intelectual do Open Banking Brasil exige que os contribuidores ofereçam uma promessa de patente de não fazer valer certas reivindicações de patentes contra outros contribuidores e implementadores. A Estrutura Inicial do Open Banking Brasil convida qualquer parte interessada a trazer à sua atenção quaisquer direitos autorais, patentes, pedidos de patentes ou outros direitos de propriedade que possam abranger a tecnologia que possa ser necessária para praticar esta especificação.
\ No newline at end of file
diff --git a/open-banking-brasil-financial-api-1_ID3.md b/open-banking-brasil-financial-api-1_ID3.md
index ff7bff6..d7ab44c 100644
--- a/open-banking-brasil-financial-api-1_ID3.md
+++ b/open-banking-brasil-financial-api-1_ID3.md
@@ -226,10 +226,11 @@ In addition, the Authorization Server
 10. may support [Financial-grade API: Client Initiated Backchannel Authentication Profile][FAPI-CIBA]
 11. (withdrawn)
 12. shall support refresh tokens
-13. shall issue access tokens with an expiry no greater than 900 seconds and no less than 300 seconds
-14. shall always include an acr claim in the `id_token`
-15. shall support the `response_type` value `code id_token`
-16. may support `response_type` value `code` in conjunction with the `response_mode` value `jwt`
+13. shall not allow `refresh tokens` rotation feature
+14. shall issue access tokens with an expiry no greater than 900 seconds and no less than 300 seconds
+15. shall always include an acr claim in the `id_token`
+16. shall support the `response_type` value `code id_token`
+17. may support `response_type` value `code` in conjunction with the `response_mode` value `jwt`
 
 
 #### ID Token as detached signature
@@ -319,9 +320,10 @@ In addition, the confidential client
 3. shall use _encrypted_ request objects if not using [PAR]
 4. shall support parameterized OAuth 2.0 resource scope _consent_ as defined in clause 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP]
 5. shall support refresh tokens
-6. shall not populate the `acr` claim with required values
-7. shall require the `acr` claim as an essential claim
-8. shall support all authentication methods specified in clause 5.2.2-14 of [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] including diferent combinations of the methods to send requests (using [PAR] or not - item 11).
+6. shall not allow `refresh tokens` rotation feature
+7. shall not populate the `acr` claim with required values
+8. shall require the `acr` claim as an essential claim
+9. shall support all authentication methods specified in clause 5.2.2-14 of [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] including diferent combinations of the methods to send requests (using [PAR] or not - item 11).
 
 # Security considerations
 
@@ -453,4 +455,4 @@ Copyright (c) 2021 Open Banking Brasil Initial Structure.
 
 The Open Banking Brasil Initial Structure (OBBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OBBIS as the source of the material, but that such attribution does not indicate an endorsement by the OBBIS.
 
-The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation, the Open Banking Brasil GT Security Working Group and others. Although the Open Banking Brasil Initial Structure has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The Open Banking Brasil Initial Structure and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The Open Banking Brasil Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The Open Banking Brasil Initial Structure invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.
+The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation, the Open Banking Brasil GT Security Working Group and others. Although the Open Banking Brasil Initial Structure has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The Open Banking Brasil Initial Structure and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The Open Banking Brasil Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The Open Banking Brasil Initial Structure invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.
\ No newline at end of file

From c065015dd11d535e6c686a19c9cb81bc619bcda4 Mon Sep 17 00:00:00 2001
From: Alexandre Daniel Dalabrida <alexandre.dalabrida@ailos.coop.br>
Date: Tue, 16 Nov 2021 17:26:51 -0300
Subject: [PATCH 40/59] =?UTF-8?q?Ajuste=20da=20posi=C3=A7=C3=A3o=20dos=20n?=
 =?UTF-8?q?ovos=20itens=20sobre=20rota=C3=A7=C3=A3o=20do=20refresh=20token?=
 =?UTF-8?q?=20para=20o=20final=20da=20lista=20e=20ajuste=20na=20pontua?=
 =?UTF-8?q?=C3=A7=C3=A3o?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...banking-brasil-financial-api-1_ID3-ptbr.md | 52 +++++++++----------
 open-banking-brasil-financial-api-1_ID3.md    | 51 +++++++++---------
 2 files changed, 51 insertions(+), 52 deletions(-)

diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.md b/open-banking-brasil-financial-api-1_ID3-ptbr.md
index 093caf0..eb94639 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.md
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.md
@@ -215,23 +215,23 @@ O Servidor de Autorização **deve** suportar as disposições especificadas na
 
 Além disso, ele deve:
 
-1. deve suportar Request Objects JWE assinados e criptografados passados por valor ou deve exigir requisições do tipo "pushed authorization requests" [PAR]
-2. deve publicar metadados de descoberta (incluindo a do endpoint de autorização) por meio do documento de metadado especificado em [OIDD] e [RFC8414] (".well-known")
-3. deve suportar os parâmetros `claims` como definido no item 5.5 do [OpenID Connect Core][OIDC]
-4. deve suportar o atributo `claim` padrão oidc "cpf" conforme definido no item 5.2.2.2 deste documento
-5. deve suportar o atributo `claim` padrão oidc "cnpj" conforme definido no item 5.2.2.3 deste documento, se a instituição for detentora de conta para pessoas jurídicas
-6. deve suportar o atributo `acr` "urn:brasil:openbanking:loa2" como definido no item 5.2.2.4 deste documento
-7. deveria suportar o atributo `acr` "urn:brasil:openbanking:loa3" como definido no item 5.2.2.4 deste documento
-8. deve implementar o endpoint "userinfo" como definido no item 5.3 do [OpenID Connect Core][OIDC]
-9. deve suportar o escopo parametrizável ("parameterized OAuth 2.0 resource scope") _consent_ como definido no item 6.3.1 de [OIDF FAPI WG Lodging Intent Pattern][LIWP]
-10. pode suportar [Financial-grade API: Client Initiated Backchannel Authentication Profile][FAPI-CIBA]
-11. (requisito temporariamente retirado)
-12. deve suportar `refresh tokens`
-13. não deve permitir o recurso de rotação de `refresh tokens`
-14. deve emitir `access tokens` com o tempo de expiração entre 300 (mínimo) e 900 (máximo) segundos
-15. deve sempre incluir a claim `acr` no id_token
-16. deve suportar os valores `code` e `id_token` para o atributo `response_type`
-17. pode suportar o valor `code` para o atributo `response_type`em conjunto com o valor `jwt` para o atributo `response_mode`
+1. deve suportar Request Objects JWE assinados e criptografados passados por valor ou deve exigir requisições do tipo "pushed authorization requests" [PAR];
+2. deve publicar metadados de descoberta (incluindo a do endpoint de autorização) por meio do documento de metadado especificado em [OIDD] e [RFC8414] (".well-known");
+3. deve suportar os parâmetros `claims` como definido no item 5.5 do [OpenID Connect Core][OIDC];
+4. deve suportar o atributo `claim` padrão oidc "cpf" conforme definido no item 5.2.2.2 deste documento;
+5. deve suportar o atributo `claim` padrão oidc "cnpj" conforme definido no item 5.2.2.3 deste documento, se a instituição for detentora de conta para pessoas jurídicas;
+6. deve suportar o atributo `acr` "urn:brasil:openbanking:loa2" como definido no item 5.2.2.4 deste documento;
+7. deveria suportar o atributo `acr` "urn:brasil:openbanking:loa3" como definido no item 5.2.2.4 deste documento;
+8. deve implementar o endpoint "userinfo" como definido no item 5.3 do [OpenID Connect Core][OIDC];
+9. deve suportar o escopo parametrizável ("parameterized OAuth 2.0 resource scope") _consent_ como definido no item 6.3.1 de [OIDF FAPI WG Lodging Intent Pattern][LIWP];
+10. pode suportar [Financial-grade API: Client Initiated Backchannel Authentication Profile][FAPI-CIBA];
+11. (requisito temporariamente retirado);
+12. deve suportar `refresh tokens`;
+13. deve emitir `access tokens` com o tempo de expiração entre 300 (mínimo) e 900 (máximo) segundos;
+14. deve sempre incluir a claim `acr` no id_token;
+15. deve suportar os valores `code` e `id_token` para o atributo `response_type`;
+16. pode suportar o valor `code` para o atributo `response_type`em conjunto com o valor `jwt` para o atributo `response_mode`;
+17. não deve permitir o recurso de rotação de `refresh tokens`.
 
 #### Token de ID como assinatura separada  {#detached}
 
@@ -301,15 +301,15 @@ Um cliente confidencial deve apoiar as disposições especificadas na cláusula
 
 Além disso, o cliente confidencial
 
-1. deve suportar objetos de solicitação _encrypted_
-2. deve suportar solicitações de autorização push (pushed authorization requests) [PAR]
-3. deve usar objetos de solicitação _encrypted_ se não usar [PAR]
-4. deve suportar o escopo de recurso OAuth 2.0 parametrizado _consent_ conforme definido na cláusula 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP]
-5. deve suportar `refresh tokens`
-6. não deve permitir o recurso de rotação de `refresh tokens`
-7. não deve incluir um valor específico na _claim_ `acr`
-8. deve definir a _claim_ `acr`como _essential_
-9. deve suportar todos os métodos de autenticação especificados no item 14 da seção 5.2.2 da [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] incluindo as diferentes combinações de métodos de encaminhamento dos Requests Objects (usando ou não [PAR] - item 11).
+1. deve suportar objetos de solicitação _encrypted_;
+2. deve suportar solicitações de autorização push (pushed authorization requests) [PAR];
+3. deve usar objetos de solicitação _encrypted_ se não usar [PAR];
+4. deve suportar o escopo de recurso OAuth 2.0 parametrizado _consent_ conforme definido na cláusula 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP];
+5. deve suportar `refresh tokens`;
+6. não deve incluir um valor específico na _claim_ `acr`;
+7. deve definir a _claim_ `acr`como _essential_;
+8. deve suportar todos os métodos de autenticação especificados no item 14 da seção 5.2.2 da [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] incluindo as diferentes combinações de métodos de encaminhamento dos Requests Objects (usando ou não [PAR] - item 11);
+9. não deve permitir o recurso de rotação de `refresh tokens`.
 
 # Considerações de segurança  {#authserver}
 
diff --git a/open-banking-brasil-financial-api-1_ID3.md b/open-banking-brasil-financial-api-1_ID3.md
index d7ab44c..2407a13 100644
--- a/open-banking-brasil-financial-api-1_ID3.md
+++ b/open-banking-brasil-financial-api-1_ID3.md
@@ -215,23 +215,22 @@ The Authorization Server shall support the provisions specified in clause 5.2.2
 In addition, the Authorization Server
 
 1. shall support a signed and encrypted JWE request object passed by value or shall require pushed authorization requests [PAR];
-2. shall distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in [OIDD] and [RFC8414]
-3. shall support the claims parameter as defined in clause 5.5 [OpenID Connect Core][OIDC]
-4. shall support the oidc standard claim "cpf" as defined in clause 5.2.2.2 of this document
-5. shall support the oidc standard claim "cnpj" as defined in clause 5.2.2.3 of this document if providing access to resources where the resource owner is not a `natural person`
-6. shall support the acr "urn:brasil:openbanking:loa2" as defined in clause 5.2.2.4 of this document
-7. should support the acr "urn:brasil:openbanking:loa3" as defined in clause 5.2.2.4 of this document
-8. shall implement the userinfo endpoint as defined in clause 5.3 [OpenID Connect Core][OIDC]
-9. shall support parameterized OAuth 2.0 resource scope _consent_ as defined in clause 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP]
-10. may support [Financial-grade API: Client Initiated Backchannel Authentication Profile][FAPI-CIBA]
-11. (withdrawn)
-12. shall support refresh tokens
-13. shall not allow `refresh tokens` rotation feature
-14. shall issue access tokens with an expiry no greater than 900 seconds and no less than 300 seconds
-15. shall always include an acr claim in the `id_token`
-16. shall support the `response_type` value `code id_token`
-17. may support `response_type` value `code` in conjunction with the `response_mode` value `jwt`
-
+2. shall distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in [OIDD] and [RFC8414];
+3. shall support the claims parameter as defined in clause 5.5 [OpenID Connect Core][OIDC];
+4. shall support the oidc standard claim "cpf" as defined in clause 5.2.2.2 of this document;
+5. shall support the oidc standard claim "cnpj" as defined in clause 5.2.2.3 of this document if providing access to resources where the resource owner is not a `natural person`;
+6. shall support the acr "urn:brasil:openbanking:loa2" as defined in clause 5.2.2.4 of this document;
+7. should support the acr "urn:brasil:openbanking:loa3" as defined in clause 5.2.2.4 of this document;
+8. shall implement the userinfo endpoint as defined in clause 5.3 [OpenID Connect Core][OIDC];
+9. shall support parameterized OAuth 2.0 resource scope _consent_ as defined in clause 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP];
+10. may support [Financial-grade API: Client Initiated Backchannel Authentication Profile][FAPI-CIBA];
+11. (withdrawn);
+12. shall support refresh tokens;
+13. shall issue access tokens with an expiry no greater than 900 seconds and no less than 300 seconds;
+14. shall always include an acr claim in the `id_token`;
+15. shall support the `response_type` value `code id_token`;
+16. may support `response_type` value `code` in conjunction with the `response_mode` value `jwt`;
+17. shall not allow `refresh tokens` rotation feature.
 
 #### ID Token as detached signature
 
@@ -315,15 +314,15 @@ A confidential client shall support the provisions specified in clause 5.2.3 of
 
 In addition, the confidential client
 
-1. shall support _encrypted_ request objects
-2. shall support Pushed Authorisation Requests [PAR]
-3. shall use _encrypted_ request objects if not using [PAR]
-4. shall support parameterized OAuth 2.0 resource scope _consent_ as defined in clause 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP]
-5. shall support refresh tokens
-6. shall not allow `refresh tokens` rotation feature
-7. shall not populate the `acr` claim with required values
-8. shall require the `acr` claim as an essential claim
-9. shall support all authentication methods specified in clause 5.2.2-14 of [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] including diferent combinations of the methods to send requests (using [PAR] or not - item 11).
+1. shall support _encrypted_ request objects;
+2. shall support Pushed Authorisation Requests [PAR];
+3. shall use _encrypted_ request objects if not using [PAR];
+4. shall support parameterized OAuth 2.0 resource scope _consent_ as defined in clause 6.3.1 [OIDF FAPI WG Lodging Intent Pattern][LIWP];
+5. shall support refresh tokens;
+6. shall not populate the `acr` claim with required values;
+7. shall require the `acr` claim as an essential claim;
+8. shall support all authentication methods specified in clause 5.2.2-14 of [Financial-grade API Security Profile 1.0 - Part 2: Advanced][FAPI-1-Advanced] including diferent combinations of the methods to send requests (using [PAR] or not - item 11);
+9. shall not allow `refresh tokens` rotation feature.
 
 # Security considerations
 

From 02b810f81cb45b7464ec5e1ad7875f3f2fe36494 Mon Sep 17 00:00:00 2001
From: JOAO RODOLFO <joao.rodolfo+github@gmail.com>
Date: Mon, 29 Nov 2021 23:21:44 -0300
Subject: [PATCH 41/59] Include a note into DCR/DCM to match PT-BR Doc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The PTBR DCR DCM doc has a sentence:

Observação: A [RFC7592] prevê a possibilidade de rotação do registration_access_token emitido pelo Servidor de Autorização a cada uso, tornando-o um token de uso único. As instituições devem considerar esse aspecto no registro de suas aplicações cliente para receber e atualizar o registration_access_token pelo novo valor recebido nas chamadas de manutenção de cliente.

It's just a translated version to adjust the docs:

Note: [RFC7592] provides the possibility of rotating the `registration_access_token` issued by the Authorization Server with each use, making it a single-use token. When registering their client applications, institutions should consider this aspect to receive and update the `registration_access_token` for the new value received in client maintenance (DCM) operations.

Fix Doc and Close #198
---
 open-banking-brasil-dynamic-client-registration-1_ID2.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.md b/open-banking-brasil-dynamic-client-registration-1_ID2.md
index 8995218..3bb7c93 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.md
@@ -458,6 +458,8 @@ To extend [RFC7591] and [RFC7592], which recommend minimum mechanisms for authen
 1. validate that the certificate presented by the client application is subordinate to the ICP-Brasil chains defined in the Open Banking Brasil Certificates Standard; 
 2. Validate the presence and matching of the Bearer header `Authorization` containing the value of the `registration_access_token` attribute returned during registration of the corresponding client. 
 
+Note: [RFC7592] provides the possibility of rotating the `registration_access_token` issued by the Authorization Server with each use, making it a single-use token. When registering their client applications, institutions should consider this aspect to receive and update the `registration_access_token` for the new value received in client maintenance (DCM) operations.
+
 # Acknowledgement
 
 With thanks to all who have set the foundations for secure and safe data sharing through the formation of the OpenID Foundation FAPI Working Group, the Open Banking Brasil GT Security and to the pioneers who will stand on their shoulders.

From eeef9cf53e004ad162770205ab929558a003b96a Mon Sep 17 00:00:00 2001
From: ediemerson-br <60996132+ediemerson-br@users.noreply.github.com>
Date: Tue, 30 Nov 2021 13:44:09 -0300
Subject: [PATCH 42/59] =?UTF-8?q?Atualiza=C3=A7=C3=A3o=20do=20item=206.1?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Conforme solicitado pelo GT
---
 open-banking-brasil-financial-api-1_ID3-ptbr.md | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.md b/open-banking-brasil-financial-api-1_ID3-ptbr.md
index 60701d4..4c60227 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.md
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.md
@@ -342,7 +342,11 @@ Os participantes devem apoiar todas as considerações de segurança especificad
 
 6. O receptor  deve validar a consistência da assinatura digital da mensagem JWS **exclusivamente com base nas informações obtidas do diretório**, ou seja, com base nas chaves publicadas no JWKS da instituição no diretório.
 
-7. As assinaturas devem ser realizadas com uso do certificado digital de assinatura especificado no [Padrão de Certificados Open Banking Brasil](https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-certificate-standards-1_ID1-ptbr.md#certificado-de-assinatura-certificadoassinatura).
+7. As assinaturas devem ser realizadas com uso do certificado digital de assinatura especificado no [Padrão de Certificados Open Banking Brasil](https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-certificate-standards-1_ID1-ptbr.md#certificado-de-assinatura-certificadoassinatura);
+
+8. A claim _iat_ deve ser numérica no formato Unix Time GMT+0 com tolerância de +/- 60 segundos;
+
+9. A claim do _jti_ deve ser única para um _clientId_ dentro de um intervalo de tempo de 86.400 segundos (24h), não podendo ser reutilizada neste período. Em caso de reutilização, deverá ser retornado o código de erro HTTP 40;
 
 ### Considerações sobre algoritmos de assinatura {#alg}
 
@@ -444,4 +448,4 @@ Copyright (c) 2021 Estrutura Inicial do Open Banking Brasil
 
 A Estrutura Inicial do Open Banking Brasil (EIOBB) concede a qualquer Colaborador, desenvolvedor, implementador ou outra parte interessada uma licença de direitos autorais mundial não exclusiva, livre de royalties para reproduzir, preparar trabalhos derivados, distribuir, executar e exibir, estes Implementadores Rascunho ou Especificação Final exclusivamente para fins de (i) desenvolver especificações e (ii) implementar Rascunhos de Implementadores e Especificações Finais com base em tais documentos, desde que a atribuição seja feita ao EIOBB como a fonte do material, mas que tal atribuição o faça não indica endosso do EIOBB.
 
-A tecnologia descrita nesta especificação foi disponibilizada a partir de contribuições de várias fontes, incluindo membros da OpenID Foundation, do Grupo de Trabalho de Segurança do Open Banking Brasil e outros. Embora a Estrutura Inicial do Open Banking Brasil tenha tomado medidas para ajudar a garantir que a tecnologia esteja disponível para distribuição, ela não toma posição quanto à validade ou escopo de qualquer propriedade intelectual ou outros direitos que possam ser reivindicados como pertencentes à implementação ou uso do tecnologia descrita nesta especificação ou até que ponto qualquer licença sob tais direitos pode ou não estar disponível; nem representa que fez qualquer esforço independente para identificar tais direitos. A Estrutura Inicial do Open Banking Brasil e os contribuidores desta especificação não oferecem (e por meio deste expressamente se isentam de quaisquer) garantias (expressas, implícitas ou de outra forma), incluindo garantias implícitas de comercialização, não violação, adequação a uma finalidade específica ou título, relacionados a esta especificação, e todo o risco quanto à implementação desta especificação é assumido pelo implementador. A política de Direitos de Propriedade Intelectual do Open Banking Brasil exige que os contribuidores ofereçam uma promessa de patente de não fazer valer certas reivindicações de patentes contra outros contribuidores e implementadores. A Estrutura Inicial do Open Banking Brasil convida qualquer parte interessada a trazer à sua atenção quaisquer direitos autorais, patentes, pedidos de patentes ou outros direitos de propriedade que possam abranger a tecnologia que possa ser necessária para praticar esta especificação.
\ No newline at end of file
+A tecnologia descrita nesta especificação foi disponibilizada a partir de contribuições de várias fontes, incluindo membros da OpenID Foundation, do Grupo de Trabalho de Segurança do Open Banking Brasil e outros. Embora a Estrutura Inicial do Open Banking Brasil tenha tomado medidas para ajudar a garantir que a tecnologia esteja disponível para distribuição, ela não toma posição quanto à validade ou escopo de qualquer propriedade intelectual ou outros direitos que possam ser reivindicados como pertencentes à implementação ou uso do tecnologia descrita nesta especificação ou até que ponto qualquer licença sob tais direitos pode ou não estar disponível; nem representa que fez qualquer esforço independente para identificar tais direitos. A Estrutura Inicial do Open Banking Brasil e os contribuidores desta especificação não oferecem (e por meio deste expressamente se isentam de quaisquer) garantias (expressas, implícitas ou de outra forma), incluindo garantias implícitas de comercialização, não violação, adequação a uma finalidade específica ou título, relacionados a esta especificação, e todo o risco quanto à implementação desta especificação é assumido pelo implementador. A política de Direitos de Propriedade Intelectual do Open Banking Brasil exige que os contribuidores ofereçam uma promessa de patente de não fazer valer certas reivindicações de patentes contra outros contribuidores e implementadores. A Estrutura Inicial do Open Banking Brasil convida qualquer parte interessada a trazer à sua atenção quaisquer direitos autorais, patentes, pedidos de patentes ou outros direitos de propriedade que possam abranger a tecnologia que possa ser necessária para praticar esta especificação.

From 6216ef16413c0b736a6c247e5ef85fe1cfe7897f Mon Sep 17 00:00:00 2001
From: ediemerson-br <60996132+ediemerson-br@users.noreply.github.com>
Date: Tue, 30 Nov 2021 13:46:05 -0300
Subject: [PATCH 43/59] =?UTF-8?q?Atualiza=C3=A7=C3=A3o=20do=20item=206.1?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Conforme solicitado pelo GT
---
 open-banking-brasil-financial-api-1_ID3.md | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/open-banking-brasil-financial-api-1_ID3.md b/open-banking-brasil-financial-api-1_ID3.md
index d1b963f..62ceb83 100644
--- a/open-banking-brasil-financial-api-1_ID3.md
+++ b/open-banking-brasil-financial-api-1_ID3.md
@@ -358,7 +358,11 @@ Participants shall support all security considerations specified in clause 8
 
 6. The receiver shall validate the consistency of the JWS message's digital signature **exclusively based on the information obtained from the directory**, that is, based on the keys published in the institution's JWKS in the directory.
 
-7. Signatures must be performed using the digital signature certificate specified in the [Open Banking Brazil Certificates Standard](https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil -certificate-standards-1_ID1-ptbr.md#certificate-of-signing-certificatesignature).
+7. Signatures must be performed using the digital signature certificate specified in the [Open Banking Brazil Certificates Standard](https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil -certificate-standards-1_ID1-ptbr.md#certificate-of-signing-certificatesignature);
+
+8. the _iat_ claim must be numeric in Unix Time format GMT+0 with a tolerance of +/- 60 seconds;
+
+9. the _jti_ claim must be unique for a _clientId_ within a time frame of 86,400 seconds (24h), and cannot be reused within this period. In case of reuse, the HTTP error code 403 shall be return.
 
 ## Algorithm considerations
 
@@ -456,4 +460,4 @@ Copyright (c) 2021 Open Banking Brasil Initial Structure.
 
 The Open Banking Brasil Initial Structure (OBBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OBBIS as the source of the material, but that such attribution does not indicate an endorsement by the OBBIS.
 
-The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation, the Open Banking Brasil GT Security Working Group and others. Although the Open Banking Brasil Initial Structure has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The Open Banking Brasil Initial Structure and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The Open Banking Brasil Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The Open Banking Brasil Initial Structure invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.
\ No newline at end of file
+The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation, the Open Banking Brasil GT Security Working Group and others. Although the Open Banking Brasil Initial Structure has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The Open Banking Brasil Initial Structure and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The Open Banking Brasil Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The Open Banking Brasil Initial Structure invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.

From f2393a380747662a8520f889a6ae5c12967dfe67 Mon Sep 17 00:00:00 2001
From: ediemerson-br <60996132+ediemerson-br@users.noreply.github.com>
Date: Tue, 30 Nov 2021 13:48:58 -0300
Subject: [PATCH 44/59] Update open-banking-brasil-financial-api-1_ID3-ptbr.md

---
 open-banking-brasil-financial-api-1_ID3-ptbr.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.md b/open-banking-brasil-financial-api-1_ID3-ptbr.md
index 4c60227..ce265d9 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.md
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.md
@@ -346,7 +346,7 @@ Os participantes devem apoiar todas as considerações de segurança especificad
 
 8. A claim _iat_ deve ser numérica no formato Unix Time GMT+0 com tolerância de +/- 60 segundos;
 
-9. A claim do _jti_ deve ser única para um _clientId_ dentro de um intervalo de tempo de 86.400 segundos (24h), não podendo ser reutilizada neste período. Em caso de reutilização, deverá ser retornado o código de erro HTTP 40;
+9. A claim do _jti_ deve ser única para um _clientId_ dentro de um intervalo de tempo de 86.400 segundos (24h), não podendo ser reutilizada neste período. Em caso de reutilização, deverá ser retornado o código de erro HTTP 403;
 
 ### Considerações sobre algoritmos de assinatura {#alg}
 

From 7cd10d6bc2814159414140b5b8312e17ea83c45e Mon Sep 17 00:00:00 2001
From: ediemerson-br <60996132+ediemerson-br@users.noreply.github.com>
Date: Tue, 30 Nov 2021 14:00:57 -0300
Subject: [PATCH 45/59] Update open-banking-brasil-financial-api-1_ID3-ptbr.md

---
 open-banking-brasil-financial-api-1_ID3-ptbr.md | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.md b/open-banking-brasil-financial-api-1_ID3-ptbr.md
index ce265d9..09214f5 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.md
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.md
@@ -417,9 +417,7 @@ Além dos requisitos descritos nas disposições de segurança do Open Banking B
 8. deve retornar falha na autenticação e o código de retorno _access_denied_ no parâmetro _erro_ (como especificado na seção 4.1.2.1 da [RFC6749]) caso o CPF do usuário autenticado não seja o mesmo indicado no elemento _loggedUser_ do Consentimento (Consent Resource Object);
 9. deve retornar falha na autenticação e o código de retorno _access_denied_ no parâmetro _erro_ (como especificado na seção 4.1.2.1 da [RFC6749]) caso o elemento _businessEntity_ não tenha sido preenchido no Consentimento (Consent Resource Object) relacionado e o usuário tenha selecionado ou se autenticado por meio de credencial relacionada à conta do tipo Pessoa Jurídica (PJ);
 10. deve condicionar a autenticação ou seleção de contas do tipo PJ à consistência entre o CNPJ relacionado à(s) conta(s) e o valor presente no elemento _businessEntity_ do Consentimento (Consent Resource Object). Em caso de divergência deve retornar falha na autenticação e o código de retorno _access_denied_ no parâmetro _erro_ (como especificado na seção 4.1.2.1 da [RFC6749]);
-11. deve emitir _refresh_token_ com validade não inferior à validade do consentimento ao qual está relacionado, respeitado os demais critérios acima;
-12. a claim _iat_ deve ser numérica no formato Unix Time GMT+0 com tolerância de +/- 60 segundos;
-13. A claim do _jti_ deve ser única para um _clientId_ dentro de um intervalo de tempo de 86.400 segundos (24h), não podendo ser reutilizada neste período. Em caso de reutilização, deverá ser retornado o código de erro HTTP 403.
+11. deve emitir _refresh_token_ com validade não inferior à validade do consentimento ao qual está relacionado, respeitado os demais critérios acima.
 
 ### Cliente confidencial  {#clientconfidential}
 

From cc2f07b67c6c678db4f1d38d22329bbb8ad59d70 Mon Sep 17 00:00:00 2001
From: ediemerson-br <60996132+ediemerson-br@users.noreply.github.com>
Date: Tue, 30 Nov 2021 14:05:33 -0300
Subject: [PATCH 46/59] Update open-banking-brasil-financial-api-1_ID3.md

---
 open-banking-brasil-financial-api-1_ID3.md | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/open-banking-brasil-financial-api-1_ID3.md b/open-banking-brasil-financial-api-1_ID3.md
index 62ceb83..15abbbd 100644
--- a/open-banking-brasil-financial-api-1_ID3.md
+++ b/open-banking-brasil-financial-api-1_ID3.md
@@ -429,9 +429,7 @@ In addition to the requirements outlined in Open Banking Brasil security provisi
 8. shall return authentication failure and return code _access_denied_ in the _error_ parameter (as specified in section 4.1.2.1 of [RFC6749]) if the CPF of the authenticated user is not the same as indicated in the _loggedUser_ element of the Consent Resource Object;
 9. shall return authentication failure and return code _access_denied_ in the _error_ parameter (as specified in section 4.1.2.1 of [RFC6749]) if the _businessEntity_ element has not been populated in the related Consent Resource Object and the user has selected or authenticated by using a credential related to a business account;
 10. an autenticated or selected business account´s CNPJ must match the value present in the _businessEntity_ element of the Consent Resource Object. In case of divergence authorization server shall return authentication failure and return code _access_denied_ in the _error_ parameter (as specified in section 4.1.2.1 of [RFC6749]);
-11. shall ensure _refresh_tokens_ expiration time is at least equal to the linked consent resource expiration time;
-12. the _iat_ claim must be numeric in Unix Time format GMT+0 with a tolerance of +/- 60 seconds;
-13. The _jti_ claim must be unique for a _clientId_ within a time frame of 86,400 seconds (24h), and cannot be reused within this period. In case of reuse, the HTTP error code 403 shall be returned.
+11. shall ensure _refresh_tokens_ expiration time is at least equal to the linked consent resource expiration time.
 
 ### Confidential Client
 

From effb0be2c3196efca942161bc391e1efa4aac489 Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Thu, 2 Dec 2021 09:02:44 -0300
Subject: [PATCH 47/59] =?UTF-8?q?Adicionado=20instru=C3=A7=C3=A3o=20para?=
 =?UTF-8?q?=20suporte=20a=20m=C3=BAltiplas=20marcas?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 aspsp-user-guide-ptbr.md | 1 +
 aspsp-user-guide.md      | 1 +
 2 files changed, 2 insertions(+)

diff --git a/aspsp-user-guide-ptbr.md b/aspsp-user-guide-ptbr.md
index 9718584..d77ca80 100644
--- a/aspsp-user-guide-ptbr.md
+++ b/aspsp-user-guide-ptbr.md
@@ -159,6 +159,7 @@ Um banco pode optar por ter um *Authorization Servers* ou muitos, desde que sati
 
 * Um cliente pode reconhecer o *Authorization Server* como um local com o qual normalmente faria interação com o seu banco.
 * O *Authorization Server* pode emitir tokens para os recursos e serviços que um cliente ou insituição receptora está procurando.
+* O *Authorization Server* das instituições transmissoras/detentoras de contas que atenda mais de uma marca deve aceitar mais de um cadastro (criação de client_ids) para um mesmo *software statement*. Caso a solução de *Authorization Server* não suporte este comportamento, deverá ser adequado para suportar múltiplas marcas e o cadastramento das marcas no diretório deverá sofrer apontamento de acordo com cada marca.
 
 ### 1.3 Registrando Recursos  {#Recursos}
 
diff --git a/aspsp-user-guide.md b/aspsp-user-guide.md
index 03827e3..094cbfb 100644
--- a/aspsp-user-guide.md
+++ b/aspsp-user-guide.md
@@ -175,6 +175,7 @@ A Bank may choose to have one Authorization Server or many provided that it can
 
 * A customer can recognise the Authorization Server as a place that they would normally Bank with.
 * The Authorization Server can issue tokens for the resource and services that a customer or TPP is looking for.
+* For transmiting/account holder institutions whose *Authorization Server* supports more than one brand, it must accept more than one registry (client_ids creation) for the same *software statement*. If your *Authorization Server* implementation does not supports this behaviour, it must be suitable to support multiple brands and the registration of brands in the directory must be annotated according to each brand. 
 
 ### 1.3 Registering Resources
 

From 74e961e8f8d6dd1b7193346f9bcb8c4ceba4deca Mon Sep 17 00:00:00 2001
From: Rafael Hashimoto <rafael.hashimoto@c6bank.com>
Date: Thu, 2 Dec 2021 10:57:26 -0300
Subject: [PATCH 48/59] =?UTF-8?q?Migrado=20item=203.4=20da=20IN=20134=20pa?=
 =?UTF-8?q?ra=20Perfil=20de=20Seguran=C3=A7a=20conforme=20consulta=20reali?=
 =?UTF-8?q?zada=20ao=20Bacen?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 open-banking-brasil-financial-api-1_ID3-ptbr.md | 1 +
 open-banking-brasil-financial-api-1_ID3.md      | 1 +
 2 files changed, 2 insertions(+)

diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.md b/open-banking-brasil-financial-api-1_ID3-ptbr.md
index 09214f5..6a8f80b 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.md
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.md
@@ -366,6 +366,7 @@ Para TLS, endpoints do Servidor de Autenticação e endpoints do Servidor de Rec
 
 1. devem suportar `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
 2. devem suportar `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
+3. As funcionalidades "TLS Session Resumption" e "TLS Renegotiation" devem ser desabilitadas
 
 # Considerações sobre compartilhamento de dados  {#dados}
 
diff --git a/open-banking-brasil-financial-api-1_ID3.md b/open-banking-brasil-financial-api-1_ID3.md
index 15abbbd..31f7c76 100644
--- a/open-banking-brasil-financial-api-1_ID3.md
+++ b/open-banking-brasil-financial-api-1_ID3.md
@@ -382,6 +382,7 @@ For TLS, Authorization Server endpoints and Resource Server endpoints used direc
 
 1. shall support `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
 2. shall support `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
+3. The "TLS Session Resumption" e "TLS Renegotiation" features shall be disabled
 
 # Data Sharing Considerations
 

From 286f1771777fb480ce23ec6eb32806c10a7417c8 Mon Sep 17 00:00:00 2001
From: JOAO RODOLFO <joao.rodolfo+github@gmail.com>
Date: Wed, 16 Feb 2022 23:46:07 -0300
Subject: [PATCH 49/59] =?UTF-8?q?Atualiza=C3=A7=C3=A3o=20de=20documentos?=
 =?UTF-8?q?=20aprovados=20no=20GTSeg.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Preve a atualização dos itens aprovados no GTSeg.
---
 open-banking-brasil-certificate-standards-1_ID1-ptbr.html | 8 ++++----
 open-banking-brasil-certificate-standards-1_ID1-ptbr.md   | 8 ++++----
 open-banking-brasil-certificate-standards-1_ID1.html      | 8 ++++----
 open-banking-brasil-certificate-standards-1_ID1.md        | 8 ++++----
 ...nking-brasil-dynamic-client-registration-1_ID2-ptbr.md | 4 ++++
 open-banking-brasil-dynamic-client-registration-1_ID2.md  | 2 ++
 6 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/open-banking-brasil-certificate-standards-1_ID1-ptbr.html b/open-banking-brasil-certificate-standards-1_ID1-ptbr.html
index 5b6f713..db92f72 100644
--- a/open-banking-brasil-certificate-standards-1_ID1-ptbr.html
+++ b/open-banking-brasil-certificate-standards-1_ID1-ptbr.html
@@ -1668,10 +1668,10 @@ <h3 id="name-modelo-de-configura231227o-d">
 keyUsage = critical,digitalSignature,nonRepudiation
 
 [ alt_name ]
-otherName.0 = 2.16.76.1.3.2;UTF8:&lt;Nome da pessoal responsável pela entidade&gt;#CNPJ
-otherName.1 = 2.16.76.1.3.3;UTF8:&lt;CNPJ&gt;
-otherName.2 = 2.16.76.1.3.4;UTF8:&lt;CPF/PIS/RF da Pessoa responsável&gt;
-otherName.3 = 2.16.76.1.3.7;UTF8:&lt;Número de INSS&gt;
+otherName.0 = 2.16.76.1.3.2;PRINTABLESTRING:&lt;Nome da pessoal responsável pela entidade&gt;#CNPJ
+otherName.1 = 2.16.76.1.3.3;PRINTABLESTRING:&lt;CNPJ&gt;
+otherName.2 = 2.16.76.1.3.4;PRINTABLESTRING:&lt;CPF/PIS/RF da Pessoa responsável&gt;
+otherName.3 = 2.16.76.1.3.7;PRINTABLESTRING:&lt;Número de INSS&gt;
 </pre><a href="#section-8.2-1" class="pilcrow">¶</a>
 </div>
 </section>
diff --git a/open-banking-brasil-certificate-standards-1_ID1-ptbr.md b/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
index cc5bb56..b08276f 100644
--- a/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
+++ b/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
@@ -317,10 +317,10 @@ subjectAltName = @alt_name
 keyUsage = critical,digitalSignature,nonRepudiation
 
 [ alt_name ]
-otherName.0 = 2.16.76.1.3.2;UTF8:<Nome da pessoal responsável pela entidade>#CNPJ
-otherName.1 = 2.16.76.1.3.3;UTF8:<CNPJ>
-otherName.2 = 2.16.76.1.3.4;UTF8:<CPF/PIS/RF da Pessoa responsável>
-otherName.3 = 2.16.76.1.3.7;UTF8:<Número de INSS>
+otherName.0 = 2.16.76.1.3.2;PRINTABLESTRING:<Nome da pessoal responsável pela entidade>#CNPJ
+otherName.1 = 2.16.76.1.3.3;PRINTABLESTRING:<CNPJ>
+otherName.2 = 2.16.76.1.3.4;PRINTABLESTRING:<CPF/PIS/RF da Pessoa responsável>
+otherName.3 = 2.16.76.1.3.7;PRINTABLESTRING:<Número de INSS>
 ```
 ## Tabela com Endpoints vs Tipo de Certificado e mTLS
 Abaixo apresentamos quais endpoints podem ser publicados utilizando certificado EV como autenticação do consentimento e os endpoints de autenticação de APIs privadas/negócios que devem ser publicadas usando certificado ICP. Você também poderá verificar quais endpoints devem proteger suas conexões utilizando mTLS.
diff --git a/open-banking-brasil-certificate-standards-1_ID1.html b/open-banking-brasil-certificate-standards-1_ID1.html
index 5f88368..4c928d9 100644
--- a/open-banking-brasil-certificate-standards-1_ID1.html
+++ b/open-banking-brasil-certificate-standards-1_ID1.html
@@ -1661,10 +1661,10 @@ <h3 id="name-configuration-template-for-s">
 keyUsage = critical,digitalSignature,nonRepudiation
 
 [ alt_name ]
-otherName.0 = 2.16.76.1.3.2;UTF8:&lt;Name of the person responsible for the organization&gt;
-otherName.1 = 2.16.76.1.3.3;UTF8:&lt;CNPJ&gt;
-otherName.2 = 2.16.76.1.3.4;UTF8:&lt;CPF/PIS/RF of responsible person&gt;
-otherName.3 = 2.16.76.1.3.7;UTF8:&lt;INSS Number&gt;
+otherName.0 = 2.16.76.1.3.2;PRINTABLESTRING:&lt;Name of the person responsible for the organization&gt;
+otherName.1 = 2.16.76.1.3.3;PRINTABLESTRING:&lt;CNPJ&gt;
+otherName.2 = 2.16.76.1.3.4;PRINTABLESTRING:&lt;CPF/PIS/RF of responsible person&gt;
+otherName.3 = 2.16.76.1.3.7;PRINTABLESTRING:&lt;INSS Number&gt;
 </pre><a href="#section-8.2-1" class="pilcrow">¶</a>
 </div>
 </section>
diff --git a/open-banking-brasil-certificate-standards-1_ID1.md b/open-banking-brasil-certificate-standards-1_ID1.md
index 93e3ac5..6c8203d 100644
--- a/open-banking-brasil-certificate-standards-1_ID1.md
+++ b/open-banking-brasil-certificate-standards-1_ID1.md
@@ -321,10 +321,10 @@ subjectAltName = @alt_name
 keyUsage = critical,digitalSignature,nonRepudiation
 
 [ alt_name ]
-otherName.0 = 2.16.76.1.3.2;UTF8:<Name of the person responsible for the organization>
-otherName.1 = 2.16.76.1.3.3;UTF8:<CNPJ>
-otherName.2 = 2.16.76.1.3.4;UTF8:<CPF/PIS/RF of responsible person>
-otherName.3 = 2.16.76.1.3.7;UTF8:<INSS Number>
+otherName.0 = 2.16.76.1.3.2;PRINTABLESTRING:<Name of the person responsible for the organization>
+otherName.1 = 2.16.76.1.3.3;PRINTABLESTRING:<CNPJ>
+otherName.2 = 2.16.76.1.3.4;PRINTABLESTRING:<CPF/PIS/RF of responsible person>
+otherName.3 = 2.16.76.1.3.7;PRINTABLESTRING:<INSS Number>
 ```
 
 ## Endpoints vs Certificate type and mTLS requirements
diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
index c34cbbf..5d82ba8 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
@@ -288,6 +288,8 @@ A tabela a seguir descreve as funções regulatórias do Open Banking e o mapeam
 | CONTA | Instituição detentora de conta (ASPSP) | openid | Phase 3 |
 | CCORR | Correspondente de crédito | openid | Phase 3* |
 
+É necessário validar as roles ativas no _software\_statement_ da aplicação. Na validação dessa informação deve ser utilizado o campo _software\_statement\_roles, e deve ser verificado se as roles listadas estão ativas.
+
 ## Registro do Cliente {#registro_tls_client_auth}
 
 No processo de registro do cliente, utilizando-se o método de autenticação _tls\_client\_auth_, o cliente deve encaminhar o campo _tls\_client\_auth\_subject\_dn_ com os AttibuteTypes(Descritores) em formato definido no item 7.1.2. Em caso de não aderencia a este padrão o registro será rejeitado.
@@ -296,6 +298,8 @@ No processo de registro do cliente, utilizando-se o método de autenticação _
 
 Uma declaração de software (_software\_statement_) é um JSON Web Token (JWT) [RFC7519] que afirma valores de metadados sobre o software cliente como um todo. Na estrutura do Open Banking Brasil, esse _software\_statement_ é assinado pelo Diretório de Participantes, e sua assinatura DEVE ser validada pelos Servidores de Autorizacao usando as chaves públicas disponíveis na seção a seguir.
 
+
+
 ## Atributos da Declaração de Software (Claims)  {#Claims}
 
 O exemplo a seguir contém todos os atributos atualmente incluídos em um _software\_statement_:
diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.md b/open-banking-brasil-dynamic-client-registration-1_ID2.md
index 3bb7c93..ebe73cd 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.md
@@ -284,6 +284,8 @@ The following table describes the regulatory roles for Open Banking and the rela
 | CONTA | Instituição detentora de conta (ASPSP) | openid | Phase 3 |
 | CCORR | Correspondente de crédito | openid | Phase 3* |
 
+Validate the active roles in the application's _software\_statement_. The information validation, shall use the field _software\_statement\_roles, and shall verify if their roles are actives.
+
 ### Implementers Note
 
 In line with guidance from the IETF and the direction of travel for fine-grained consent management. The obligation falls to the Authorisation Server to ensure that there is sufficient scope conveyed in an access token necessary to fulfill the Permissions conveyed in the Consent Request. This principle and requirement is reflected in the forthcoming Grant Management API.

From ced43a476f122376a2c3312d43f6e91fcc000aaa Mon Sep 17 00:00:00 2001
From: Nic <qbitnic@gmail.com>
Date: Thu, 17 Feb 2022 19:24:54 -0300
Subject: [PATCH 50/59] chore(md): Fix and export
 open-banking-brasil-certificate-standards-1_ID1.md

---
 ...ng-brasil-certificate-standards-1_ID1.html | 100 +++++++++---------
 ...king-brasil-certificate-standards-1_ID1.md |  92 +++++++---------
 2 files changed, 85 insertions(+), 107 deletions(-)

diff --git a/open-banking-brasil-certificate-standards-1_ID1.html b/open-banking-brasil-certificate-standards-1_ID1.html
index 4c928d9..5ddb384 100644
--- a/open-banking-brasil-certificate-standards-1_ID1.html
+++ b/open-banking-brasil-certificate-standards-1_ID1.html
@@ -5,8 +5,6 @@
 <meta content="Common,Latin" name="scripts">
 <meta content="initial-scale=1.0" name="viewport">
 <title>Open Banking Brasil Certificate Standards 1.0</title>
-<meta content="Marcos Rodrigues" name="author">
-<meta content="Jose Michael Dias" name="author">
 <meta content="GT Segurança" name="author">
 <meta content="xml2rfc 2.40.1" name="generator">
 <meta content="FAPI" name="keyword">
@@ -1070,10 +1068,10 @@
 <thead><tr>
 <td class="left"></td>
 <td class="center">OBB-CERT-1-ID1</td>
-<td class="right">September 2021</td>
+<td class="right">February 2022</td>
 </tr></thead>
 <tfoot><tr>
-<td class="left">Rodrigues, et al.</td>
+<td class="left">Segurança</td>
 <td class="center">Standards Track</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
@@ -1087,20 +1085,12 @@
 <dd class="internet-draft">open-banking-brasil-certificate-standards-1_ID1</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2021-09-27" class="published">27 September 2021</time>
+<time datetime="2022-02-17" class="published">17 February 2022</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Standards Track</dd>
-<dt class="label-authors">Authors:</dt>
+<dt class="label-authors">Author:</dt>
 <dd class="authors">
-<div class="author">
-      <div class="author-name">M. Rodrigues</div>
-<div class="org">Itau</div>
-</div>
-<div class="author">
-      <div class="author-name">J. Dias</div>
-<div class="org">Banco Pan</div>
-</div>
 <div class="author">
       <div class="author-name">GT. Segurança</div>
 <div class="org">EIOBB</div>
@@ -1109,35 +1099,36 @@
 </dl>
 </div>
 <h1 id="title">Open Banking Brasil Certificate Standards 1.0</h1>
-<div>
-<h1>The english version of this document is Outdated</h1>
-Please refer to the portuguese version for up to date information:<br>
-<a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html">https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html</a>
-</div>
 <section class="note" id="section-note.1">
+      <h2 id="name-the-english-version-of-this">
+<a href="#name-the-english-version-of-this" class="section-name selfRef">The English version of this document is Outdated</a>
+      </h2>
+<p id="section-note.1-1">Please refer to the <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1-ptbr.html">Portuguese version</a> for up to date information.<a href="#section-note.1-1" class="pilcrow">¶</a></p>
+</section>
+<section class="note" id="section-note.2">
       <h2 id="name-foreword">
 <a href="#name-foreword" class="section-name selfRef">Foreword</a>
       </h2>
-<p id="section-note.1-1">Este documento tamb&#233;m est&#225; dispon&#237;vel em <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1-ptbr.html">portugu&#234;s</a>.<a href="#section-note.1-1" class="pilcrow">¶</a></p>
-<p id="section-note.1-2">The Open Banking Brasil Initial Structure is responsible for creating standards and specifications necessary to meet the requirements and obligations of the Brasil Open Banking Legislation as originally outlined by the <a href="https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf">Brasil Central Bank</a>. There is a possibility that some of the elements of this document may be the subject to patent rights. OBBIS shall not be held responsible for identifying any or all such patent rights.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
+<p id="section-note.2-1">Este documento tamb&#233;m est&#225; dispon&#237;vel em <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1-ptbr.html">portugu&#234;s</a>.<a href="#section-note.2-1" class="pilcrow">¶</a></p>
+<p id="section-note.2-2">The Open Banking Brasil Initial Structure is responsible for creating standards and specifications necessary to meet the requirements and obligations of the Brasil Open Banking Legislation as originally outlined by the <a href="https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf">Brasil Central Bank</a>. There is a possibility that some of the elements of this document may be the subject to patent rights. OBBIS shall not be held responsible for identifying any or all such patent rights.<a href="#section-note.2-2" class="pilcrow">¶</a></p>
 </section>
-<section class="note" id="section-note.2">
+<section class="note" id="section-note.3">
       <h2 id="name-objective">
 <a href="#name-objective" class="section-name selfRef">Objective</a>
       </h2>
-<p id="section-note.2-1">Specify the set of necessary certificates that must be used by participating organizations in Open Banking Brasil to ensure interoperability for validation, confidentiality, integrity and non-repudiation among participants, as well as for users and consumers of these entities. The public in this class are entities participating in Open Banking Brasil that issue certificates to authenticate themselves with other entities, as well as offer their customers a secure authentication channel.<a href="#section-note.2-1" class="pilcrow">¶</a></p>
+<p id="section-note.3-1">Specify the set of necessary certificates that must be used by participating organizations in Open Banking Brasil to ensure interoperability for validation, confidentiality, integrity and non-repudiation among participants, as well as for users and consumers of these entities. The public in this class are entities participating in Open Banking Brasil that issue certificates to authenticate themselves with other entities, as well as offer their customers a secure authentication channel.<a href="#section-note.3-1" class="pilcrow">¶</a></p>
 </section>
-<section class="note" id="section-note.3">
+<section class="note" id="section-note.4">
       <h2 id="name-notational-conventions">
 <a href="#name-notational-conventions" class="section-name selfRef">Notational Conventions</a>
       </h2>
-<p id="section-note.3-1">The key words "shall", "shall not",
+<p id="section-note.4-1">The key words "shall", "shall not",
 "should", "should not", "may", and
 "can" in this document are to be interpreted as described in
 [ISO Directive Part 2][ISODIR2].
 These key words are not used as dictionary terms such that
 any occurrence of them shall be interpreted as key words
-and are not to be interpreted with their natural language meanings.<a href="#section-note.3-1" class="pilcrow">¶</a></p>
+and are not to be interpreted with their natural language meanings.<a href="#section-note.4-1" class="pilcrow">¶</a></p>
 </section>
 <div id="toc">
 <section id="section-toc.1">
@@ -1263,22 +1254,25 @@ <h2 id="name-normative-refences">
           <p id="section-2-2.8.1">[RFC8705] - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens [RFC8705]: <a href="https://tools.ietf.org/html/rfc8705">https://tools.ietf.org/html/rfc8705</a><a href="#section-2-2.8.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-2-2.9">
-          <p id="section-2-2.9.1">[OBB-FAPI] - Open Banking Brasil Financial-grade API Security Profile 1.0 [OBB-FAPI]: <a href="https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html">https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html</a><a href="#section-2-2.9.1" class="pilcrow">¶</a></p>
+          <p id="section-2-2.9.1">[OBB-FAPI] - Open Banking Brasil Financial-grade API Security Profile 1.0 [OBB-FAPI]: <a href="https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html</a><a href="#section-2-2.9.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-2-2.10">
-          <p id="section-2-2.10.1">[DOC-ICP-01] - DECLARA&#199;&#195;O DE PR&#193;TICAS DE CERTIFICA&#199;&#195;O DA AUTORIDADE CERTIFICADORA RAIZ DA ICP-BRASIL: <a href="https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf">https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf</a><a href="#section-2-2.10.1" class="pilcrow">¶</a></p>
+          <p id="section-2-2.10.1">[OBB-FAPI-DCR] - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0 [OBB-FAPI-DCR]: &lt;https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html<a href="#section-2-2.10.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-2-2.11">
-          <p id="section-2-2.11.1">[RFC6749] - The OAuth 2.0 Authorization Framework [RFC6749]: <a href="https://tools.ietf.org/html/rfc6749">https://tools.ietf.org/html/rfc6749</a><a href="#section-2-2.11.1" class="pilcrow">¶</a></p>
+          <p id="section-2-2.11.1">[DOC-ICP-01] - DECLARA&#199;&#195;O DE PR&#193;TICAS DE CERTIFICA&#199;&#195;O DA AUTORIDADE CERTIFICADORA RAIZ DA ICP-BRASIL: <a href="https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf">https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf</a><a href="#section-2-2.11.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-2-2.12">
-          <p id="section-2-2.12.1">[BCB-IN134] - Manual de Seguran&#231;a do Open Banking: <a href="https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364">https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364</a><a href="#section-2-2.12.1" class="pilcrow">¶</a></p>
+          <p id="section-2-2.12.1">[RFC6749] - The OAuth 2.0 Authorization Framework [RFC6749]: <a href="https://tools.ietf.org/html/rfc6749">https://tools.ietf.org/html/rfc6749</a><a href="#section-2-2.12.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-2-2.13">
-          <p id="section-2-2.13.1">[RFC2818] - HTTP Over TLS: <a href="https://datatracker.ietf.org/doc/html/rfc2818">https://datatracker.ietf.org/doc/html/rfc2818</a><a href="#section-2-2.13.1" class="pilcrow">¶</a></p>
+          <p id="section-2-2.13.1">[BCB-IN134] - Manual de Seguran&#231;a do Open Banking: <a href="https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364">https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364</a><a href="#section-2-2.13.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-2-2.14">
-          <p id="section-2-2.14.1">[RFC5246] - The Transport Layer Security (TLS) Protocol Version 1.2 <a href="https://www.rfc-editor.org/rfc/rfc5246.txt">https://www.rfc-editor.org/rfc/rfc5246.txt</a><a href="#section-2-2.14.1" class="pilcrow">¶</a></p>
+          <p id="section-2-2.14.1">[RFC2818] - HTTP Over TLS: <a href="https://datatracker.ietf.org/doc/html/rfc2818">https://datatracker.ietf.org/doc/html/rfc2818</a><a href="#section-2-2.14.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-2-2.15">
+          <p id="section-2-2.15.1">[RFC5246] - The Transport Layer Security (TLS) Protocol Version 1.2 <a href="https://www.rfc-editor.org/rfc/rfc5246.txt">https://www.rfc-editor.org/rfc/rfc5246.txt</a><a href="#section-2-2.15.1" class="pilcrow">¶</a></p>
 </li>
 </ul>
 </section>
@@ -1298,28 +1292,28 @@ <h2 id="name-glossary">
       </h2>
 <ul>
 <li id="section-4-1.1">
-          <p id="section-4-1.1.1"><strong>SSA</strong> - Software Statement Assertion<a href="#section-4-1.1.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.1.1"><strong>API</strong> - Application Programming Interface<a href="#section-4-1.1.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.2">
-          <p id="section-4-1.2.1"><strong>SS</strong> - Software Statement<a href="#section-4-1.2.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.2.1"><strong>DCR</strong> - Dynamic Client Registration<a href="#section-4-1.2.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.3">
-          <p id="section-4-1.3.1"><strong>DCR</strong> - Dynamic Client Registration<a href="#section-4-1.3.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.3.1"><strong>HTTP</strong> - Hyper Text Transfer Protocol<a href="#section-4-1.3.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.4">
-          <p id="section-4-1.4.1"><strong>API</strong> - Application Programming Interface<a href="#section-4-1.4.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.4.1"><strong>ICP</strong> - Infraestrutura de Chave P&#250;blicas Brasileira<a href="#section-4-1.4.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.5">
-          <p id="section-4-1.5.1"><strong>HTTP</strong> - Hyper Text Transfer Protocol<a href="#section-4-1.5.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.5.1"><strong>SS</strong> - Software Statement<a href="#section-4-1.5.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.6">
-          <p id="section-4-1.6.1"><strong>TLS</strong> - Transport Layer Security<a href="#section-4-1.6.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.6.1"><strong>SSA</strong> - Software Statement Assertion<a href="#section-4-1.6.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.7">
-          <p id="section-4-1.7.1"><strong>mTLS</strong> - Mutual Transport Layer Security<a href="#section-4-1.7.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.7.1"><strong>TLS</strong> - Transport Layer Security<a href="#section-4-1.7.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.8">
-          <p id="section-4-1.8.1"><strong>ICP</strong> - Infraestrutura de Chave P&#250;blicas Brasileira<a href="#section-4-1.8.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.8.1"><strong>mTLS</strong> - Mutual Transport Layer Security<a href="#section-4-1.8.1" class="pilcrow">¶</a></p>
 </li>
 </ul>
 </section>
@@ -1366,6 +1360,7 @@ <h4 id="name-server-certificate">
           </h4>
 <p id="section-5.2.1-1">The Server Certificate must be issued to protect and authenticate the TLS channel used by the APIs that will be consumed by client applications of organizations participating in Open Banking.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
 <p id="section-5.2.1-2">The certificate standard used must follow the existing certificate issuing practices of "CERTIFICATE FOR WEB SERVER - ICP-Brasil".<a href="#section-5.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-5.2.1-3">The server certificate shall be sent with the intermediate chain, according to <a href="items%207.4.2">RFC5246</a>.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="client-certificate">
@@ -1519,10 +1514,10 @@ <h5 id="name-participating-certificate-a">
 <p id="section-5.2.3.2-1">The following certifying authorities carried out the onboard process for Open Banking Brasil and are authorized to issue Open Banking Brasil certificates.<a href="#section-5.2.3.2-1" class="pilcrow">¶</a></p>
 <ul>
 <li id="section-5.2.3.2-2.1">
-                <p id="section-5.2.3.2-2.1.1">Serpro<a href="#section-5.2.3.2-2.1.1" class="pilcrow">¶</a></p>
+                <p id="section-5.2.3.2-2.1.1">Serasa<a href="#section-5.2.3.2-2.1.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-5.2.3.2-2.2">
-                <p id="section-5.2.3.2-2.2.1">Serasa<a href="#section-5.2.3.2-2.2.1" class="pilcrow">¶</a></p>
+                <p id="section-5.2.3.2-2.2.1">Serpro<a href="#section-5.2.3.2-2.2.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-5.2.3.2-2.3">
                 <p id="section-5.2.3.2-2.3.1">Soluti<a href="#section-5.2.3.2-2.3.1" class="pilcrow">¶</a></p>
@@ -1547,7 +1542,7 @@ <h4 id="name-about-certificates-for-exch">
           </h4>
 <p id="section-5.2.5-1">According to section IV of Joint Resolution No. 1 of May 4, 2020, the establishment of bilateral partnerships between authorized institutions and partners is an arrangement provided in the regulation and which must observe, where applicable, the same standards and certificates requirements that are applicable to exchange of information between participating institutions.<a href="#section-5.2.5-1" class="pilcrow">¶</a></p>
 <p id="section-5.2.5-2">In accordance with &#167;2 of Art. 10 of Provisional Measure 2200-2 of August 24, 2001 and with the provisions of item 3.12 in BCB Normative Instruction No. 134, for bilateral communication between institutions and partners, the use is authorized, by mutual agreement between the parties, of a private PKI, provided that the requirements of this <em>profile for security certificates</em> are observed, including their formatting, algorithms and established attributes.<a href="#section-5.2.5-2" class="pilcrow">¶</a></p>
-<p id="section-5.2.5-3">The values ​​for filling in the attributes required in this specification, but not applicable to the partner, should be defined in common agreement between the authorized institution and the partner, which does not exempt the authorized institution from the responsibility for filling it in properly.<a href="#section-5.2.5-3" class="pilcrow">¶</a></p>
+<p id="section-5.2.5-3">The values for filling in the attributes required in this specification, but not applicable to the partner, should be defined in common agreement between the authorized institution and the partner, which does not exempt the authorized institution from the responsibility for filling it in properly.<a href="#section-5.2.5-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -1563,16 +1558,19 @@ <h2 id="name-acknowledgements">
 <p id="section-6-2">The following people contributed to this document:<a href="#section-6-2" class="pilcrow">¶</a></p>
 <ul>
 <li id="section-6-3.1">
-          <p id="section-6-3.1.1">Marcos Rodrigues (Ita&#250;)<a href="#section-6-3.1.1" class="pilcrow">¶</a></p>
+          <p id="section-6-3.1.1">Jo&#227;o Rodolfo Vieira (Ita&#250;)<a href="#section-6-3.1.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-6-3.2">
           <p id="section-6-3.2.1">Jos&#233; Michael Dias (Grupo Pan)<a href="#section-6-3.2.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-6-3.3">
-          <p id="section-6-3.3.1">Ralph Bragg (Raidiam)<a href="#section-6-3.3.1" class="pilcrow">¶</a></p>
+          <p id="section-6-3.3.1">Marcos Rodrigues (Ita&#250;)<a href="#section-6-3.3.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-6-3.4">
-          <p id="section-6-3.4.1">Ediemerson Moreira Alves (Santander)<a href="#section-6-3.4.1" class="pilcrow">¶</a></p>
+          <p id="section-6-3.4.1">Nic Marcondes (Quanto)<a href="#section-6-3.4.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-6-3.5">
+          <p id="section-6-3.5.1">Ralph Bragg (Raidiam)<a href="#section-6-3.5.1" class="pilcrow">¶</a></p>
 </li>
 </ul>
 </section>
@@ -1582,7 +1580,7 @@ <h2 id="name-acknowledgements">
       <h2 id="name-notices">
 <a href="#section-7" class="section-number selfRef">7. </a><a href="#name-notices" class="section-name selfRef">Notices</a>
       </h2>
-<p id="section-7-1">Copyright (c) 2021 Open Banking Brasil Initial Structure.<a href="#section-7-1" class="pilcrow">¶</a></p>
+<p id="section-7-1">Copyright (c) 2022 Open Banking Brasil Initial Structure.<a href="#section-7-1" class="pilcrow">¶</a></p>
 <p id="section-7-2">The Open Banking Brasil Initial Structure (OBBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OBBIS as the source of the material, but that such attribution does not indicate an endorsement by the OBBIS.<a href="#section-7-2" class="pilcrow">¶</a></p>
 <p id="section-7-3">The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation, the Open Banking Brasil GT Security Working Group and others. Although the Open Banking Brasil Initial Structure has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The Open Banking Brasil Initial Structure and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The Open Banking Brasil Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The Open Banking Brasil Initial Structure invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.<a href="#section-7-3" class="pilcrow">¶</a></p>
 </section>
@@ -1661,10 +1659,10 @@ <h3 id="name-configuration-template-for-s">
 keyUsage = critical,digitalSignature,nonRepudiation
 
 [ alt_name ]
-otherName.0 = 2.16.76.1.3.2;PRINTABLESTRING:&lt;Name of the person responsible for the organization&gt;
-otherName.1 = 2.16.76.1.3.3;PRINTABLESTRING:&lt;CNPJ&gt;
-otherName.2 = 2.16.76.1.3.4;PRINTABLESTRING:&lt;CPF/PIS/RF of responsible person&gt;
-otherName.3 = 2.16.76.1.3.7;PRINTABLESTRING:&lt;INSS Number&gt;
+otherName.0 = 2.16.76.1.3.2;UTF8:&lt;Name of the person responsible for the organization&gt;
+otherName.1 = 2.16.76.1.3.3;UTF8:&lt;CNPJ&gt;
+otherName.2 = 2.16.76.1.3.4;UTF8:&lt;CPF/PIS/RF of responsible person&gt;
+otherName.3 = 2.16.76.1.3.7;UTF8:&lt;INSS Number&gt;
 </pre><a href="#section-8.2-1" class="pilcrow">¶</a>
 </div>
 </section>
diff --git a/open-banking-brasil-certificate-standards-1_ID1.md b/open-banking-brasil-certificate-standards-1_ID1.md
index 6c8203d..9db4b1d 100644
--- a/open-banking-brasil-certificate-standards-1_ID1.md
+++ b/open-banking-brasil-certificate-standards-1_ID1.md
@@ -17,26 +17,6 @@
     status = "standard"
     value = "open-banking-brasil-certificate-standards-1_ID1"
 
-    [[author]]
-    initials = "M."
-    surname = "Rodrigues"
-    fullname = "Marcos Rodrigues"
-    organization = "Itau"
-    abbrev = "Itau"
-      [author.address]
-      email = "marcos.aurelio-rodrigues@itau-unibanco.com.br"
-      uri = "https://www.itau.com.br/"
-
-    [[author]]
-    initials = "J."
-    surname = "Dias"
-    fullname = "Jose Michael Dias"
-    organization = "Banco Pan"
-    abbrev = "Banco Pan"
-      [author.address]
-      email = "jose.henrique@grupopan.com"
-      uri = "https://www.bancopan.com.br/"
-
     [[author]]
     initials = "GT"
     surname = "Segurança"
@@ -48,9 +28,8 @@
       uri = "https://openbankingbrasil.org.br/"
 %%%
 
-# The English version of this document is Outdated
-Please refer to the portuguese version for up to date information:
->[https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html)
+.# The English version of this document is Outdated
+Please refer to the [Portuguese version](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1-ptbr.html) for up to date information.
 
 .# Foreword
 
@@ -109,14 +88,14 @@ For the purpose of this document, the terms defined in [RFC5280], [BCP195], [RFC
 
 # Glossary
 
-* **SSA** – Software Statement Assertion
-* **SS** – Software Statement
-* **DCR** – Dynamic Client Registration
 * **API** – Application Programming Interface
+* **DCR** – Dynamic Client Registration
 * **HTTP** – Hyper Text Transfer Protocol
+* **ICP** - Infraestrutura de Chave Públicas Brasileira
+* **SS** – Software Statement
+* **SSA** – Software Statement Assertion
 * **TLS** – Transport Layer Security
 * **mTLS** – Mutual Transport Layer Security
-* **ICP** - Infraestrutura de Chave Públicas Brasileira
 
 # Open Banking Brasil Standard
 
@@ -222,8 +201,8 @@ The Signature Certificate must be issued through the V5 chain, and must contain
 
 The following certifying authorities carried out the onboard process for Open Banking Brasil and are authorized to issue Open Banking Brasil certificates.
 
-* Serpro
 * Serasa
+* Serpro
 * Soluti
 
 ### Front-End Certificates
@@ -236,7 +215,7 @@ According to section IV of Joint Resolution No. 1 of May 4, 2020, the establishm
 
 In accordance with §2 of Art. 10 of Provisional Measure 2200-2 of August 24, 2001 and with the provisions of item 3.12 in BCB Normative Instruction No. 134, for bilateral communication between institutions and partners, the use is authorized, by mutual agreement between the parties, of a private PKI, provided that the requirements of this _profile for security certificates_ are observed, including their formatting, algorithms and established attributes.
 
-The values ​​for filling in the attributes required in this specification, but not applicable to the partner, should be defined in common agreement between the authorized institution and the partner, which does not exempt the authorized institution from the responsibility for filling it in properly.
+The values for filling in the attributes required in this specification, but not applicable to the partner, should be defined in common agreement between the authorized institution and the partner, which does not exempt the authorized institution from the responsibility for filling it in properly.
 
 # Acknowledgements
 
@@ -244,14 +223,15 @@ With thanks to all who have set the foundations for secure and safe data sharing
 
 The following people contributed to this document:
 
-* Marcos Rodrigues (Itaú)
+* João Rodolfo Vieira (Itaú)
 * José Michael Dias (Grupo Pan)
+* Marcos Rodrigues (Itaú)
+* Nic Marcondes (Quanto)
 * Ralph Bragg (Raidiam)
-* João Rodolfo Vieira (Itaú)
 
 # Notices
 
-Copyright (c) 2021 Open Banking Brasil Initial Structure.
+Copyright (c) 2022 Open Banking Brasil Initial Structure.
 
 The Open Banking Brasil Initial Structure (OBBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OBBIS as the source of the material, but that such attribution does not indicate an endorsement by the OBBIS.
 
@@ -321,33 +301,33 @@ subjectAltName = @alt_name
 keyUsage = critical,digitalSignature,nonRepudiation
 
 [ alt_name ]
-otherName.0 = 2.16.76.1.3.2;PRINTABLESTRING:<Name of the person responsible for the organization>
-otherName.1 = 2.16.76.1.3.3;PRINTABLESTRING:<CNPJ>
-otherName.2 = 2.16.76.1.3.4;PRINTABLESTRING:<CPF/PIS/RF of responsible person>
-otherName.3 = 2.16.76.1.3.7;PRINTABLESTRING:<INSS Number>
+otherName.0 = 2.16.76.1.3.2;UTF8:<Name of the person responsible for the organization>
+otherName.1 = 2.16.76.1.3.3;UTF8:<CNPJ>
+otherName.2 = 2.16.76.1.3.4;UTF8:<CPF/PIS/RF of responsible person>
+otherName.3 = 2.16.76.1.3.7;UTF8:<INSS Number>
 ```
 
 ## Endpoints vs Certificate type and mTLS requirements
 
 ASPSP may choose the certificate that should be adopted for Phase 1 endpoints, which, by nature, are publicly accessible.
 
-| OBB phase | group | endpoint | certificate type | mTLS |
-| --- | --- | --- | --- | --- |
-| NA | OIDC | .well-known/openid-configuration | EV or ICP WEB SSL |  
-| NA | OIDC | jwks_uri | EV or ICP WEB SSL |  
-| NA | OIDC | authorization_endpoint | EV |   |  
-| NA | OIDC | token_endpoint | ICP WEB SSL | Required |
-| NA | OIDC | userinfo_endpoint | ICP WEB SSL | Required |
-| NA | OIDC | pushed_authorization_request_endpoint |  ICP WEB SSL | Required |
-| NA | DCR | registration_endpoint |  ICP WEB SSL | Required |
-| NA | OIDC | revocation_endpoint | ICP WEB SSL | Required |
-| 2 | Consentimentos | /consents/* |  ICP WEB SSL | Required |
-| 2 | Resources | /resources/* | ICP WEB SSL | Required |
-| 2 | Dados | /customers/* | ICP WEB SSL | Required |
-| 2 | Cartão | /credit-cards-accounts/* | ICP WEB SSL | Required |
-| 2 | Contas | /accounts/* | ICP WEB SSL | Required |
-| 2 | Empréstimos | /loans/* | ICP WEB SSL | Required |
-| 2 | Financiamentos | /financings/* | ICP WEB SSL | Required |
-| 2 | Adiantamento | /unarranged-accounts-overdraft/* | ICP WEB SSL | Required |
-| 2 | Direitos   Creditórios | /invoice-financings/* | ICP WEB SSL | Required |
-| 3 | Pagamentos | /payments/* | ICP WEB SSL | Required |
+| OBB phase | group                  | endpoint                              | certificate type  | mTLS     |
+|-----------|------------------------|---------------------------------------|-------------------|----------|
+| NA        | OIDC                   | .well-known/openid-configuration      | EV or ICP WEB SSL |          |
+| NA        | OIDC                   | jwks_uri                              | EV or ICP WEB SSL |          |
+| NA        | OIDC                   | authorization_endpoint                | EV                |          |  
+| NA        | OIDC                   | token_endpoint                        | ICP WEB SSL       | Required |
+| NA        | OIDC                   | userinfo_endpoint                     | ICP WEB SSL       | Required |
+| NA        | OIDC                   | pushed_authorization_request_endpoint | ICP WEB SSL       | Required |
+| NA        | DCR                    | registration_endpoint                 | ICP WEB SSL       | Required |
+| NA        | OIDC                   | revocation_endpoint                   | ICP WEB SSL       | Required |
+| 2         | Consentimentos         | /consents/*                           | ICP WEB SSL       | Required |
+| 2         | Resources              | /resources/*                          | ICP WEB SSL       | Required |
+| 2         | Dados                  | /customers/*                          | ICP WEB SSL       | Required |
+| 2         | Cartão                 | /credit-cards-accounts/*              | ICP WEB SSL       | Required |
+| 2         | Contas                 | /accounts/*                           | ICP WEB SSL       | Required |
+| 2         | Empréstimos            | /loans/*                              | ICP WEB SSL       | Required |
+| 2         | Financiamentos         | /financings/*                         | ICP WEB SSL       | Required |
+| 2         | Adiantamento           | /unarranged-accounts-overdraft/*      | ICP WEB SSL       | Required |
+| 2         | Direitos   Creditórios | /invoice-financings/*                 | ICP WEB SSL       | Required |
+| 3         | Pagamentos             | /payments/*                           | ICP WEB SSL       | Required |

From e50fa9f86978c33689ac007a3a48ecb688ab72ea Mon Sep 17 00:00:00 2001
From: Nic <qbitnic@gmail.com>
Date: Thu, 17 Feb 2022 19:40:48 -0300
Subject: [PATCH 51/59] chore(md): Fix and export
 open-banking-brasil-certificate-standards-1_ID1-ptbr.md

---
 ...asil-certificate-standards-1_ID1-ptbr.html | 64 +++++++--------
 ...brasil-certificate-standards-1_ID1-ptbr.md | 77 +++++++------------
 2 files changed, 58 insertions(+), 83 deletions(-)

diff --git a/open-banking-brasil-certificate-standards-1_ID1-ptbr.html b/open-banking-brasil-certificate-standards-1_ID1-ptbr.html
index db92f72..548d021 100644
--- a/open-banking-brasil-certificate-standards-1_ID1-ptbr.html
+++ b/open-banking-brasil-certificate-standards-1_ID1-ptbr.html
@@ -5,8 +5,6 @@
 <meta content="Common,Latin" name="scripts">
 <meta content="initial-scale=1.0" name="viewport">
 <title>Padr&#227;o de Certificados Open Banking Brasil 1.0</title>
-<meta content="Marcos Rodrigues" name="author">
-<meta content="Jose Michael Dias" name="author">
 <meta content="GT Segurança" name="author">
 <meta content="xml2rfc 2.40.1" name="generator">
 <meta content="FAPI" name="keyword">
@@ -1070,10 +1068,10 @@
 <thead><tr>
 <td class="left"></td>
 <td class="center">OBB-CERT-1-ID1</td>
-<td class="right">September 2021</td>
+<td class="right">February 2022</td>
 </tr></thead>
 <tfoot><tr>
-<td class="left">Rodrigues, et al.</td>
+<td class="left">Segurança</td>
 <td class="center">Standards Track</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
@@ -1087,20 +1085,12 @@
 <dd class="internet-draft">open-banking-brasil-certificate-standards-1_ID1-ptbr</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2021-09-27" class="published">27 September 2021</time>
+<time datetime="2022-02-17" class="published">17 February 2022</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Standards Track</dd>
-<dt class="label-authors">Authors:</dt>
+<dt class="label-authors">Author:</dt>
 <dd class="authors">
-<div class="author">
-      <div class="author-name">M. Rodrigues</div>
-<div class="org">Itau</div>
-</div>
-<div class="author">
-      <div class="author-name">J. Dias</div>
-<div class="org">Banco Pan</div>
-</div>
 <div class="author">
       <div class="author-name">GT. Segurança</div>
 <div class="org">EIOBB</div>
@@ -1267,22 +1257,25 @@ <h2 id="name-refer234ncias-normativas">
           <p id="section-2-2.8.1">[RFC8705] - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens [RFC8705]: <a href="https://tools.ietf.org/html/rfc8705">https://tools.ietf.org/html/rfc8705</a><a href="#section-2-2.8.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-2-2.9">
-          <p id="section-2-2.9.1">[OBB-FAPI] - Open Banking Brasil Financial-grade API Security Profile 1.0 [OBB-FAPI]: <a href="https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html">https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html</a><a href="#section-2-2.9.1" class="pilcrow">¶</a></p>
+          <p id="section-2-2.9.1">[OBB-FAPI] - Open Banking Brasil Financial-grade API Security Profile 1.0 [OBB-FAPI]: <a href="https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html</a><a href="#section-2-2.9.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-2-2.10">
-          <p id="section-2-2.10.1">[DOC-ICP-01] - DECLARA&#199;&#195;O DE PR&#193;TICAS DE CERTIFICA&#199;&#195;O DA AUTORIDADE CERTIFICADORA RAIZ DA ICP-BRASIL: <a href="https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf">https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf</a><a href="#section-2-2.10.1" class="pilcrow">¶</a></p>
+          <p id="section-2-2.10.1">[OBB-FAPI-DCR] - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0 [OBB-FAPI-DCR]: &lt;https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html<a href="#section-2-2.10.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-2-2.11">
-          <p id="section-2-2.11.1">[RFC6749] - The OAuth 2.0 Authorization Framework [RFC6749]: <a href="https://tools.ietf.org/html/rfc6749">https://tools.ietf.org/html/rfc6749</a><a href="#section-2-2.11.1" class="pilcrow">¶</a></p>
+          <p id="section-2-2.11.1">[DOC-ICP-01] - DECLARA&#199;&#195;O DE PR&#193;TICAS DE CERTIFICA&#199;&#195;O DA AUTORIDADE CERTIFICADORA RAIZ DA ICP-BRASIL: <a href="https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf">https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf</a><a href="#section-2-2.11.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-2-2.12">
-          <p id="section-2-2.12.1">[BCB-IN134] - Manual de Seguran&#231;a do Open Banking: <a href="https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364">https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364</a><a href="#section-2-2.12.1" class="pilcrow">¶</a></p>
+          <p id="section-2-2.12.1">[RFC6749] - The OAuth 2.0 Authorization Framework [RFC6749]: <a href="https://tools.ietf.org/html/rfc6749">https://tools.ietf.org/html/rfc6749</a><a href="#section-2-2.12.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-2-2.13">
-          <p id="section-2-2.13.1">[RFC2818] - HTTP Over TLS: <a href="https://datatracker.ietf.org/doc/html/rfc2818">https://datatracker.ietf.org/doc/html/rfc2818</a><a href="#section-2-2.13.1" class="pilcrow">¶</a></p>
+          <p id="section-2-2.13.1">[BCB-IN134] - Manual de Seguran&#231;a do Open Banking: <a href="https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364">https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364</a><a href="#section-2-2.13.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-2-2.14">
-          <p id="section-2-2.14.1">[RFC5246] - The Transport Layer Security (TLS) Protocol Version 1.2 <a href="https://www.rfc-editor.org/rfc/rfc5246.txt">https://www.rfc-editor.org/rfc/rfc5246.txt</a><a href="#section-2-2.14.1" class="pilcrow">¶</a></p>
+          <p id="section-2-2.14.1">[RFC2818] - HTTP Over TLS: <a href="https://datatracker.ietf.org/doc/html/rfc2818">https://datatracker.ietf.org/doc/html/rfc2818</a><a href="#section-2-2.14.1" class="pilcrow">¶</a></p>
+</li>
+<li id="section-2-2.15">
+          <p id="section-2-2.15.1">[RFC5246] - The Transport Layer Security (TLS) Protocol Version 1.2 <a href="https://www.rfc-editor.org/rfc/rfc5246.txt">https://www.rfc-editor.org/rfc/rfc5246.txt</a><a href="#section-2-2.15.1" class="pilcrow">¶</a></p>
 </li>
 </ul>
 </section>
@@ -1302,28 +1295,28 @@ <h2 id="name-gloss225rio">
       </h2>
 <ul>
 <li id="section-4-1.1">
-          <p id="section-4-1.1.1"><strong>SSA</strong> - Software Statement Assertion<a href="#section-4-1.1.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.1.1"><strong>API</strong> - Application Programming Interface<a href="#section-4-1.1.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.2">
-          <p id="section-4-1.2.1"><strong>SS</strong> - Software Statement<a href="#section-4-1.2.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.2.1"><strong>DCR</strong> - Dynamic Client Registration<a href="#section-4-1.2.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.3">
-          <p id="section-4-1.3.1"><strong>DCR</strong> - Dynamic Client Registration<a href="#section-4-1.3.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.3.1"><strong>HTTP</strong> - Hyper Text Transfer Protocol<a href="#section-4-1.3.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.4">
-          <p id="section-4-1.4.1"><strong>API</strong> - Application Programming Interface<a href="#section-4-1.4.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.4.1"><strong>ICP</strong> - Infraestrutura de Chave P&#250;blicas Brasileira<a href="#section-4-1.4.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.5">
-          <p id="section-4-1.5.1"><strong>HTTP</strong> - Hyper Text Transfer Protocol<a href="#section-4-1.5.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.5.1"><strong>SS</strong> - Software Statement<a href="#section-4-1.5.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.6">
-          <p id="section-4-1.6.1"><strong>TLS</strong> - Transport Layer Security<a href="#section-4-1.6.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.6.1"><strong>SSA</strong> - Software Statement Assertion<a href="#section-4-1.6.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.7">
-          <p id="section-4-1.7.1"><strong>mTLS</strong> - Mutual Transport Layer Security<a href="#section-4-1.7.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.7.1"><strong>TLS</strong> - Transport Layer Security<a href="#section-4-1.7.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-4-1.8">
-          <p id="section-4-1.8.1"><strong>ICP</strong> - Infraestrutura de Chave P&#250;blicas Brasileira<a href="#section-4-1.8.1" class="pilcrow">¶</a></p>
+          <p id="section-4-1.8.1"><strong>mTLS</strong> - Mutual Transport Layer Security<a href="#section-4-1.8.1" class="pilcrow">¶</a></p>
 </li>
 </ul>
 </section>
@@ -1370,6 +1363,7 @@ <h4 id="name-certificado-servidor">
           </h4>
 <p id="section-5.2.1-1">O Certificado Servidor deve ser emitido para proteger e autenticar o canal TLS utilizado pelas APIs que ser&#227;o consumidas pelas aplica&#231;&#245;es cliente de entidades participantes do Open Banking.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
 <p id="section-5.2.1-2">O padr&#227;o de certificado utilizado deve seguir as pr&#225;ticas de emiss&#227;o de certificados existentes de "CERTIFICADO PARA SERVIDOR WEB - ICP-Brasil".<a href="#section-5.2.1-2" class="pilcrow">¶</a></p>
+<p id="section-5.2.1-3">O certificado de servidor precisa ser enviado com a cadeia intermedi&#225;ria, conforme <a href="itens%207.4.2">RFC5246</a>.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="CertificadoCliente">
@@ -1523,10 +1517,10 @@ <h5 id="name-autoridades-certificadoras-">
 <p id="section-5.2.3.2-1">As seguintes autoridades certificadoras realizaram o processo de onboard ao Open Banking Brasil e est&#227;o habilitadas para realizar a emiss&#227;o de certificados do Open Banking Brasil.<a href="#section-5.2.3.2-1" class="pilcrow">¶</a></p>
 <ul>
 <li id="section-5.2.3.2-2.1">
-                <p id="section-5.2.3.2-2.1.1">Serpro<a href="#section-5.2.3.2-2.1.1" class="pilcrow">¶</a></p>
+                <p id="section-5.2.3.2-2.1.1">Serasa<a href="#section-5.2.3.2-2.1.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-5.2.3.2-2.2">
-                <p id="section-5.2.3.2-2.2.1">Serasa<a href="#section-5.2.3.2-2.2.1" class="pilcrow">¶</a></p>
+                <p id="section-5.2.3.2-2.2.1">Serpro<a href="#section-5.2.3.2-2.2.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-5.2.3.2-2.3">
                 <p id="section-5.2.3.2-2.3.1">Soluti<a href="#section-5.2.3.2-2.3.1" class="pilcrow">¶</a></p>
@@ -1567,19 +1561,19 @@ <h2 id="name-reconhecimento">
 <p id="section-6-2">As seguintes pessoas contribu&#237;ram para este documento:<a href="#section-6-2" class="pilcrow">¶</a></p>
 <ul>
 <li id="section-6-3.1">
-          <p id="section-6-3.1.1">Marcos Rodrigues (Ita&#250;)<a href="#section-6-3.1.1" class="pilcrow">¶</a></p>
+          <p id="section-6-3.1.1">Jo&#227;o Rodolfo Vieira (Ita&#250;)<a href="#section-6-3.1.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-6-3.2">
           <p id="section-6-3.2.1">Jos&#233; Michael Dias (Grupo Pan)<a href="#section-6-3.2.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-6-3.3">
-          <p id="section-6-3.3.1">Ralph Bragg (Raidiam)<a href="#section-6-3.3.1" class="pilcrow">¶</a></p>
+          <p id="section-6-3.3.1">Marcos Rodrigues (Ita&#250;)<a href="#section-6-3.3.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-6-3.4">
-          <p id="section-6-3.4.1">Ediemerson Moreira Alves (Santander)<a href="#section-6-3.4.1" class="pilcrow">¶</a></p>
+          <p id="section-6-3.4.1">Nic Marcondes (Quanto)<a href="#section-6-3.4.1" class="pilcrow">¶</a></p>
 </li>
 <li id="section-6-3.5">
-          <p id="section-6-3.5.1">Jo&#227;o Rodolfo Vieira (Ita&#250;)<a href="#section-6-3.5.1" class="pilcrow">¶</a></p>
+          <p id="section-6-3.5.1">Ralph Bragg (Raidiam)<a href="#section-6-3.5.1" class="pilcrow">¶</a></p>
 </li>
 </ul>
 </section>
@@ -1589,7 +1583,7 @@ <h2 id="name-reconhecimento">
       <h2 id="name-informativo">
 <a href="#section-7" class="section-number selfRef">7. </a><a href="#name-informativo" class="section-name selfRef">Informativo</a>
       </h2>
-<p id="section-7-1">Copyright (c) 2021 Estrutura Inicial do Open Banking Brasil.<a href="#section-7-1" class="pilcrow">¶</a></p>
+<p id="section-7-1">Copyright (c) 2022 Estrutura Inicial do Open Banking Brasil.<a href="#section-7-1" class="pilcrow">¶</a></p>
 <p id="section-7-2">A Estrutura Inicial do Open Banking Brasil (EIOBB) concede a qualquer Colaborador, desenvolvedor, implementador ou outra parte interessada uma licen&#231;a de direitos autorais mundial n&#227;o exclusiva, livre de royalties para reproduzir, preparar trabalhos derivados, distribuir, executar e exibir, estes Implementadores Rascunho ou Especifica&#231;&#227;o Final exclusivamente para fins de (i) desenvolver especifica&#231;&#245;es e (ii) implementar Rascunhos de Implementa&#231;&#245;es e Especifica&#231;&#245;es Finais com base em tais documentos, desde que a atribui&#231;&#227;o seja feita ao EIOBB como a fonte do material, mas que tal atribui&#231;&#227;o o fa&#231;a n&#227;o indica endosso do EIOBB.<a href="#section-7-2" class="pilcrow">¶</a></p>
 <p id="section-7-3">A tecnologia descrita nesta especifica&#231;&#227;o foi disponibilizada a partir de contribui&#231;&#245;es de v&#225;rias fontes, incluindo membros da OpenID Foundation, do GT-Seguran&#231;a do Open Banking Brasil e outros. Embora a Estrutura Inicial do Open Banking Brasil tenha tomado medidas para ajudar a garantir que a tecnologia esteja dispon&#237;vel para distribui&#231;&#227;o, ela n&#227;o toma posi&#231;&#227;o quanto &#224; validade ou escopo de qualquer propriedade intelectual ou outros direitos que possam ser reivindicados como pertencentes &#224; implementa&#231;&#227;o ou uso do tecnologia descrita nesta especifica&#231;&#227;o ou at&#233; que ponto qualquer licen&#231;a sob tais direitos pode ou n&#227;o estar dispon&#237;vel; nem representa que fez qualquer esfor&#231;o independente para identificar tais direitos. A Estrutura Inicial do Open Banking Brasil e os contribuidores desta especifica&#231;&#227;o n&#227;o oferecem (e por meio deste expressamente se isentam de quaisquer) garantias (expressas, impl&#237;citas ou de outra forma), incluindo garantias impl&#237;citas de comercializa&#231;&#227;o, n&#227;o viola&#231;&#227;o, adequa&#231;&#227;o a uma finalidade espec&#237;fica ou t&#237;tulo, relacionados a esta especifica&#231;&#227;o, e todo o risco quanto &#224; implementa&#231;&#227;o desta especifica&#231;&#227;o &#233; assumido pelo implementador. A pol&#237;tica de Direitos de Propriedade Intelectual do Open Banking Brasil exige que os contribuidores ofere&#231;am uma promessa de patente de n&#227;o fazer valer certas reivindica&#231;&#245;es de patentes contra outros contribuidores e implementadores. A Estrutura Inicial do Open Banking Brasil convida qualquer parte interessada a trazer &#224; sua aten&#231;&#227;o quaisquer direitos autorais, patentes, pedidos de patentes ou outros direitos de propriedade que possam abranger a tecnologia que possa ser necess&#225;ria para praticar esta especifica&#231;&#227;o.<a href="#section-7-3" class="pilcrow">¶</a></p>
 </section>
diff --git a/open-banking-brasil-certificate-standards-1_ID1-ptbr.md b/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
index b08276f..e8c3b1d 100644
--- a/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
+++ b/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
@@ -17,26 +17,6 @@
     status = "standard"
     value = "open-banking-brasil-certificate-standards-1_ID1-ptbr"
 
-    [[author]]
-    initials = "M."
-    surname = "Rodrigues"
-    fullname = "Marcos Rodrigues"
-    organization = "Itau"
-    abbrev = "Itau"
-      [author.address]
-      email = "marcos.aurelio-rodrigues@itau-unibanco.com.br"
-      uri = "https://www.itau.com.br/"
-
-    [[author]]
-    initials = "J."
-    surname = "Dias"
-    fullname = "Jose Michael Dias"
-    organization = "Banco Pan"
-    abbrev = "Banco Pan"
-      [author.address]
-      email = "jose.henrique@grupopan.com"
-      uri = "https://www.bancopan.com.br/"
-
     [[author]]
     initials = "GT"
     surname = "Segurança"
@@ -106,14 +86,14 @@ Para o propósito deste documento os termos definidos na [RFC5280], [BCP195], [R
 
 # Glossário {#Glossario}
 
-* **SSA** – Software Statement Assertion
-* **SS** – Software Statement
-* **DCR** – Dynamic Client Registration
 * **API** – Application Programming Interface
+* **DCR** – Dynamic Client Registration
 * **HTTP** – Hyper Text Transfer Protocol
+* **ICP** - Infraestrutura de Chave Públicas Brasileira
+* **SS** – Software Statement
+* **SSA** – Software Statement Assertion
 * **TLS** – Transport Layer Security
 * **mTLS** – Mutual Transport Layer Security
-* **ICP** - Infraestrutura de Chave Públicas Brasileira
 
 # Padrão de Certificados Open Banking Brasil {#PadraoCertificadosOpenBankingBrasil}
 
@@ -219,8 +199,8 @@ O Certificado de Assinatura deve ser emitido através de cadeia V5, e deve obrig
 
 As seguintes autoridades certificadoras realizaram o processo de onboard ao Open Banking Brasil e estão habilitadas para realizar a emissão de certificados do Open Banking Brasil.
 
-* Serpro
 * Serasa
+* Serpro
 * Soluti
 
 ### Certificado para Front-End {#CertificadoFrontEnd}
@@ -241,14 +221,15 @@ Agradecemos a todos que estabeleceram as bases para o compartilhamento seguro e
 
 As seguintes pessoas contribuíram para este documento:
 
-* Marcos Rodrigues (Itaú)
+* João Rodolfo Vieira (Itaú)
 * José Michael Dias (Grupo Pan)
+* Marcos Rodrigues (Itaú)
+* Nic Marcondes (Quanto)
 * Ralph Bragg (Raidiam)
-* João Rodolfo Vieira (Itaú)
 
 # Informativo {#Informativo}
 
-Copyright (c) 2021 Estrutura Inicial do Open Banking Brasil.
+Copyright (c) 2022 Estrutura Inicial do Open Banking Brasil.
 
 A Estrutura Inicial do Open Banking Brasil (EIOBB) concede a qualquer Colaborador, desenvolvedor, implementador ou outra parte interessada uma licença de direitos autorais mundial não exclusiva, livre de royalties para reproduzir, preparar trabalhos derivados, distribuir, executar e exibir, estes Implementadores Rascunho ou Especificação Final exclusivamente para fins de (i) desenvolver especificações e (ii) implementar Rascunhos de Implementações e Especificações Finais com base em tais documentos, desde que a atribuição seja feita ao EIOBB como a fonte do material, mas que tal atribuição o faça não indica endosso do EIOBB.
 
@@ -327,23 +308,23 @@ Abaixo apresentamos quais endpoints podem ser publicados utilizando certificado
 
 Fica a critério da instituição a escolha do certificado que deve ser adotado para os _endpoints_ da Fase 1, os quais, por natureza, são de acesso público.
 
-| Fase | Grupo | API | Certificado | mTLS |
-| --- | --- | --- | --- | --- |
-| NA | OIDC | .well-known/openid-configuration | EV ou ICP WEB SSL |  
-| NA | OIDC | jwks_uri | EV ou ICP WEB SSL |  
-| NA | OIDC | authorization_endpoint | EV |   |  
-| NA | OIDC | token_endpoint | ICP WEB SSL | Obrigatório |
-| NA | OIDC | userinfo_endpoint | ICP WEB SSL | Obrigatório |
-| NA | OIDC | pushed_authorization_request_endpoint |  ICP WEB SSL | Obrigatório |
-| NA | DCR | registration_endpoint |  ICP WEB SSL | Obrigatório |
-| NA | OIDC | revocation_endpoint | ICP WEB SSL | Obrigatório |
-| 2 | Consentimentos | /consents/* |  ICP WEB SSL | Obrigatório |
-| 2 | Resources | /resources/* | ICP WEB SSL | Obrigatório |
-| 2 | Dados | /customers/* | ICP WEB SSL | Obrigatório |
-| 2 | Cartão | /credit-cards-accounts/* | ICP WEB SSL | Obrigatório |
-| 2 | Contas | /accounts/* | ICP WEB SSL | Obrigatório |
-| 2 | Empréstimos | /loans/* | ICP WEB SSL | Obrigatório |
-| 2 | Financiamentos | /financings/* | ICP WEB SSL | Obrigatório |
-| 2 | Adiantamento | /unarranged-accounts-overdraft/* | ICP WEB SSL | Obrigatório |
-| 2 | Direitos   Creditórios | /invoice-financings/* | ICP WEB SSL | Obrigatório |
-| 3 | Pagamentos | /payments/* | ICP WEB SSL | Obrigatório |
+| Fase | Grupo                  | API                                   | Certificado       | mTLS        |
+|------|------------------------|---------------------------------------|-------------------|-------------|
+| NA   | OIDC                   | .well-known/openid-configuration      | EV ou ICP WEB SSL |             |
+| NA   | OIDC                   | jwks_uri                              | EV ou ICP WEB SSL |             |
+| NA   | OIDC                   | authorization_endpoint                | EV                |             |  
+| NA   | OIDC                   | token_endpoint                        | ICP WEB SSL       | Obrigatório |
+| NA   | OIDC                   | userinfo_endpoint                     | ICP WEB SSL       | Obrigatório |
+| NA   | OIDC                   | pushed_authorization_request_endpoint | ICP WEB SSL       | Obrigatório |
+| NA   | DCR                    | registration_endpoint                 | ICP WEB SSL       | Obrigatório |
+| NA   | OIDC                   | revocation_endpoint                   | ICP WEB SSL       | Obrigatório |
+| 2    | Consentimentos         | /consents/*                           | ICP WEB SSL       | Obrigatório |
+| 2    | Resources              | /resources/*                          | ICP WEB SSL       | Obrigatório |
+| 2    | Dados                  | /customers/*                          | ICP WEB SSL       | Obrigatório |
+| 2    | Cartão                 | /credit-cards-accounts/*              | ICP WEB SSL       | Obrigatório |
+| 2    | Contas                 | /accounts/*                           | ICP WEB SSL       | Obrigatório |
+| 2    | Empréstimos            | /loans/*                              | ICP WEB SSL       | Obrigatório |
+| 2    | Financiamentos         | /financings/*                         | ICP WEB SSL       | Obrigatório |
+| 2    | Adiantamento           | /unarranged-accounts-overdraft/*      | ICP WEB SSL       | Obrigatório |
+| 2    | Direitos   Creditórios | /invoice-financings/*                 | ICP WEB SSL       | Obrigatório |
+| 3    | Pagamentos             | /payments/*                           | ICP WEB SSL       | Obrigatório |

From 9fef4b0fe9b8492dfefd055866631ddf052cc815 Mon Sep 17 00:00:00 2001
From: Nic <qbitnic@gmail.com>
Date: Thu, 17 Feb 2022 20:03:22 -0300
Subject: [PATCH 52/59] chore(md): Fix and export
 open-banking-brasil-dynamic-client-registration-1_ID2.md

---
 images/dynamic-client-registration.svg        | 118 +++
 ...sil-dynamic-client-registration-1_ID2.html | 725 +++++++++++-------
 ...rasil-dynamic-client-registration-1_ID2.md |  81 +-
 3 files changed, 606 insertions(+), 318 deletions(-)
 create mode 100644 images/dynamic-client-registration.svg

diff --git a/images/dynamic-client-registration.svg b/images/dynamic-client-registration.svg
new file mode 100644
index 0000000..1af0fe1
--- /dev/null
+++ b/images/dynamic-client-registration.svg
@@ -0,0 +1,118 @@
+<?xml version="1.0" encoding="utf-8"?>
+<svg contentstyletype="text/css" height="auto" preserveAspectRatio="none" style="width:100%;height:auto;background:#FFFFFF;" version="1.1" viewBox="0 0 1153 906" width="100%" zoomAndPan="magnify" xmlns="http://www.w3.org/2000/svg">
+  <g>
+    <rect height="26.2969" style="stroke:#00000000;stroke-width:1.0;fill:none;" width="238" x="456.75" y="10"/>
+    <text fill="#000000" font-family="sans-serif" font-size="14" font-weight="bold" lengthAdjust="spacing" textLength="228" x="461.75" y="27.9951" style="white-space: pre;">Dynamic Client Registration</text>
+    <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="298" x2="298" y1="73.5938" y2="870.9141"/>
+    <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="482" x2="482" y1="73.5938" y2="870.9141"/>
+    <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="624" x2="624" y1="73.5938" y2="870.9141"/>
+    <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="746" x2="746" y1="73.5938" y2="870.9141"/>
+    <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="877" x2="877" y1="73.5938" y2="870.9141"/>
+    <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="1109.5" x2="1109.5" y1="73.5938" y2="870.9141"/>
+    <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="41" x="278" y="42.2969"/>
+    <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="27" x="285" y="62.292" style="white-space: pre;">TPP</text>
+    <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="41" x="278" y="869.9141"/>
+    <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="27" x="285" y="889.9092" style="white-space: pre;">TPP</text>
+    <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="101" x="432" y="42.2969"/>
+    <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="87" x="439" y="62.292" style="white-space: pre;">DirectoryAS</text>
+    <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="101" x="432" y="869.9141"/>
+    <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="87" x="439" y="889.9092" style="white-space: pre;">DirectoryAS</text>
+    <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="105" x="572" y="42.2969"/>
+    <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="91" x="579" y="62.292" style="white-space: pre;">DirectoryAPI</text>
+    <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="105" x="572" y="869.9141"/>
+    <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="91" x="579" y="889.9092" style="white-space: pre;">DirectoryAPI</text>
+    <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="119" x="687" y="42.2969"/>
+    <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="105" x="694" y="62.292" style="white-space: pre;">DirectoryJWKS</text>
+    <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="119" x="687" y="869.9141"/>
+    <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="105" x="694" y="889.9092" style="white-space: pre;">DirectoryJWKS</text>
+    <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="69" x="843" y="42.2969"/>
+    <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="55" x="850" y="62.292" style="white-space: pre;">BankAS</text>
+    <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="69" x="843" y="869.9141"/>
+    <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="55" x="850" y="889.9092" style="white-space: pre;">BankAS</text>
+    <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="76" x="1071.5" y="42.2969"/>
+    <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="62" x="1078.5" y="62.292" style="white-space: pre;">ICPBrasil</text>
+    <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="76" x="1071.5" y="869.9141"/>
+    <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="62" x="1078.5" y="889.9092" style="white-space: pre;">ICPBrasil</text>
+    <polygon fill="#181818" points="470.5,100.7266,480.5,104.7266,470.5,108.7266,474.5,104.7266" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="476.5" y1="104.7266" y2="104.7266"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="160" x="305.5" y="99.6606" style="white-space: pre;">OAuth 2.0 tls_client_auth</text>
+    <path d="M110,117.7266 L110,157.7266 L293,157.7266 L293,127.7266 L283,117.7266 L110,117.7266 " fill="#FEFFDD" style="stroke:#181818;stroke-width:0.5;"/>
+    <path d="M283,117.7266 L283,127.7266 L293,127.7266 L283,117.7266 " fill="#FEFFDD" style="stroke:#181818;stroke-width:0.5;"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="152" x="116" y="134.7935" style="white-space: pre;">Client Credentials Grant</text>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="162" x="116" y="149.9263" style="white-space: pre;">Scope directory:software</text>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="482.5" x2="524.5" y1="184.125" y2="184.125"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="524.5" x2="524.5" y1="184.125" y2="197.125"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="483.5" x2="524.5" y1="197.125" y2="197.125"/>
+    <polygon fill="#181818" points="493.5,193.125,483.5,197.125,493.5,201.125,489.5,197.125" style="stroke:#181818;stroke-width:1.0;"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="122" x="489.5" y="179.0591" style="white-space: pre;">Validate Certificate</text>
+    <polygon fill="#181818" points="1097.5,222.2578,1107.5,226.2578,1097.5,230.2578,1101.5,226.2578" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="482.5" x2="1103.5" y1="226.2578" y2="226.2578"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="160" x="489.5" y="221.1919" style="white-space: pre;">Check Revocation Status</text>
+    <polygon fill="#181818" points="493.5,251.3906,483.5,255.3906,493.5,259.3906,489.5,255.3906" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="487.5" x2="1108.5" y1="255.3906" y2="255.3906"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="88" x="499.5" y="250.3247" style="white-space: pre;">Certificate OK</text>
+    <polygon fill="#181818" points="309.5,280.5234,299.5,284.5234,309.5,288.5234,305.5,284.5234" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="481.5" y1="284.5234" y2="284.5234"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="88" x="315.5" y="279.4575" style="white-space: pre;">Access Token</text>
+    <polygon fill="#181818" points="612.5,309.6563,622.5,313.6563,612.5,317.6563,616.5,313.6563" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="618.5" y1="313.6563" y2="313.6563"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="302" x="305.5" y="308.5903" style="white-space: pre;">Retrieve Authorisation Servers + Access Token</text>
+    <polygon fill="#181818" points="309.5,338.7891,299.5,342.7891,309.5,346.7891,305.5,342.7891" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="623.5" y1="342.7891" y2="342.7891"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="138" x="315.5" y="337.7231" style="white-space: pre;">Authorisation Servers</text>
+    <polygon fill="#181818" points="865.5,367.9219,875.5,371.9219,865.5,375.9219,869.5,371.9219" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="871.5" y1="371.9219" y2="371.9219"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="195" x="305.5" y="366.856" style="white-space: pre;">Retrieve OpenID Configuration</text>
+    <polygon fill="#181818" points="309.5,397.0547,299.5,401.0547,309.5,405.0547,305.5,401.0547" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="876.5" y1="401.0547" y2="401.0547"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="221" x="315.5" y="395.9888" style="white-space: pre;">JSON OpenID Discovery Clause 4.2</text>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="340.5" y1="430.1875" y2="430.1875"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="340.5" x2="340.5" y1="430.1875" y2="443.1875"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="299.5" x2="340.5" y1="443.1875" y2="443.1875"/>
+    <polygon fill="#181818" points="309.5,439.1875,299.5,443.1875,309.5,447.1875,305.5,443.1875" style="stroke:#181818;stroke-width:1.0;"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="165" x="305.5" y="425.1216" style="white-space: pre;">Extract Desired MetaData</text>
+    <polygon fill="#181818" points="612.5,468.3203,622.5,472.3203,612.5,476.3203,616.5,472.3203" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="618.5" y1="472.3203" y2="472.3203"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="83" x="305.5" y="467.2544" style="white-space: pre;">Retrieve SSA</text>
+    <polygon fill="#181818" points="309.5,497.4531,299.5,501.4531,309.5,505.4531,305.5,501.4531" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="623.5" y1="501.4531" y2="501.4531"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="54" x="315.5" y="496.3872" style="white-space: pre;">SSA JWT</text>
+    <polygon fill="#181818" points="865.5,526.5859,875.5,530.5859,865.5,534.5859,869.5,530.5859" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="871.5" y1="530.5859" y2="530.5859"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="332" x="305.5" y="525.52" style="white-space: pre;">Post RFC7591 with SSA JWT as software_statement</text>
+    <polygon fill="#181818" points="1097.5,555.7188,1107.5,559.7188,1097.5,563.7188,1101.5,559.7188" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="877.5" x2="1103.5" y1="559.7188" y2="559.7188"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="160" x="884.5" y="554.6528" style="white-space: pre;">Check Revocation Status</text>
+    <polygon fill="#181818" points="888.5,584.8516,878.5,588.8516,888.5,592.8516,884.5,588.8516" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="882.5" x2="1108.5" y1="588.8516" y2="588.8516"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="88" x="894.5" y="583.7856" style="white-space: pre;">Certificate OK</text>
+    <polygon fill="#181818" points="757.5,613.9844,747.5,617.9844,757.5,621.9844,753.5,617.9844" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="751.5" x2="876.5" y1="617.9844" y2="617.9844"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="107" x="763.5" y="612.9185" style="white-space: pre;">Retrieve Key Set</text>
+    <polygon fill="#181818" points="865.5,643.1172,875.5,647.1172,865.5,651.1172,869.5,647.1172" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="746.5" x2="871.5" y1="647.1172" y2="647.1172"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="96" x="753.5" y="642.0513" style="white-space: pre;">Return Key Set</text>
+    <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="877.5" x2="919.5" y1="676.25" y2="676.25"/>
+    <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="919.5" x2="919.5" y1="676.25" y2="689.25"/>
+    <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="878.5" x2="919.5" y1="689.25" y2="689.25"/>
+    <polygon fill="#181818" points="888.5,685.25,878.5,689.25,888.5,693.25,884.5,689.25" style="stroke:#181818;stroke-width:1.0;"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="218" x="884.5" y="671.1841" style="white-space: pre;">Validate SSA in RFC 7591 Request</text>
+    <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="877.5" x2="919.5" y1="718.3828" y2="718.3828"/>
+    <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="919.5" x2="919.5" y1="718.3828" y2="731.3828"/>
+    <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="878.5" x2="919.5" y1="731.3828" y2="731.3828"/>
+    <polygon fill="#181818" points="888.5,727.3828,878.5,731.3828,888.5,735.3828,884.5,731.3828" style="stroke:#181818;stroke-width:1.0;"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="170" x="884.5" y="713.3169" style="white-space: pre;">Validate RFC7591 Request</text>
+    <path d="M5,744.3828 L5,784.3828 L294,784.3828 L294,754.3828 L284,744.3828 L5,744.3828 " fill="#FEFFDD" style="stroke:#181818;stroke-width:0.5;"/>
+    <path d="M284,744.3828 L284,754.3828 L294,754.3828 L284,744.3828 " fill="#FEFFDD" style="stroke:#181818;stroke-width:0.5;"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="268" x="11" y="761.4497" style="white-space: pre;">Request must be made to token endpoint</text>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="154" x="11" y="776.5825" style="white-space: pre;">secured with mutual tls.</text>
+    <polygon fill="#181818" points="309.5,806.7813,299.5,810.7813,309.5,814.7813,305.5,810.7813" style="stroke:#181818;stroke-width:1.0;"/>
+    <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="876.5" y1="810.7813" y2="810.7813"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="448" x="315.5" y="805.7153" style="white-space: pre;">Return RFC7591 Client Configuration +   RFC7592 Management Token</text>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="340.5" y1="839.9141" y2="839.9141"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="340.5" x2="340.5" y1="839.9141" y2="852.9141"/>
+    <line style="stroke:#181818;stroke-width:1.0;" x1="299.5" x2="340.5" y1="852.9141" y2="852.9141"/>
+    <polygon fill="#181818" points="309.5,848.9141,299.5,852.9141,309.5,856.9141,305.5,852.9141" style="stroke:#181818;stroke-width:1.0;"/>
+    <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="163" x="305.5" y="834.8481" style="white-space: pre;">Save Management Token</text>
+  </g>
+</svg>
\ No newline at end of file
diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.html b/open-banking-brasil-dynamic-client-registration-1_ID2.html
index 68cec05..800de16 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.html
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.html
@@ -5,12 +5,29 @@
 <meta content="Common,Latin" name="scripts">
 <meta content="initial-scale=1.0" name="viewport">
 <title>Open Banking Brasil Financial-grade API Dynamic Client Registration 1.0 Implementers Draft 2</title>
-<meta content="Ralph Bragg" name="author">
 <meta content="OBBIS GT Security" name="author">
-<meta content="xml2rfc 2.40.1" name="generator">
+<meta content="xml2rfc 3.12.2" name="generator">
 <meta content="FAPI" name="keyword">
 <meta content="Open Banking Brasil GT Security" name="keyword">
 <meta content="open-banking-brasil-dynamic-client-registration-1_ID2" name="ietf.draft">
+<!-- Generator version information:
+  xml2rfc 3.12.2
+    Python 3.10.2
+    appdirs 1.4.4
+    ConfigArgParse 1.5.3
+    google-i18n-address 2.5.0
+    html5lib 1.1
+    intervaltree 3.1.0
+    Jinja2 2.11.3
+    kitchen 1.2.6
+    lxml 4.8.0
+    pycountry 22.1.10
+    pyflakes 2.4.0
+    PyYAML 6.0
+    requests 2.27.1
+    setuptools 58.1.0
+    six 1.16.0
+-->
 <link href="./open-banking-brasil-dynamic-client-registration-1_ID2.xml" rel="alternate" type="application/rfc+xml">
 <link href="#copyright" rel="license">
 <style type="text/css">/*
@@ -179,6 +196,9 @@
 ul.empty li, .ulEmpty li {
   margin-top: 0.5em;
 }
+ul.ulBare, li.ulBare {
+  margin-left: 0em !important;
+}
 ul.compact, .ulCompact,
 ol.compact, .olCompact {
   line-height: 100%;
@@ -362,6 +382,12 @@
   float: left;
   margin-bottom: 0;
 }
+/* Fix PDF info block run off issue */
+@media print {
+  #identifiers dd {
+    float: none;
+  }
+}
 #identifiers .authors .author {
   display: inline-block;
   margin-right: 1.5em;
@@ -912,12 +938,6 @@
   }
 
 }
-/* Avoid wrapping of URLs in references */
-@media screen {
-  .references a {
-    white-space: nowrap;
-  }
-}
 /* Tweak the bcp14 keyword presentation */
 .bcp14 {
   font-variant: small-caps;
@@ -988,7 +1008,7 @@
 }
 /* Make .olPercent look the same as <ol><li> */
 dl.olPercent > dd {
-  margin: 0 0 0.25em 0;
+  margin-bottom: 0.25em;
   min-height: initial;
 }
 /* Give aside some styling to set it apart */
@@ -1026,14 +1046,6 @@
     margin-bottom: 1em;
   }
 }
-/*
-  The margin-left: 0 on <dd> removes all distinction
-  between levels from nested <dl>s.  Undo that.
-*/
-dl.olPercent > dd,
-dd {
-  margin-left: revert;
-}
 /* Avoid narrow tables forcing too narrow table captions, which may render badly */
 table {
   min-width: 20em;
@@ -1059,6 +1071,108 @@
   #toc nav { display: none; }
   #toc.active nav { display: block; }
 }
+/* Add support for keepWithNext */
+.keepWithNext {
+  break-after: avoid-page;
+  break-after: avoid-page;
+}
+/* Add support for keepWithPrevious */
+.keepWithPrevious {
+  break-before: avoid-page;
+}
+/* Change the approach to avoiding breaks inside artwork etc. */
+figure, pre, table, .artwork, .sourcecode  {
+  break-before: auto;
+  break-after: auto;
+}
+/* Avoid breaks between <dt> and <dd> */
+dl {
+  break-before: auto;
+  break-inside: auto;
+}
+dt {
+  break-before: auto;
+  break-after: avoid-page;
+}
+dd {
+  break-before: avoid-page;
+  break-after: auto;
+  orphans: 3;
+  widows: 3
+}
+span.break, dd.break {
+  margin-bottom: 0;
+  min-height: 0;
+  break-before: auto;
+  break-inside: auto;
+  break-after: auto;
+}
+/* Undo break-before ToC */
+@media print {
+  #toc {
+    break-before: auto;
+  }
+}
+/* Text in compact lists should not get extra bottim margin space,
+   since that would makes the list not compact */
+ul.compact p, .ulCompact p,
+ol.compact p, .olCompact p {
+ margin: 0;
+}
+/* But the list as a whole needs the extra space at the end */
+section ul.compact,
+section .ulCompact,
+section ol.compact,
+section .olCompact {
+  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
+}
+/* The tt and code background above interferes with for instance table cell
+   backgrounds.  Changed to something a bit more selective. */
+tt, code {
+  background-color: transparent;
+}
+p tt, p code, li tt, li code {
+  background-color: #f8f8f8;
+}
+/* Tweak the pre margin -- 0px doesn't come out well */
+pre {
+   margin-top: 0.5px;
+}
+/* Tweak the comact list text */
+ul.compact, .ulCompact,
+ol.compact, .olCompact,
+dl.compact, .dlCompact {
+  line-height: normal;
+}
+/* Don't add top margin for nested lists */
+li > ul, li > ol, li > dl,
+dd > ul, dd > ol, dd > dl,
+dl > dd > dl {
+  margin-top: initial;
+}
+/* Elements that should not be rendered on the same line as a <dt> */
+/* This should match the element list in writer.text.TextWriter.render_dl() */
+dd > div.artwork:first-child,
+dd > aside:first-child,
+dd > figure:first-child,
+dd > ol:first-child,
+dd > div:first-child > pre.sourcecode,
+dd > table:first-child,
+dd > ul:first-child {
+  clear: left;
+}
+/* fix for weird browser behaviour when <dd/> is empty */
+dt+dd:empty::before{
+  content: "\00a0";
+}
+/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
+li > p {
+  margin-bottom: 0.5em
+}
+/* Don't let p margin spill out from inside list items */
+li > p:last-of-type {
+  margin-bottom: 0;
+}
 </style>
 <link href="rfc-local.css" rel="stylesheet" type="text/css">
 </head>
@@ -1068,10 +1182,10 @@
 <thead><tr>
 <td class="left"></td>
 <td class="center">OBB-FAPI-1-DCR-ID2</td>
-<td class="right">November 2021</td>
+<td class="right">February 2022</td>
 </tr></thead>
 <tfoot><tr>
-<td class="left">Bragg & Security</td>
+<td class="left">Security</td>
 <td class="center">Standards Track</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
@@ -1081,20 +1195,8 @@
 <dl id="identifiers">
 <dt class="label-workgroup">Workgroup:</dt>
 <dd class="workgroup">Open Banking Brasil GT Security</dd>
-<dt class="label-internet-draft">Internet-Draft:</dt>
-<dd class="internet-draft">open-banking-brasil-dynamic-client-registration-1_ID2</dd>
-<dt class="label-published">Published:</dt>
-<dd class="published">
-<time datetime="2021-11-11" class="published">11 November 2021</time>
-    </dd>
-<dt class="label-intended-status">Intended Status:</dt>
-<dd class="intended-status">Standards Track</dd>
-<dt class="label-authors">Authors:</dt>
+<dt class="label-authors">Author:</dt>
 <dd class="authors">
-<div class="author">
-      <div class="author-name">R. Bragg</div>
-<div class="org">Raidiam</div>
-</div>
 <div class="author">
       <div class="author-name">GT. Security</div>
 <div class="org">OBBIS</div>
@@ -1110,14 +1212,13 @@ <h2 id="name-foreword">
 <p id="section-note.1-1">Este documento tamb&#233;m est&#225; dispon&#237;vel em <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html">portugu&#234;s</a><a href="#section-note.1-1" class="pilcrow">¶</a></p>
 <p id="section-note.1-2">The Open Banking Brasil Initial Structure is responsible for creating standards and specifications necessary to meet the requirements and obligations of the Brasil Open Banking Legislation as originally outlined by the <a href="https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf">Brasil Central Bank</a>. There is a possibility that some of the elements of this document may be the subject to patent rights. OBBIS shall not be held responsible for identifying any or all such patent rights.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
 <p id="section-note.1-3">Open Banking Brasil Financial-grade API Security Profile 1.0 consists of the following parts:<a href="#section-note.1-3" class="pilcrow">¶</a></p>
-<ul class="note">
-<li class="note" id="section-note.1-4.1">
-          <p id="section-note.1-4.1.1"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">Open Banking Brasil Financial-grade API Security Profile 1.0</a><a href="#section-note.1-4.1.1" class="pilcrow">¶</a></p>
+<ul class="compact note">
+<li class="compact note" id="section-note.1-4.1">
+          <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">Open Banking Brasil Financial-grade API Security Profile 1.0</a><a href="#section-note.1-4.1" class="pilcrow">¶</a>
 </li>
-<li class="note" id="section-note.1-4.2">
-          <p id="section-note.1-4.2.1">Open Banking Brasil Dynamic Client Registration Profile 1.0<a href="#section-note.1-4.2.1" class="pilcrow">¶</a></p>
+        <li class="compact note" id="section-note.1-4.2">Open Banking Brasil Dynamic Client Registration Profile 1.0<a href="#section-note.1-4.2" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 <p id="section-note.1-5">These parts are intended to be used with <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>, <a href="https://tools.ietf.org/html/rfc6750">RFC6750</a>, <a href="https://tools.ietf.org/html/rfc7636">RFC7636</a>, <a href="https://openid.net/specs/openid-connect-core-1_0.html">OIDC</a>, <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OIDR</a>, <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a>, <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a>, <a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">FAPI-1-Baseline</a> and <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">FAPI-1-Advanced</a><a href="#section-note.1-5" class="pilcrow">¶</a></p>
 </section>
 <section class="note" id="section-note.2">
@@ -1144,105 +1245,105 @@ <h2 id="name-notational-conventions">
         <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
 <a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
         </h2>
-<nav class="toc"><ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.1">
-            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-scope" class="xref">Scope</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
+<nav class="toc"><ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
+            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-scope" class="xref">Scope</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.2">
-            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-normative-references" class="xref">Normative references</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
+            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-normative-references" class="xref">Normative references</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.3">
-            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-terms-and-definitions" class="xref">Terms and definitions</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
+            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-terms-and-definitions" class="xref">Terms and definitions</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.4">
-            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-symbols-and-abbreviated-ter" class="xref">Symbols and Abbreviated terms</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
+            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-symbols-and-abbreviated-ter" class="xref">Symbols and Abbreviated terms</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.5">
-            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-introduction-2" class="xref">Introduction</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
+            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-introduction-2" class="xref">Introduction</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.6">
-            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-open-banking-brasil-openid-" class="xref">Open Banking Brasil OpenID Connect Discovery provisions</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.1">
-                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-authorization-server" class="xref">Authorization server</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
+            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-open-banking-brasil-openid-" class="xref">Open Banking Brasil OpenID Connect Discovery provisions</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
+                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-authorization-server" class="xref">Authorization server</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.2">
-                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-client" class="xref">Client</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
+                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-client" class="xref">Client</a></p>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7">
-            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-open-banking-brasil-openid-c" class="xref">Open Banking Brasil OpenID Connect Registration Provisions</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1">
-                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-authorization-server-2" class="xref">Authorization server</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1.2.1">
-                    <p id="section-toc.1-1.7.2.1.2.1.1"><a href="#section-7.1.1" class="xref">7.1.1</a>.  <a href="#name-applying-server-defaults" class="xref">Applying Server Defaults</a><a href="#section-toc.1-1.7.2.1.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
+            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-open-banking-brasil-openid-c" class="xref">Open Banking Brasil OpenID Connect Registration Provisions</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
+                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-authorization-server-2" class="xref">Authorization server</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.1">
+                    <p id="section-toc.1-1.7.2.1.2.1.1"><a href="#section-7.1.1" class="xref">7.1.1</a>.  <a href="#name-applying-server-defaults" class="xref">Applying Server Defaults</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1.2.2">
-                    <p id="section-toc.1-1.7.2.1.2.2.1"><a href="#section-7.1.2" class="xref">7.1.2</a>.  <a href="#name-certificate-distinguished-n" class="xref">Certificate Distinguished Name Parsing</a><a href="#section-toc.1-1.7.2.1.2.2.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.2">
+                    <p id="section-toc.1-1.7.2.1.2.2.1"><a href="#section-7.1.2" class="xref">7.1.2</a>.  <a href="#name-certificate-distinguished-n" class="xref">Certificate Distinguished Name Parsing</a></p>
 </li>
-</ul>
+                </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.2">
-                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-regulatory-roles-to-openid-" class="xref">Regulatory Roles to OpenID and OAuth 2.0 Mappings</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.1">
-                    <p id="section-toc.1-1.7.2.2.2.1.1"><a href="#section-7.2.1" class="xref">7.2.1</a>.  <a href="#name-implementers-note" class="xref">Implementers Note</a><a href="#section-toc.1-1.7.2.2.2.1.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
+                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-regulatory-roles-to-openid-" class="xref">Regulatory Roles to OpenID and OAuth 2.0 Mappings</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2.2.1">
+                    <p id="section-toc.1-1.7.2.2.2.1.1"><a href="#section-7.2.1" class="xref">7.2.1</a>.  <a href="#name-implementers-note" class="xref">Implementers Note</a></p>
 </li>
-</ul>
+                </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.3">
-                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-regulatory-roles-to-dynamic" class="xref">Regulatory Roles to dynamic OAuth 2.0 scope Mappings</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.3">
+                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-regulatory-roles-to-dynamic" class="xref">Regulatory Roles to dynamic OAuth 2.0 scope Mappings</a></p>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.8">
-            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-software-statement" class="xref">Software Statement</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.8.2.1">
-                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-software-statement-claims" class="xref">Software Statement Claims</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
+            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-software-statement" class="xref">Software Statement</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
+                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-software-statement-claims" class="xref">Software Statement Claims</a></p>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.9">
-            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-dynamic-client-registration" class="xref">Dynamic Client Registration Request Processing</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.1">
-                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-posting-a-request-with-a-so" class="xref">Posting a request with a software statement</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
+            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-dynamic-client-registration" class="xref">Dynamic Client Registration Request Processing</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.1">
+                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-posting-a-request-with-a-so" class="xref">Posting a request with a software statement</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.2">
-                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-open-banking-brasil-ssa-key" class="xref">Open Banking Brasil SSA Key Store and Issuer Details</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2">
+                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-open-banking-brasil-ssa-key" class="xref">Open Banking Brasil SSA Key Store and Issuer Details</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.3">
-                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-about-authentication-and-au" class="xref">About authentication and authorization mechanisms for DCR and DCM services</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.3.2.1">
-                    <p id="section-toc.1-1.9.2.3.2.1.1"><a href="#section-9.3.1" class="xref">9.3.1</a>.  <a href="#name-client-registration-post-re" class="xref">Client registration - POST /register</a><a href="#section-toc.1-1.9.2.3.2.1.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3">
+                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-about-authentication-and-au" class="xref">About authentication and authorization mechanisms for DCR and DCM services</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3.2.1">
+                    <p id="section-toc.1-1.9.2.3.2.1.1"><a href="#section-9.3.1" class="xref">9.3.1</a>.  <a href="#name-client-registration-post-re" class="xref">Client registration - POST /register</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.3.2.2">
-                    <p id="section-toc.1-1.9.2.3.2.2.1"><a href="#section-9.3.2" class="xref">9.3.2</a>.  <a href="#name-client-maintenance-get-regi" class="xref">Client Maintenance - GET /register - PUT /register - DELETE /register</a><a href="#section-toc.1-1.9.2.3.2.2.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3.2.2">
+                    <p id="section-toc.1-1.9.2.3.2.2.1"><a href="#section-9.3.2" class="xref">9.3.2</a>.  <a href="#name-client-maintenance-get-regi" class="xref">Client Maintenance - GET /register - PUT /register - DELETE /register</a></p>
 </li>
-</ul>
+                </ul>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.10">
-            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-acknowledgement" class="xref">Acknowledgement</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
+            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-acknowledgement" class="xref">Acknowledgement</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.11">
-            <p id="section-toc.1-1.11.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-notices" class="xref">Notices</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.11.2.1">
-                <p id="section-toc.1-1.11.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-appendix-a-example-software" class="xref">Appendix A. Example Software Statement Assertion</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
+            <p id="section-toc.1-1.11.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-notices" class="xref">Notices</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1">
+                <p id="section-toc.1-1.11.2.1.1"><a href="#appendix-A.1" class="xref">A.1</a>.  <a href="#name-appendix-a-example-software" class="xref">Appendix A. Example Software Statement Assertion</a></p>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.12">
-            <p id="section-toc.1-1.12.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
+            <p id="section-toc.1-1.12.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a></p>
 </li>
-</ul>
+        </ul>
 </nav>
 </section>
 </div>
@@ -1252,17 +1353,14 @@ <h2 id="name-scope">
 <a href="#section-1" class="section-number selfRef">1. </a><a href="#name-scope" class="section-name selfRef">Scope</a>
       </h2>
 <p id="section-1-1">This document specifies the method of<a href="#section-1-1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-1-2.1">
-          <p id="section-1-2.1.1">applications registered in the <a href="https://web.directory.openbankingbrasil.org.br">Open Banking Directory of Participants</a> to discover OpenID Providers offering services in the Open Banking Brasil ecosystem;<a href="#section-1-2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-1-2.1">applications registered in the <a href="https://web.directory.openbankingbrasil.org.br">Open Banking Directory of Participants</a> to discover OpenID Providers offering services in the Open Banking Brasil ecosystem;<a href="#section-1-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-1-2.2">
-          <p id="section-1-2.2.1">applications to use <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Registration</a> to onboard their applications with Bank OpenID Providers; and<a href="#section-1-2.2.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-1-2.2">applications to use <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Registration</a> to onboard their applications with Bank OpenID Providers; and<a href="#section-1-2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-1-2.3">
-          <p id="section-1-2.3.1">applications to use <a href="https://tools.ietf.org/html/rfc7592">OAuth 2.0 Dynamic Client Registration Management Protocol</a> to manage their applications with OpenID Providers;<a href="#section-1-2.3.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-1-2.3">applications to use <a href="https://tools.ietf.org/html/rfc7592">OAuth 2.0 Dynamic Client Registration Management Protocol</a> to manage their applications with OpenID Providers;<a href="#section-1-2.3" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 <p id="section-1-3">This document is applicable to all participants engaging in Open Banking in Brasil.<a href="#section-1-3" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -1310,35 +1408,52 @@ <h2 id="name-terms-and-definitions">
       <h2 id="name-symbols-and-abbreviated-ter">
 <a href="#section-4" class="section-number selfRef">4. </a><a href="#name-symbols-and-abbreviated-ter" class="section-name selfRef">Symbols and Abbreviated terms</a>
       </h2>
-<p id="section-4-1"><strong>SSA</strong> - Software Statement Assertion<a href="#section-4-1" class="pilcrow">¶</a></p>
-<p id="section-4-2"><strong>SS</strong> - Software Statement<a href="#section-4-2" class="pilcrow">¶</a></p>
-<p id="section-4-3"><strong>DCR</strong> - Dynamic Client Registration<a href="#section-4-3" class="pilcrow">¶</a></p>
-<p id="section-4-4"><strong>API</strong> - Application Programming Interface<a href="#section-4-4" class="pilcrow">¶</a></p>
-<p id="section-4-5"><strong>FAPI</strong> - Financial-grade API<a href="#section-4-5" class="pilcrow">¶</a></p>
-<p id="section-4-6"><strong>HTTP</strong> - Hyper Text Transfer Protocol<a href="#section-4-6" class="pilcrow">¶</a></p>
-<p id="section-4-7"><strong>OIDF</strong> - OpenID Foundation<a href="#section-4-7" class="pilcrow">¶</a></p>
-<p id="section-4-8"><strong>REST</strong> - Representational State Transfer<a href="#section-4-8" class="pilcrow">¶</a></p>
-<p id="section-4-9"><strong>TLS</strong> - Transport Layer Security<a href="#section-4-9" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-4-1.1">
+          <strong>API</strong> - Application Programming Interface<a href="#section-4-1.1" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.2">
+          <strong>DCR</strong> - Dynamic Client Registration<a href="#section-4-1.2" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.3">
+          <strong>FAPI</strong> - Financial-grade API<a href="#section-4-1.3" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.4">
+          <strong>HTTP</strong> - Hyper Text Transfer Protocol<a href="#section-4-1.4" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.5">
+          <strong>OIDF</strong> - OpenID Foundation<a href="#section-4-1.5" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.6">
+          <strong>REST</strong> - Representational State Transfer<a href="#section-4-1.6" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.7">
+          <strong>SS</strong> - Software Statement<a href="#section-4-1.7" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.8">
+          <strong>SSA</strong> - Software Statement Assertion<a href="#section-4-1.8" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.9">
+          <strong>TLS</strong> - Transport Layer Security<a href="#section-4-1.9" class="pilcrow">¶</a>
+</li>
+      </ul>
 </section>
 </div>
-<div id="introduction">
+<div id="introduction-1">
 <section id="section-5">
       <h2 id="name-introduction-2">
 <a href="#section-5" class="section-number selfRef">5. </a><a href="#name-introduction-2" class="section-name selfRef">Introduction</a>
       </h2>
 <p id="section-5-1">Brasil Open Bankings ecosystem leverages a federation trust provider or <em>directory of participants</em> as the golden source of information on accredited participants and software that are authorized to partake in the Open Banking Brasil ecosystem.<a href="#section-5-1" class="pilcrow">¶</a></p>
 <p id="section-5-2">The services by the Directory include<a href="#section-5-2" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-5-3.1">
-          <p id="section-5-3.1.1">Software registration and management.<a href="#section-5-3.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-5-3.1">Software registration and management.<a href="#section-5-3.1" class="pilcrow">¶</a>
 </li>
-<li id="section-5-3.2">
-          <p id="section-5-3.2.1">Software credential registration and management using ICP Certificates.<a href="#section-5-3.2.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-5-3.2">Software credential registration and management using ICP Certificates.<a href="#section-5-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-5-3.3">
-          <p id="section-5-3.3.1">Software Statement Assertion (SSA) generation<a href="#section-5-3.3.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-5-3.3">Software Statement Assertion (SSA) generation<a href="#section-5-3.3" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 <p id="section-5-4">Participants within the ecosystem must leverage these services to facilitate API driven OAuth client registration using the process outlined in clause 3.1.1 of <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a> with additional metadata necessary to support OpenID Connect defined in <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Registration</a>.<a href="#section-5-4" class="pilcrow">¶</a></p>
 <p id="section-5-5">It's important to remember that the client registration payload has most of its non-mandatory attributes, and that assigned values; that conflict with the present in the assertion software declaration <em>will be overridden by the values of the software statement assertion issued by the Directory of Participants</em>. Not all metadata that a client wishes to provide may be contained in a software statement, e.g alternative <a href="https://openid.net/specs/openid-connect-registration-1_0.html#LanguagesAndScripts">Metadata Languages and Script values</a>. There are some cases when the client metadata are subset os the existing values in the SSA, such as redirect_URIs.<a href="#section-5-5" class="pilcrow">¶</a></p>
 </section>
@@ -1356,29 +1471,22 @@ <h3 id="name-authorization-server">
 <p id="section-6.1-1">The Authorization Server shall support <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery</a> as required by <a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">Financial-grade API Security Profile 1.0 - Part 1: Baseline</a>.
 This support shall be explicit in Participant Directory configurations, and in the declaration of its attributes in the Discovery file (well-known), respecting the authentication mechanisms certified by the institution through the Open Banking Brazil compliance tests.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
 <p id="section-6.1-2">In addition, the Authorization Server<a href="#section-6.1-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-6.1-3">
-          <li id="section-6.1-3.1">
-            <p id="section-6.1-3.1.1">shall advertise its presence in the Open Banking Brasil ecosystem by being listed on the Directory of Participants;<a href="#section-6.1-3.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-6.1-3">
+<li id="section-6.1-3.1">shall advertise its presence in the Open Banking Brasil ecosystem by being listed on the Directory of Participants;<a href="#section-6.1-3.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-3.2">
-            <p id="section-6.1-3.2.1">shall advertise all Open Banking Brasil REST API resources protected by the OpenID Provider on the Directory of Participants;<a href="#section-6.1-3.2.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.2">shall advertise all Open Banking Brasil REST API resources protected by the OpenID Provider on the Directory of Participants;<a href="#section-6.1-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-3.3">
-            <p id="section-6.1-3.3.1">shall advertise support for all signing, encryption, authentication mechanisms and standards required to support <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">Open Banking Brasil Financial API</a>;<a href="#section-6.1-3.3.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.3">shall advertise support for all signing, encryption, authentication mechanisms and standards required to support <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">Open Banking Brasil Financial API</a>;<a href="#section-6.1-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-3.4">
-            <p id="section-6.1-3.4.1">shall advertise support for <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Dynamic Client Registration</a>;<a href="#section-6.1-3.4.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.4">shall advertise support for <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Dynamic Client Registration</a>;<a href="#section-6.1-3.4" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-3.5">
-            <p id="section-6.1-3.5.1">shall advertise <code>mtls_endpoint_aliases</code> as per clause 5 <a href="https://tools.ietf.org/html/rfc8705">RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens</a> the <code>token_endpoint</code>, <code>registration_endpoint</code> and <code>userinfo_endpoint</code>;<a href="#section-6.1-3.5.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.5">shall advertise <code>mtls_endpoint_aliases</code> as per clause 5 <a href="https://tools.ietf.org/html/rfc8705">RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens</a> the <code>token_endpoint</code>, <code>registration_endpoint</code> and <code>userinfo_endpoint</code>;<a href="#section-6.1-3.5" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-3.6">
-            <p id="section-6.1-3.6.1">if supporting <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">OAuth 2.0 Pushed Authorization Requests</a> shall advertise through <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> <code>mtls_endpoint_aliases</code> the <code>pushed_authorization_request_endpoint</code>;<a href="#section-6.1-3.6.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.6">if supporting <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">OAuth 2.0 Pushed Authorization Requests</a> shall advertise through <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> <code>mtls_endpoint_aliases</code> the <code>pushed_authorization_request_endpoint</code>;<a href="#section-6.1-3.6" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-3.7">
-            <p id="section-6.1-3.7.1">if supporting <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md">Financial API - Client Initiated Back Channel Authentication</a> shall advertise through <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> <code>mtls_endpoint_aliases</code> the <code>backchannel_authentication_endpoint</code>;<a href="#section-6.1-3.7.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.7">if supporting <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md">Financial API - Client Initiated Back Channel Authentication</a> shall advertise through <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> <code>mtls_endpoint_aliases</code> the <code>backchannel_authentication_endpoint</code>;<a href="#section-6.1-3.7" class="pilcrow">¶</a>
 </li>
-</ol>
+        </ol>
 </section>
 </div>
 <div id="client">
@@ -1388,17 +1496,14 @@ <h3 id="name-client">
         </h3>
 <p id="section-6.2-1">The Client shall support <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery</a> as required by <a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">Financial-grade API Security Profile 1.0 - Part 1: Baseline</a><a href="#section-6.2-1" class="pilcrow">¶</a></p>
 <p id="section-6.2-2">In addition, the Client<a href="#section-6.2-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-6.2-3">
-          <li id="section-6.2-3.1">
-            <p id="section-6.2-3.1.1">shall rely on ecosystem discovery services provided by Directory of Participants only;<a href="#section-6.2-3.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-6.2-3">
+<li id="section-6.2-3.1">shall rely on ecosystem discovery services provided by Directory of Participants only;<a href="#section-6.2-3.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.2-3.2">
-            <p id="section-6.2-3.2.1">shall derive necessary Authorisation Server metadata by relying on an Authorization Servers OpenID Connect Discovery services only;<a href="#section-6.2-3.2.1" class="pilcrow">¶</a></p>
+          <li id="section-6.2-3.2">shall derive necessary Authorisation Server metadata by relying on an Authorization Servers OpenID Connect Discovery services only;<a href="#section-6.2-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-6.2-3.3">
-            <p id="section-6.2-3.3.1">where present, shall use endpoints advertised in <code>mtls_endpoint_aliases</code> as per clause 5 <a href="https://tools.ietf.org/html/rfc8705">RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens</a>;<a href="#section-6.2-3.3.1" class="pilcrow">¶</a></p>
+          <li id="section-6.2-3.3">where present, shall use endpoints advertised in <code>mtls_endpoint_aliases</code> as per clause 5 <a href="https://tools.ietf.org/html/rfc8705">RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens</a>;<a href="#section-6.2-3.3" class="pilcrow">¶</a>
 </li>
-</ol>
+        </ol>
 </section>
 </div>
 </section>
@@ -1415,44 +1520,33 @@ <h3 id="name-authorization-server-2">
         </h3>
 <p id="section-7.1-1">The Authorization Server shall support the RFC RFCs Dynamic Client Registration (DCR) <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a>,  Dynamic Client Management (DCM) <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a> and <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Registration</a><a href="#section-7.1-1" class="pilcrow">¶</a></p>
 <p id="section-7.1-2">In addition, the Authorization Server<a href="#section-7.1-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-7.1-3">
-          <li id="section-7.1-3.1">
-            <p id="section-7.1-3.1.1">shall reject dynamic client registration requests not performed over a connection secured with mutual tls using certificates issued by Brazil ICP (production) or the Directory of Participants (sandbox);<a href="#section-7.1-3.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-7.1-3">
+<li id="section-7.1-3.1">shall reject dynamic client registration requests not performed over a connection secured with mutual tls using certificates issued by Brazil ICP (production) or the Directory of Participants (sandbox);<a href="#section-7.1-3.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.2">
-            <p id="section-7.1-3.2.1">shall validate that the request contains software_statement JWT signed using the <code>PS256</code> algorithim issued by the Open Banking Brasil directory of participants;<a href="#section-7.1-3.2.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.2">shall validate that the request contains software_statement JWT signed using the <code>PS256</code> algorithim issued by the Open Banking Brasil directory of participants;<a href="#section-7.1-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.3">
-            <p id="section-7.1-3.3.1">shall validate that the <code>software_statement</code> was issued (iat) not more than 5 minutes prior to the request being received;<a href="#section-7.1-3.3.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.3">shall validate that the <code>software_statement</code> was issued (iat) not more than 5 minutes prior to the request being received;<a href="#section-7.1-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.4">
-            <p id="section-7.1-3.4.1">shall validate that the attribute <code>jwks</code> (key set by value) was <strong>not</strong> included; but declared as a reference in the <code>jwks_uri</code> attribute;<a href="#section-7.1-3.4.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.4">shall validate that the attribute <code>jwks</code> (key set by value) was <strong>not</strong> included; but declared as a reference in the <code>jwks_uri</code> attribute;<a href="#section-7.1-3.4" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.5">
-            <p id="section-7.1-3.5.1">when the <code>jwks_uri</code> was informed, shall validate that matches the <code>software_jwks_uri</code> provided in the <code>software_statement</code>;<a href="#section-7.1-3.5.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.5">when the <code>jwks_uri</code> was informed, shall validate that matches the <code>software_jwks_uri</code> provided in the <code>software_statement</code>;<a href="#section-7.1-3.5" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.6">
-            <p id="section-7.1-3.6.1">shall require and validate that <code>redirect_uris</code> match or contain a sub set of software<em>redirect</em>uris provided in the <code>software_statement</code>;<a href="#section-7.1-3.6.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.6">shall require and validate that <code>redirect_uris</code> match or contain a sub set of software_redirect_uris provided in the <code>software_statement</code>;<a href="#section-7.1-3.6" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.7">
-            <p id="section-7.1-3.7.1">shall require and validate that all client authentication mechanism adhere to the requirements defined in <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a> and <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a>, validating the <code>registration_access_token</code> and using a secure connection, protected by certificate Issued from chain of certificates linked to ICP-Brasil;<a href="#section-7.1-3.7.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.7">shall require and validate that all client authentication mechanism adhere to the requirements defined in <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a> and <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a>, validating the <code>registration_access_token</code> and using a secure connection, protected by certificate Issued from chain of certificates linked to ICP-Brasil;<a href="#section-7.1-3.7" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.8">
-            <p id="section-7.1-3.8.1"><em>removed</em>;<a href="#section-7.1-3.8.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.8">
+            <em>removed</em>;<a href="#section-7.1-3.8" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.9">
-            <p id="section-7.1-3.9.1">shall validate that the requested scopes are adequate for accredited institutions and their regulatory roles and contained in the <code>software_statement</code>. The list of regulatory permissions and the corresponding scopes are described in the following sections;<a href="#section-7.1-3.9.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.9">shall validate that the requested scopes are adequate for accredited institutions and their regulatory roles and contained in the <code>software_statement</code>. The list of regulatory permissions and the corresponding scopes are described in the following sections;<a href="#section-7.1-3.9" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.10">
-            <p id="section-7.1-3.10.1">where possible, shall compare client metadata asserted by a client toward the metadata provided into  <code>software_statement</code>, choosing the values present in the SSA with precedence;<a href="#section-7.1-3.10.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.10">where possible, shall compare client metadata asserted by a client toward the metadata provided into  <code>software_statement</code>, choosing the values present in the SSA with precedence;<a href="#section-7.1-3.10" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.11">
-            <p id="section-7.1-3.11.1">shall accept all x.500 AttributeType name strings defined in the Distinguished Name of the x.509 Certificate Profiles defined in <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a>;<a href="#section-7.1-3.11.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.11">shall accept all x.500 AttributeType name strings defined in the Distinguished Name of the x.509 Certificate Profiles defined in <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a>;<a href="#section-7.1-3.11" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.12">
-            <p id="section-7.1-3.12.1">if supporting <code>tls_client_auth</code> client authentication mechanism as defined in <a href="https://tools.ietf.org/html/rfc8705">RFC8705</a> shall only accept <code>tls_client_auth_subject_dn</code>  as an indication of the certificate subject value as defined in clause 2.1.2 <a href="https://tools.ietf.org/html/rfc8705">RFC8705</a>;<a href="#section-7.1-3.12.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.12">if supporting <code>tls_client_auth</code> client authentication mechanism as defined in <a href="https://tools.ietf.org/html/rfc8705">RFC8705</a> shall only accept <code>tls_client_auth_subject_dn</code>  as an indication of the certificate subject value as defined in clause 2.1.2 <a href="https://tools.ietf.org/html/rfc8705">RFC8705</a>;<a href="#section-7.1-3.12" class="pilcrow">¶</a>
 </li>
-</ol>
+        </ol>
 <p id="section-7.1-4">These provisions apply equally to the processing of <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a>, <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a> and <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Registration</a> requests<a href="#section-7.1-4" class="pilcrow">¶</a></p>
 <div id="applying-server-defaults">
 <section id="section-7.1.1">
@@ -1460,17 +1554,14 @@ <h4 id="name-applying-server-defaults">
 <a href="#section-7.1.1" class="section-number selfRef">7.1.1. </a><a href="#name-applying-server-defaults" class="section-name selfRef">Applying Server Defaults</a>
           </h4>
 <p id="section-7.1.1-1">Where properties of a DCR request are not included and are not mandatory in the specification the Authorisation Server shall apply client defaults in the following manner<a href="#section-7.1.1-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-7.1.1-2">
-            <li id="section-7.1.1-2.1">
-              <p id="section-7.1.1-2.1.1">shall select and apply the encryption algorithm and cipher choice from the most recommended of the IANA cipher suites that is supported by the Authorisation Server;<a href="#section-7.1.1-2.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-7.1.1-2">
+<li id="section-7.1.1-2.1">shall select and apply the encryption algorithm and cipher choice from the most recommended of the IANA cipher suites that is supported by the Authorisation Server;<a href="#section-7.1.1-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.1-2.2">
-              <p id="section-7.1.1-2.2.1">shall populate defaults from values within the <code>software_statement</code> assertion where possible;<a href="#section-7.1.1-2.2.1" class="pilcrow">¶</a></p>
+            <li id="section-7.1.1-2.2">shall populate defaults from values within the <code>software_statement</code> assertion where possible;<a href="#section-7.1.1-2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.1-2.3">
-              <p id="section-7.1.1-2.3.1">shall grant the client permission to the complete set of potential scopes based on the softwares regulatory permissions included in the <code>software_statement</code>;<a href="#section-7.1.1-2.3.1" class="pilcrow">¶</a></p>
+            <li id="section-7.1.1-2.3">shall grant the client permission to the complete set of potential scopes based on the softwares regulatory permissions included in the <code>software_statement</code>;<a href="#section-7.1.1-2.3" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 </section>
 </div>
 <div id="certificate-distinguished-name-parsing">
@@ -1482,17 +1573,14 @@ <h4 id="name-certificate-distinguished-n">
 <p id="section-7.1.2-2">To address this ambiguity, the Authorization Server must accept only the AttributeTypes name strings (descriptors) defined in the last paragraph of clause 3 <a href="https://www.rfc-editor.org/rfc/rfc4514">RFC4514</a> in string format, it shall also accept in OID format, with their values in ASN.1, all the AttributeTypes defined in Distinguished Name <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a> or added by the Certificate Authority.<a href="#section-7.1.2-2" class="pilcrow">¶</a></p>
 <p id="section-7.1.2-3">In case of non-compliance with these requirements, the Authorization Server shall reject the registration.<a href="#section-7.1.2-3" class="pilcrow">¶</a></p>
 <p id="section-7.1.2-4">In terms of format, follow below how decoding should be done:<a href="#section-7.1.2-4" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-7.1.2-5.1">
-              <p id="section-7.1.2-5.1.1">Start backwards, the order is reversed from what is entered.<a href="#section-7.1.2-5.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-7.1.2-5.1">Start backwards, the order is reversed from what is entered.<a href="#section-7.1.2-5.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.2-5.2">
-              <p id="section-7.1.2-5.2.1">Append each RDN (RelativeDistinguishedName) segment with a comma ','.<a href="#section-7.1.2-5.2.1" class="pilcrow">¶</a></p>
+            <li class="compact" id="section-7.1.2-5.2">Append each RDN (RelativeDistinguishedName) segment with a comma ','.<a href="#section-7.1.2-5.2" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.2-5.3">
-              <p id="section-7.1.2-5.3.1">Use the RFC strings (CN, L, ST, O, OR, C, Street, DC, UID) with the value of their attributes in "printable string", ie human-readable + the OIDs of the attributes defined in this specification for use in Distinguished Name <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a> (businessCategory=OID 2.5.4.15,jurisdictionCountryName=OID: 1.3.6.1.4.1.311.60.2.1.3, serialNumber=OID:2.5.4.5) with the value of your attributes in ASN.1 format.<a href="#section-7.1.2-5.3.1" class="pilcrow">¶</a></p>
+            <li class="compact" id="section-7.1.2-5.3">Use the RFC strings (CN, L, ST, O, OR, C, Street, DC, UID) with the value of their attributes in "printable string", ie human-readable + the OIDs of the attributes defined in this specification for use in Distinguished Name <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a> (businessCategory=OID 2.5.4.15,jurisdictionCountryName=OID: 1.3.6.1.4.1.311.60.2.1.3, serialNumber=OID:2.5.4.5) with the value of your attributes in ASN.1 format.<a href="#section-7.1.2-5.3" class="pilcrow">¶</a>
 </li>
-</ul>
+          </ul>
 <p id="section-7.1.2-6">Examples:<a href="#section-7.1.2-6" class="pilcrow">¶</a></p>
 <table class="center" id="table-1">
             <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
@@ -1545,19 +1633,19 @@ <h3 id="name-regulatory-roles-to-openid-">
           <tbody>
             <tr>
               <td class="text-left" rowspan="1" colspan="1">DADOS</td>
-              <td class="text-left" rowspan="1" colspan="1">Institui&#231;&#227;o transmissora ou receptora de dados (AISP)</td>
+              <td class="text-left" rowspan="1" colspan="1">Institui<span class="unicode">çã (U+00E7 U+00E3)</span>o transmissora ou receptora de dados (AISP)</td>
               <td class="text-left" rowspan="1" colspan="1">openid accounts credit-cards-accounts consents customers invoice-financings financings loans unarranged-accounts-overdraft resources</td>
               <td class="text-left" rowspan="1" colspan="1">Phase 2</td>
             </tr>
             <tr>
               <td class="text-left" rowspan="1" colspan="1">PAGTO</td>
-              <td class="text-left" rowspan="1" colspan="1">Institui&#231;&#227;o prestadora de servi&#231;o de inicia&#231;&#227;o de pagamentos (PISP)</td>
-              <td class="text-left" rowspan="1" colspan="1">openid payments </td>
+              <td class="text-left" rowspan="1" colspan="1">Institui<span class="unicode">çã (U+00E7 U+00E3)</span>o prestadora de servi&#231;o de inicia<span class="unicode">çã (U+00E7 U+00E3)</span>o de pagamentos (PISP)</td>
+              <td class="text-left" rowspan="1" colspan="1">openid payments</td>
               <td class="text-left" rowspan="1" colspan="1">Phase 3</td>
             </tr>
             <tr>
               <td class="text-left" rowspan="1" colspan="1">CONTA</td>
-              <td class="text-left" rowspan="1" colspan="1">Institui&#231;&#227;o detentora de conta (ASPSP)</td>
+              <td class="text-left" rowspan="1" colspan="1">Institui<span class="unicode">çã (U+00E7 U+00E3)</span>o detentora de conta (ASPSP)</td>
               <td class="text-left" rowspan="1" colspan="1">openid</td>
               <td class="text-left" rowspan="1" colspan="1">Phase 3</td>
             </tr>
@@ -1569,6 +1657,7 @@ <h3 id="name-regulatory-roles-to-openid-">
             </tr>
           </tbody>
         </table>
+<p id="section-7.2-4">Validate the active roles in the application's <em>software_statement</em>. The information validation, shall use the field _software_statement_roles, and shall verify if their roles are actives.<a href="#section-7.2-4" class="pilcrow">¶</a></p>
 <div id="implementers-note">
 <section id="section-7.2.1">
           <h4 id="name-implementers-note">
@@ -1621,7 +1710,7 @@ <h3 id="name-software-statement-claims">
 <a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-software-statement-claims" class="section-name selfRef">Software Statement Claims</a>
         </h3>
 <p id="section-8.1-1">The following example contains all of the claims currently included in a software statement<a href="#section-8.1-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-8.1-2">
+<div class="alignLeft art-text artwork" id="section-8.1-2">
 <pre>{
   "software_mode": "Live",
   "software_redirect_uris": [
@@ -1707,7 +1796,128 @@ <h3 id="name-software-statement-claims">
       <h2 id="name-dynamic-client-registration">
 <a href="#section-9" class="section-number selfRef">9. </a><a href="#name-dynamic-client-registration" class="section-name selfRef">Dynamic Client Registration Request Processing</a>
       </h2>
-	  	  	  <p><img src="images/dynamic-client-registration.png" alt="Dynamic Client Registration Request Processing" /></p>
+<figure id="figure-1">
+        <div class="alignLeft art-svg artwork" id="section-9-1.1">
+<svg xmlns="http://www.w3.org/2000/svg" contentstyletype="text/css" height="auto" preserveAspectRatio="none" style="width:100%;height:auto;background:#FFFFFF;" version="1.1" viewBox="0 0 1153 906" width="100%" zoomAndPan="magnify">
+            <desc>Dynamic Client Registration</desc>
+            <g>
+              <rect height="26.2969" style="stroke:#00000000;stroke-width:1.0;fill:none;" width="238" x="456.75" y="10"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" font-weight="bold" lengthAdjust="spacing" textLength="228" x="461.75" y="27.9951" style="white-space: pre;">Dynamic Client Registration</text>
+              <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="298" x2="298" y1="73.5938" y2="870.9141"></line>
+              <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="482" x2="482" y1="73.5938" y2="870.9141"></line>
+              <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="624" x2="624" y1="73.5938" y2="870.9141"></line>
+              <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="746" x2="746" y1="73.5938" y2="870.9141"></line>
+              <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="877" x2="877" y1="73.5938" y2="870.9141"></line>
+              <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="1109.5" x2="1109.5" y1="73.5938" y2="870.9141"></line>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="41" x="278" y="42.2969"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="27" x="285" y="62.292" style="white-space: pre;">TPP</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="41" x="278" y="869.9141"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="27" x="285" y="889.9092" style="white-space: pre;">TPP</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="101" x="432" y="42.2969"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="87" x="439" y="62.292" style="white-space: pre;">DirectoryAS</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="101" x="432" y="869.9141"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="87" x="439" y="889.9092" style="white-space: pre;">DirectoryAS</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="105" x="572" y="42.2969"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="91" x="579" y="62.292" style="white-space: pre;">DirectoryAPI</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="105" x="572" y="869.9141"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="91" x="579" y="889.9092" style="white-space: pre;">DirectoryAPI</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="119" x="687" y="42.2969"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="105" x="694" y="62.292" style="white-space: pre;">DirectoryJWKS</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="119" x="687" y="869.9141"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="105" x="694" y="889.9092" style="white-space: pre;">DirectoryJWKS</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="69" x="843" y="42.2969"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="55" x="850" y="62.292" style="white-space: pre;">BankAS</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="69" x="843" y="869.9141"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="55" x="850" y="889.9092" style="white-space: pre;">BankAS</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="76" x="1071.5" y="42.2969"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="62" x="1078.5" y="62.292" style="white-space: pre;">ICPBrasil</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="76" x="1071.5" y="869.9141"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="62" x="1078.5" y="889.9092" style="white-space: pre;">ICPBrasil</text>
+              <polygon fill="#181818" points="470.5,100.7266,480.5,104.7266,470.5,108.7266,474.5,104.7266" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="476.5" y1="104.7266" y2="104.7266"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="160" x="305.5" y="99.6606" style="white-space: pre;">OAuth 2.0 tls_client_auth</text>
+              <path d="M110,117.7266 L110,157.7266 L293,157.7266 L293,127.7266 L283,117.7266 L110,117.7266 " fill="#FEFFDD" style="stroke:#181818;stroke-width:0.5;"></path>
+              <path d="M283,117.7266 L283,127.7266 L293,127.7266 L283,117.7266 " fill="#FEFFDD" style="stroke:#181818;stroke-width:0.5;"></path>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="152" x="116" y="134.7935" style="white-space: pre;">Client Credentials Grant</text>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="162" x="116" y="149.9263" style="white-space: pre;">Scope directory:software</text>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="482.5" x2="524.5" y1="184.125" y2="184.125"></line>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="524.5" x2="524.5" y1="184.125" y2="197.125"></line>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="483.5" x2="524.5" y1="197.125" y2="197.125"></line>
+              <polygon fill="#181818" points="493.5,193.125,483.5,197.125,493.5,201.125,489.5,197.125" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="122" x="489.5" y="179.0591" style="white-space: pre;">Validate Certificate</text>
+              <polygon fill="#181818" points="1097.5,222.2578,1107.5,226.2578,1097.5,230.2578,1101.5,226.2578" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="482.5" x2="1103.5" y1="226.2578" y2="226.2578"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="160" x="489.5" y="221.1919" style="white-space: pre;">Check Revocation Status</text>
+              <polygon fill="#181818" points="493.5,251.3906,483.5,255.3906,493.5,259.3906,489.5,255.3906" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="487.5" x2="1108.5" y1="255.3906" y2="255.3906"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="88" x="499.5" y="250.3247" style="white-space: pre;">Certificate OK</text>
+              <polygon fill="#181818" points="309.5,280.5234,299.5,284.5234,309.5,288.5234,305.5,284.5234" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="481.5" y1="284.5234" y2="284.5234"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="88" x="315.5" y="279.4575" style="white-space: pre;">Access Token</text>
+              <polygon fill="#181818" points="612.5,309.6563,622.5,313.6563,612.5,317.6563,616.5,313.6563" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="618.5" y1="313.6563" y2="313.6563"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="302" x="305.5" y="308.5903" style="white-space: pre;">Retrieve Authorisation Servers + Access Token</text>
+              <polygon fill="#181818" points="309.5,338.7891,299.5,342.7891,309.5,346.7891,305.5,342.7891" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="623.5" y1="342.7891" y2="342.7891"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="138" x="315.5" y="337.7231" style="white-space: pre;">Authorisation Servers</text>
+              <polygon fill="#181818" points="865.5,367.9219,875.5,371.9219,865.5,375.9219,869.5,371.9219" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="871.5" y1="371.9219" y2="371.9219"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="195" x="305.5" y="366.856" style="white-space: pre;">Retrieve OpenID Configuration</text>
+              <polygon fill="#181818" points="309.5,397.0547,299.5,401.0547,309.5,405.0547,305.5,401.0547" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="876.5" y1="401.0547" y2="401.0547"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="221" x="315.5" y="395.9888" style="white-space: pre;">JSON OpenID Discovery Clause 4.2</text>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="340.5" y1="430.1875" y2="430.1875"></line>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="340.5" x2="340.5" y1="430.1875" y2="443.1875"></line>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="299.5" x2="340.5" y1="443.1875" y2="443.1875"></line>
+              <polygon fill="#181818" points="309.5,439.1875,299.5,443.1875,309.5,447.1875,305.5,443.1875" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="165" x="305.5" y="425.1216" style="white-space: pre;">Extract Desired MetaData</text>
+              <polygon fill="#181818" points="612.5,468.3203,622.5,472.3203,612.5,476.3203,616.5,472.3203" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="618.5" y1="472.3203" y2="472.3203"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="83" x="305.5" y="467.2544" style="white-space: pre;">Retrieve SSA</text>
+              <polygon fill="#181818" points="309.5,497.4531,299.5,501.4531,309.5,505.4531,305.5,501.4531" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="623.5" y1="501.4531" y2="501.4531"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="54" x="315.5" y="496.3872" style="white-space: pre;">SSA JWT</text>
+              <polygon fill="#181818" points="865.5,526.5859,875.5,530.5859,865.5,534.5859,869.5,530.5859" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="871.5" y1="530.5859" y2="530.5859"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="332" x="305.5" y="525.52" style="white-space: pre;">Post RFC7591 with SSA JWT as software_statement</text>
+              <polygon fill="#181818" points="1097.5,555.7188,1107.5,559.7188,1097.5,563.7188,1101.5,559.7188" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="877.5" x2="1103.5" y1="559.7188" y2="559.7188"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="160" x="884.5" y="554.6528" style="white-space: pre;">Check Revocation Status</text>
+              <polygon fill="#181818" points="888.5,584.8516,878.5,588.8516,888.5,592.8516,884.5,588.8516" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="882.5" x2="1108.5" y1="588.8516" y2="588.8516"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="88" x="894.5" y="583.7856" style="white-space: pre;">Certificate OK</text>
+              <polygon fill="#181818" points="757.5,613.9844,747.5,617.9844,757.5,621.9844,753.5,617.9844" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="751.5" x2="876.5" y1="617.9844" y2="617.9844"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="107" x="763.5" y="612.9185" style="white-space: pre;">Retrieve Key Set</text>
+              <polygon fill="#181818" points="865.5,643.1172,875.5,647.1172,865.5,651.1172,869.5,647.1172" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="746.5" x2="871.5" y1="647.1172" y2="647.1172"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="96" x="753.5" y="642.0513" style="white-space: pre;">Return Key Set</text>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="877.5" x2="919.5" y1="676.25" y2="676.25"></line>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="919.5" x2="919.5" y1="676.25" y2="689.25"></line>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="878.5" x2="919.5" y1="689.25" y2="689.25"></line>
+              <polygon fill="#181818" points="888.5,685.25,878.5,689.25,888.5,693.25,884.5,689.25" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="218" x="884.5" y="671.1841" style="white-space: pre;">Validate SSA in RFC 7591 Request</text>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="877.5" x2="919.5" y1="718.3828" y2="718.3828"></line>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="919.5" x2="919.5" y1="718.3828" y2="731.3828"></line>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="878.5" x2="919.5" y1="731.3828" y2="731.3828"></line>
+              <polygon fill="#181818" points="888.5,727.3828,878.5,731.3828,888.5,735.3828,884.5,731.3828" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="170" x="884.5" y="713.3169" style="white-space: pre;">Validate RFC7591 Request</text>
+              <path d="M5,744.3828 L5,784.3828 L294,784.3828 L294,754.3828 L284,744.3828 L5,744.3828 " fill="#FEFFDD" style="stroke:#181818;stroke-width:0.5;"></path>
+              <path d="M284,744.3828 L284,754.3828 L294,754.3828 L284,744.3828 " fill="#FEFFDD" style="stroke:#181818;stroke-width:0.5;"></path>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="268" x="11" y="761.4497" style="white-space: pre;">Request must be made to token endpoint</text>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="154" x="11" y="776.5825" style="white-space: pre;">secured with mutual tls.</text>
+              <polygon fill="#181818" points="309.5,806.7813,299.5,810.7813,309.5,814.7813,305.5,810.7813" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="876.5" y1="810.7813" y2="810.7813"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="448" x="315.5" y="805.7153" style="white-space: pre;">Return RFC7591 Client Configuration +   RFC7592 Management Token</text>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="340.5" y1="839.9141" y2="839.9141"></line>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="340.5" x2="340.5" y1="839.9141" y2="852.9141"></line>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="299.5" x2="340.5" y1="852.9141" y2="852.9141"></line>
+              <polygon fill="#181818" points="309.5,848.9141,299.5,852.9141,309.5,856.9141,305.5,852.9141" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="163" x="305.5" y="834.8481" style="white-space: pre;">Save Management Token</text>
+            </g>
+          </svg>
+        </div>
+<figcaption><a href="#figure-1" class="selfRef">Figure 1</a></figcaption></figure>
 <div id="posting-a-request-with-a-software-statement">
 <section id="section-9.1">
         <h3 id="name-posting-a-request-with-a-so">
@@ -1715,7 +1925,7 @@ <h3 id="name-posting-a-request-with-a-so">
         </h3>
 <p id="section-9.1-1">This example includes various optional fields, some of which may not be applicable to some deployments. For a complete guide to the attributes and their requirements, consult the Swagger DCR/DCM link: <a href="https://raw.githubusercontent.com/OpenBanking-Brasil/specs-seguranca/main/dcr_review/dcr-dcm-swagger.yaml">OBB-DCR/DCM-Swagger</a> .
 Line wraps within values are for display purposes only.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-9.1-2">
+<div class="alignLeft art-text artwork" id="section-9.1-2">
 <pre>POST /reg HTTP/1.1
 Host: auth.raidiam.com
 Content-Type: application/json
@@ -1781,17 +1991,14 @@ <h3 id="name-about-authentication-and-au">
           <h4 id="name-client-registration-post-re">
 <a href="#section-9.3.1" class="section-number selfRef">9.3.1. </a><a href="#name-client-registration-post-re" class="section-name selfRef">Client registration - POST /register</a>
           </h4>
-<ol start="1" type="1" class="normal type-1" id="section-9.3.1-1">
-            <li id="section-9.3.1-1.1">
-              <p id="section-9.3.1-1.1.1">validate that the certificate presented by the client application is subordinate to the ICP-Brasil chains defined in the Open Banking Brasil Certificates Standard;<a href="#section-9.3.1-1.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-9.3.1-1">
+<li id="section-9.3.1-1.1">validate that the certificate presented by the client application is subordinate to the ICP-Brasil chains defined in the Open Banking Brasil Certificates Standard;<a href="#section-9.3.1-1.1" class="pilcrow">¶</a>
 </li>
-<li id="section-9.3.1-1.2">
-              <p id="section-9.3.1-1.2.1">ensure that the signature of the <code>software_statement</code>_ presented by the client application during registration has been made by the Directory of Participants using the public keys described in the previous section;<a href="#section-9.3.1-1.2.1" class="pilcrow">¶</a></p>
+            <li id="section-9.3.1-1.2">ensure that the signature of the <code>software_statement</code>_ presented by the client application during registration has been made by the Directory of Participants using the public keys described in the previous section;<a href="#section-9.3.1-1.2" class="pilcrow">¶</a>
 </li>
-<li id="section-9.3.1-1.3">
-              <p id="section-9.3.1-1.3.1">ensure that the <code>software_statement</code> presented by the client application during registration corresponds to the same institution as the client certificate presented, validating it through the attributes that bring <code>organization_id</code> in the X.509 certificate.<a href="#section-9.3.1-1.3.1" class="pilcrow">¶</a></p>
+            <li id="section-9.3.1-1.3">ensure that the <code>software_statement</code> presented by the client application during registration corresponds to the same institution as the client certificate presented, validating it through the attributes that bring <code>organization_id</code> in the X.509 certificate.<a href="#section-9.3.1-1.3" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 </section>
 </div>
 <div id="client-maintenance-get-register-put-register-delete-register">
@@ -1799,14 +2006,13 @@ <h4 id="name-client-registration-post-re">
           <h4 id="name-client-maintenance-get-regi">
 <a href="#section-9.3.2" class="section-number selfRef">9.3.2. </a><a href="#name-client-maintenance-get-regi" class="section-name selfRef">Client Maintenance - GET /register - PUT /register - DELETE /register</a>
           </h4>
-<ol start="1" type="1" class="normal type-1" id="section-9.3.2-1">
-            <li id="section-9.3.2-1.1">
-              <p id="section-9.3.2-1.1.1">validate that the certificate presented by the client application is subordinate to the ICP-Brasil chains defined in the Open Banking Brasil Certificates Standard;<a href="#section-9.3.2-1.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-9.3.2-1">
+<li id="section-9.3.2-1.1">validate that the certificate presented by the client application is subordinate to the ICP-Brasil chains defined in the Open Banking Brasil Certificates Standard;<a href="#section-9.3.2-1.1" class="pilcrow">¶</a>
 </li>
-<li id="section-9.3.2-1.2">
-              <p id="section-9.3.2-1.2.1">Validate the presence and matching of the Bearer header <code>Authorization</code> containing the value of the <code>registration_access_token</code> attribute returned during registration of the corresponding client.<a href="#section-9.3.2-1.2.1" class="pilcrow">¶</a></p>
+            <li id="section-9.3.2-1.2">Validate the presence and matching of the Bearer header <code>Authorization</code> containing the value of the <code>registration_access_token</code> attribute returned during registration of the corresponding client.<a href="#section-9.3.2-1.2" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
+<p id="section-9.3.2-2">Note: <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a> provides the possibility of rotating the <code>registration_access_token</code> issued by the Authorization Server with each use, making it a single-use token. When registering their client applications, institutions should consider this aspect to receive and update the <code>registration_access_token</code> for the new value received in client maintenance (DCM) operations.<a href="#section-9.3.2-2" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -1820,75 +2026,56 @@ <h2 id="name-acknowledgement">
       </h2>
 <p id="section-10-1">With thanks to all who have set the foundations for secure and safe data sharing through the formation of the OpenID Foundation FAPI Working Group, the Open Banking Brasil GT Security and to the pioneers who will stand on their shoulders.<a href="#section-10-1" class="pilcrow">¶</a></p>
 <p id="section-10-2">The following people contributed to this document:<a href="#section-10-2" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-10-3.1">
-          <p id="section-10-3.1.1">Ralph Bragg (Raidiam)<a href="#section-10-3.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-10-3.1">Alexandre Daniel Dalabrida (Cooperativa Central Ailos)<a href="#section-10-3.1" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-10-3.2">Alexandre Siqueira (Mercado Pago)<a href="#section-10-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.2">
-          <p id="section-10-3.2.1">Alexandre Siqueira (Mercado Pago)<a href="#section-10-3.2.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.3">Andr&#233; Borges (Banco Fibra)<a href="#section-10-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.3">
-          <p id="section-10-3.3.1">Bernardo Vale (Banco Inter)<a href="#section-10-3.3.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.4">Bernardo Vale (Banco Inter)<a href="#section-10-3.4" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.4">
-          <p id="section-10-3.4.1">Andr&#233; Borges (Banco Fibra)<a href="#section-10-3.4.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.5">Danilo Sasaki (Banco Ita&#250;)<a href="#section-10-3.5" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.5">
-          <p id="section-10-3.5.1">Danilo Sasaki (Banco Ita&#250;)<a href="#section-10-3.5.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.6">Jo&#227;o Rodolfo Vieira da Silva (Banco Ita&#250;)<a href="#section-10-3.6" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.6">
-          <p id="section-10-3.6.1">Jo&#227;o Rodolfo Vieira da Silva (Banco Ita&#250;)<a href="#section-10-3.6.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.7">Michelle Bandarra (Chicago)<a href="#section-10-3.7" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.7">
-          <p id="section-10-3.7.1">Michelle Bandarra (Chicago)<a href="#section-10-3.7.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.8">Nic Marcondes (Quanto)<a href="#section-10-3.8" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.8">
-          <p id="section-10-3.8.1">Alexandre Daniel Dalabrida (Cooperativa Central Ailos)<a href="#section-10-3.8.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.9">Rafael Gonzalez Hashimoto (Banco C6)<a href="#section-10-3.9" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.9">
-          <p id="section-10-3.9.1">Rafael Gonzalez Hashimoto - (Banco C6)<a href="#section-10-3.9.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.10">Ralph Bragg (Raidiam)<a href="#section-10-3.10" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 </section>
 </div>
 <div id="notices">
-<section id="section-appendix.a">
+<section id="appendix-A">
       <h2 id="name-notices">
-<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-notices" class="section-name selfRef">Notices</a>
+<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-notices" class="section-name selfRef">Notices</a>
       </h2>
-<p id="section-appendix.a-1">Copyright (c) 2021 Open Banking Brasil Initial Structure.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
-<p id="section-appendix.a-2">The Open Banking Brasil Initial Structure (OBBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OBBIS as the source of the material, but that such attribution does not indicate an endorsement by the OBBIS.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
-<p id="section-appendix.a-3">The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation, the Open Banking Brasil GT Security Working Group and others. Although the Open Banking Brasil Initial Structure has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The Open Banking Brasil Initial Structure and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The Open Banking Brasil Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The Open Banking Brasil Initial Structure invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
+<p id="appendix-A-1">Copyright (c) 2022 Open Banking Brasil Initial Structure.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
+<p id="appendix-A-2">The Open Banking Brasil Initial Structure (OBBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OBBIS as the source of the material, but that such attribution does not indicate an endorsement by the OBBIS.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
+<p id="appendix-A-3">The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation, the Open Banking Brasil GT Security Working Group and others. Although the Open Banking Brasil Initial Structure has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The Open Banking Brasil Initial Structure and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The Open Banking Brasil Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The Open Banking Brasil Initial Structure invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.<a href="#appendix-A-3" class="pilcrow">¶</a></p>
 <div id="appendix-a-example-software-statement-assertion">
-<section id="section-a.1">
-        <h2 id="name-appendix-a-example-software">
-<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-appendix-a-example-software" class="section-name selfRef">Appendix A. Example Software Statement Assertion</a>
-        </h2>
-<div class="artwork art-text alignLeft" id="section-a.1-1">
+<section id="appendix-A.1">
+        <h3 id="name-appendix-a-example-software">
+<a href="#appendix-A.1" class="section-number selfRef">A.1. </a><a href="#name-appendix-a-example-software" class="section-name selfRef">Appendix A. Example Software Statement Assertion</a>
+        </h3>
+<div class="alignLeft art-text artwork" id="appendix-A.1-1">
 <pre>eyJraWQiOiJzaWduZXIiLCJ0eXAiOiJKV1QiLCJhbGciOiJQUzI1NiJ9.eyJzb2Z0d2FyZV9tb2RlIjoiTGl2ZSIsInNvZnR3YXJlX3JlZGlyZWN0X3VyaXMiOlsiaHR0cHM6XC9cL3d3dy5yYWlkaWFtLmNvbVwvYWNjb3VudGluZ1wvY2IiXSwic29mdHdhcmVfc3RhdGVtZW50X3JvbGVzIjpbeyJyb2xlIjoiREFET1MiLCJhdXRob3Jpc2F0aW9uX2RvbWFpbiI6Ik9wZW4gQmFua2luZyIsInN0YXR1cyI6IkFjdGl2ZSJ9LHsicm9sZSI6IlBBR1RPIiwiYXV0aG9yaXNhdGlvbl9kb21haW4iOiJPcGVuIEJhbmtpbmciLCJzdGF0dXMiOiJBY3RpdmUifV0sInNvZnR3YXJlX2NsaWVudF9uYW1lIjoiUmFpZGlhbSBBY2NvdW50aW5nIiwib3JnX3N0YXR1cyI6IkFjdGl2ZSIsInNvZnR3YXJlX2NsaWVudF9pZCI6IkNraTFFYnZqd3loUEIxMk5HTGx6MiIsImlzcyI6Ik9wZW4gQmFua2luZyBPcGVuIEJhbmtpbmcgQnJhc2lsIHByb2QgU1NBIGlzc3VlciIsInNvZnR3YXJlX3Rvc191cmkiOiJodHRwczpcL1wvd3d3LnJhaWRpYW0uY29tXC9hY2NvdW50aW5nXC90b3MuaHRtbCIsInNvZnR3YXJlX2NsaWVudF9kZXNjcmlwdGlvbiI6IlJhaWRpYW0gQWNjb3VudGluZyBsZXZlcmFnZSBjdXR0aW5nIGVkZ2Ugb3BlbiBiYW5raW5nIGFjY2VzcyB0byBicmluZyB5b3UgcmVhbCB0aW1lIHVwIHRvIGRhdGUgdmlld3Mgb2YgeW91ciBmaW5hbmNlcyIsInNvZnR3YXJlX2p3a3NfZW5kcG9pbnQiOiJodHRwczpcL1wva2V5c3RvcmUuZGlyZWN0b3J5Lm9wZW5iYW5raW5nYnJhc2lsLm9yZy5iclwvYjk2MWM0ZWItNTA5ZC00ZWRmLWFmZWItMzU2NDJiMzgxODVkXC8yNTU1NmQ1YS1iOWRkLTRlMjctYWExYS1jY2U3MzJmZTc0ZGVcL2FwcGxpY2F0aW9uLmp3a3MiLCJzb2Z0d2FyZV9wb2xpY3lfdXJpIjoiaHR0cHM6XC9cL3d3dy5yYWlkaWFtLmNvbVwvYWNjb3VudGluZ1wvcG9saWN5Lmh0bWwiLCJzb2Z0d2FyZV9pZCI6IjI1NTU2ZDVhLWI5ZGQtNGUyNy1hYTFhLWNjZTczMmZlNzRkZSIsInNvZnR3YXJlX2NsaWVudF91cmkiOiJodHRwczpcL1wvd3d3LnJhaWRpYW0uY29tXC9hY2NvdW50aW5nLmh0bWwiLCJzb2Z0d2FyZV9qd2tzX2luYWN0aXZlX2VuZHBvaW50IjoiaHR0cHM6XC9cL2tleXN0b3JlLmRpcmVjdG9yeS5vcGVuYmFua2luZ2JyYXNpbC5vcmcuYnJcL2I5NjFjNGViLTUwOWQtNGVkZi1hZmViLTM1NjQyYjM4MTg1ZFwvMjU1NTZkNWEtYjlkZC00ZTI3LWFhMWEtY2NlNzMyZmU3NGRlXC9pbmFjdGl2ZVwvYXBwbGljYXRpb24uandrcyIsInNvZnR3YXJlX2p3a3NfdHJhbnNwb3J0X2luYWN0aXZlX2VuZHBvaW50IjoiaHR0cHM6XC9cL2tleXN0b3JlLmRpcmVjdG9yeS5vcGVuYmFua2luZ2JyYXNpbC5vcmcuYnJcL2I5NjFjNGViLTUwOWQtNGVkZi1hZmViLTM1NjQyYjM4MTg1ZFwvMjU1NTZkNWEtYjlkZC00ZTI3LWFhMWEtY2NlNzMyZmU3NGRlXC9pbmFjdGl2ZVwvdHJhbnNwb3J0Lmp3a3MiLCJzb2Z0d2FyZV9qd2tzX3RyYW5zcG9ydF9lbmRwb2ludCI6Imh0dHBzOlwvXC9rZXlzdG9yZS5kaXJlY3Rvcnkub3BlbmJhbmtpbmdicmFzaWwub3JnLmJyXC9iOTYxYzRlYi01MDlkLTRlZGYtYWZlYi0zNTY0MmIzODE4NWRcLzI1NTU2ZDVhLWI5ZGQtNGUyNy1hYTFhLWNjZTczMmZlNzRkZVwvdHJhbnNwb3J0Lmp3a3MiLCJzb2Z0d2FyZV9sb2dvX3VyaSI6Imh0dHBzOlwvXC93d3cucmFpZGlhbS5jb21cL2FjY291bnRpbmdcL2xvZ28ucG5nIiwib3JnX2lkIjoiYjk2MWM0ZWItNTA5ZC00ZWRmLWFmZWItMzU2NDJiMzgxODVkIiwic29mdHdhcmVfZW52aXJvbm1lbnQiOiJwcm9kdWN0aW9uIiwic29mdHdhcmVfdmVyc2lvbiI6MS4xMCwic29mdHdhcmVfcm9sZXMiOlsiREFET1MiLCJQQUdUTyJdLCJvcmdfbmFtZSI6Ik9wZW4gQmFua2luZyBCcmFzaWwiLCJpYXQiOjE2MTgzMzYyNjIsIm9yZ2FuaXNhdGlvbl9jb21wZXRlbnRfYXV0aG9yaXR5X2NsYWltcyI6W3siYXV0aG9yaXNhdGlvbl9kb21haW4iOiJPcGVuIEJhbmtpbmciLCJhdXRob3Jpc2F0aW9ucyI6W10sInJlZ2lzdHJhdGlvbl9pZCI6IjEzMzUzMjM2LU9CQi1DT05UQSIsImF1dGhvcml0eV9pZCI6IjY4N2ExYzk0LWIzNjAtNGUwNC05NTg5LTBmYTVjYjE2NDUxYiIsImF1dGhvcmlzYXRpb25fcm9sZSI6IkNPTlRBIiwiYXV0aG9yaXR5X2NvZGUiOiJCQ0IiLCJzdGF0dXMiOiJBY3RpdmUifSx7ImF1dGhvcmlzYXRpb25fZG9tYWluIjoiT3BlbiBCYW5raW5nIiwiYXV0aG9yaXNhdGlvbnMiOltdLCJyZWdpc3RyYXRpb25faWQiOiIxMzM1MzIzNi1PQkItREFET1MiLCJhdXRob3JpdHlfaWQiOiI2ODdhMWM5NC1iMzYwLTRlMDQtOTU4OS0wZmE1Y2IxNjQ1MWIiLCJhdXRob3Jpc2F0aW9uX3JvbGUiOiJEQURPUyIsImF1dGhvcml0eV9jb2RlIjoiQkNCIiwic3RhdHVzIjoiQWN0aXZlIn0seyJhdXRob3Jpc2F0aW9uX2RvbWFpbiI6Ik9wZW4gQmFua2luZyIsImF1dGhvcmlzYXRpb25zIjpbXSwicmVnaXN0cmF0aW9uX2lkIjoiMTMzNTMyMzYtT0JCLVBBR1RPIiwiYXV0aG9yaXR5X2lkIjoiNjg3YTFjOTQtYjM2MC00ZTA0LTk1ODktMGZhNWNiMTY0NTFiIiwiYXV0aG9yaXNhdGlvbl9yb2xlIjoiUEFHVE8iLCJhdXRob3JpdHlfY29kZSI6IkJDQiIsInN0YXR1cyI6IkFjdGl2ZSJ9XX0.W6hUAYhjT6I61rxEIVMKYKre93LTbRdzKnk9dJvUdzVgAz5B9KxZNutf27oO3k0hrjYVWBdWq23o_e4Y_AaKdpS9-rtU84JiHtmqV0wcFYIM8nqcUVWqQ-Ux6Nq9L2G-s2YNd3PcJ1e3yGg9h8553Gr7iJusKEgApzXUpkM2rBELQuumktUE_JBiuIkXmWxoRnO1cW-Osbk3MT3bxG43SPcxii07Q5S8qXI6PjCPA3fYlnaUAygwZM3O0oa7jqmSr7d9UsHuDMJfYhIKdq2wyQQKORCN-D2UopmMX-lHMvAVkkrAO08T0-7odjr4PJk-PrwuoCxeAfa7440ZDOrlmQ
-</pre><a href="#section-a.1-1" class="pilcrow">¶</a>
+</pre><a href="#appendix-A.1-1" class="pilcrow">¶</a>
 </div>
 </section>
 </div>
 </section>
 </div>
 <div id="authors-addresses">
-<section id="section-appendix.b">
-      <h2 id="name-authors-addresses">
-<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
+<section id="appendix-B">
+      <h2 id="name-authors-address">
+<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
       </h2>
-<address class="vcard">
-        <div dir="auto" class="left"><span class="fn nameRole">Ralph Bragg</span></div>
-<div dir="auto" class="left"><span class="org">Raidiam</span></div>
-<div class="email">
-<span>Email:</span>
-<a href="mailto:ralph.bragg@raidiam.com" class="email">ralph.bragg@raidiam.com</a>
-</div>
-<div class="url">
-<span>URI:</span>
-<a href="https://www.raidiam.com/" class="url">https://www.raidiam.com/</a>
-</div>
-</address>
 <address class="vcard">
         <div dir="auto" class="left"><span class="fn nameRole">OBBIS GT Security</span></div>
 <div dir="auto" class="left"><span class="org">Open Banking Brasil Initial Structure</span></div>
diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2.md b/open-banking-brasil-dynamic-client-registration-1_ID2.md
index ebe73cd..15c9249 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2.md
@@ -17,16 +17,6 @@
     status = "standard"
     value = "open-banking-brasil-dynamic-client-registration-1_ID2"
 
-    [[author]]
-    initials = "R."
-    surname = "Bragg"
-    fullname = "Ralph Bragg"
-    organization = "Raidiam"
-    abbrev = "Raidiam"
-      [author.address]
-      email = "ralph.bragg@raidiam.com"
-      uri = "https://www.raidiam.com/"
-
     [[author]]
     initials = "GT"
     surname = "Security"
@@ -158,23 +148,15 @@ For the purpose of this document, the terms defined in [RFC6749], [RFC6750], [RF
 
 # Symbols and Abbreviated terms
 
-**SSA** – Software Statement Assertion
-
-**SS** – Software Statement
-
-**DCR** – Dynamic Client Registration
-
-**API** – Application Programming Interface
-
-**FAPI** - Financial-grade API
-
-**HTTP** – Hyper Text Transfer Protocol
-
-**OIDF** - OpenID Foundation
-
-**REST** – Representational State Transfer
-
-**TLS** – Transport Layer Security
+* **API** – Application Programming Interface
+* **DCR** – Dynamic Client Registration
+* **FAPI** - Financial-grade API
+* **HTTP** – Hyper Text Transfer Protocol
+* **OIDF** - OpenID Foundation
+* **REST** – Representational State Transfer
+* **SS** – Software Statement
+* **SSA** – Software Statement Assertion
+* **TLS** – Transport Layer Security
 
 # Introduction
 
@@ -264,12 +246,12 @@ In terms of format, follow below how decoding should be done:
 
 Examples:
 
-| subject_dn | Issuer |
-| --- | --- |
-| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839, CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L= BRASILIA, ST=DF, C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
-| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, CN=mycn.bank.gov.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L=BRASILIA, ST=DF, C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, UID=67c57882-043b-11ec-9a03-0242ac130003, CN=openbanking.mybank.com.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Goiania, ST=GO, O=MyBank SA, C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| CN=mycn.bank.com.br, UID=67c57882-043b-11ec-9a03-0242ac130003, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Sao Paulo, ST=SP, O=MyBank SA, C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| subject_dn                                                                                                                                                                                                                                                                                | Issuer                                                                                                                 |
+|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839, CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L= BRASILIA, ST=DF, C=BR   | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR                          |
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, CN=mycn.bank.gov.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L=BRASILIA, ST=DF, C=BR    | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, UID=67c57882-043b-11ec-9a03-0242ac130003, CN=openbanking.mybank.com.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Goiania, ST=GO, O=MyBank SA, C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR                         |
+| CN=mycn.bank.com.br, UID=67c57882-043b-11ec-9a03-0242ac130003, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Sao Paulo, ST=SP, O=MyBank SA, C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e         | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR                         |
 
 ## Regulatory Roles to OpenID and OAuth 2.0 Mappings
 
@@ -277,12 +259,12 @@ To participate in the Open Banking ecosystem, accredited institutions must regis
 
 The following table describes the regulatory roles for Open Banking and the related OAuth 2.0 scopes mapping. If the scopes are omitted during the DCR process, the authorization server shall grant the complete set of potential scopes based on the registering bank's regulatory roles, as described in the Server Defaults section.
 
-| Regulatory Role | Description | Allowed Scopes | Target Phase|
-| --- | --- | --- | --- |
-| DADOS | Instituição transmissora ou receptora de dados (AISP) | openid accounts credit-cards-accounts consents customers invoice-financings financings loans unarranged-accounts-overdraft resources | Phase 2 |
-| PAGTO | Instituição prestadora de serviço de iniciação de pagamentos (PISP) | openid payments | Phase 3 |
-| CONTA | Instituição detentora de conta (ASPSP) | openid | Phase 3 |
-| CCORR | Correspondente de crédito | openid | Phase 3* |
+| Regulatory Role | Description                                                         | Allowed Scopes                                                                                                                       | Target Phase |
+|-----------------|---------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|--------------|
+| DADOS           | Instituição transmissora ou receptora de dados (AISP)               | openid accounts credit-cards-accounts consents customers invoice-financings financings loans unarranged-accounts-overdraft resources | Phase 2      |
+| PAGTO           | Instituição prestadora de serviço de iniciação de pagamentos (PISP) | openid payments                                                                                                                      | Phase 3      |
+| CONTA           | Instituição detentora de conta (ASPSP)                              | openid                                                                                                                               | Phase 3      |
+| CCORR           | Correspondente de crédito                                           | openid                                                                                                                               | Phase 3*     |
 
 Validate the active roles in the application's _software\_statement_. The information validation, shall use the field _software\_statement\_roles, and shall verify if their roles are actives.
 
@@ -292,10 +274,10 @@ In line with guidance from the IETF and the direction of travel for fine-grained
 
 ## Regulatory Roles to dynamic OAuth 2.0 scope Mappings
 
-| Regulatory Role | Allowed Scopes |
-| --- | --- |
-| DADOS | consent:{ConsentId} |
-| PAGTO | consent:{ConsentId} |
+| Regulatory Role | Allowed Scopes      |
+|-----------------|---------------------|
+| DADOS           | consent:{ConsentId} |
+| PAGTO           | consent:{ConsentId} |
 
 # Software Statement
 
@@ -385,7 +367,7 @@ The following example contains all of the claims currently included in a softwar
 # Dynamic Client Registration Request Processing
 
 !---
-![Dynamic Client Registration](images/dynamic-client-registration.png)
+![Dynamic Client Registration](images/dynamic-client-registration.svg)
 !---
 
 ## Posting a request with a software statement
@@ -468,21 +450,22 @@ With thanks to all who have set the foundations for secure and safe data sharing
 
 The following people contributed to this document:
 
-* Ralph Bragg (Raidiam)
+* Alexandre Daniel Dalabrida (Cooperativa Central Ailos)
 * Alexandre Siqueira (Mercado Pago)
-* Bernardo Vale (Banco Inter)
 * André Borges (Banco Fibra)
+* Bernardo Vale (Banco Inter)
 * Danilo Sasaki (Banco Itaú)
 * João Rodolfo Vieira da Silva (Banco Itaú)
 * Michelle Bandarra (Chicago)
-* Alexandre Daniel Dalabrida (Cooperativa Central Ailos)
-* Rafael Gonzalez Hashimoto - (Banco C6)
+* Nic Marcondes (Quanto)
+* Rafael Gonzalez Hashimoto (Banco C6)
+* Ralph Bragg (Raidiam)
 
 {backmatter}
 
 # Notices
 
-Copyright (c) 2021 Open Banking Brasil Initial Structure.
+Copyright (c) 2022 Open Banking Brasil Initial Structure.
 
 The Open Banking Brasil Initial Structure (OBBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OBBIS as the source of the material, but that such attribution does not indicate an endorsement by the OBBIS.
 

From f696ccb88e428eead84f3e1abfbce53791a9aa77 Mon Sep 17 00:00:00 2001
From: Nic <qbitnic@gmail.com>
Date: Thu, 17 Feb 2022 21:55:17 -0300
Subject: [PATCH 53/59] chore(md): Fix and export
 open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md

---
 ...ynamic-client-registration-1_ID2-ptbr.html | 734 +++++++++++-------
 ...-dynamic-client-registration-1_ID2-ptbr.md |  71 +-
 2 files changed, 488 insertions(+), 317 deletions(-)

diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html
index 01aced9..c3b0af4 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.html
@@ -5,12 +5,29 @@
 <meta content="Common,Latin" name="scripts">
 <meta content="initial-scale=1.0" name="viewport">
 <title>Open Banking Brasil Financial-grade API Dynamic Client Registration 1.0 Implementers Draft 2</title>
-<meta content="Ralph Bragg" name="author">
 <meta content="OBBIS GT Security" name="author">
-<meta content="xml2rfc 2.40.1" name="generator">
+<meta content="xml2rfc 3.12.2" name="generator">
 <meta content="FAPI" name="keyword">
 <meta content="Open Banking Brasil GT Security" name="keyword">
 <meta content="open-banking-brasil-dynamic-client-registration-1_ID2-ptbr" name="ietf.draft">
+<!-- Generator version information:
+  xml2rfc 3.12.2
+    Python 3.10.2
+    appdirs 1.4.4
+    ConfigArgParse 1.5.3
+    google-i18n-address 2.5.0
+    html5lib 1.1
+    intervaltree 3.1.0
+    Jinja2 2.11.3
+    kitchen 1.2.6
+    lxml 4.8.0
+    pycountry 22.1.10
+    pyflakes 2.4.0
+    PyYAML 6.0
+    requests 2.27.1
+    setuptools 58.1.0
+    six 1.16.0
+-->
 <link href="./open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.xml" rel="alternate" type="application/rfc+xml">
 <link href="#copyright" rel="license">
 <style type="text/css">/*
@@ -179,6 +196,9 @@
 ul.empty li, .ulEmpty li {
   margin-top: 0.5em;
 }
+ul.ulBare, li.ulBare {
+  margin-left: 0em !important;
+}
 ul.compact, .ulCompact,
 ol.compact, .olCompact {
   line-height: 100%;
@@ -362,6 +382,12 @@
   float: left;
   margin-bottom: 0;
 }
+/* Fix PDF info block run off issue */
+@media print {
+  #identifiers dd {
+    float: none;
+  }
+}
 #identifiers .authors .author {
   display: inline-block;
   margin-right: 1.5em;
@@ -912,12 +938,6 @@
   }
 
 }
-/* Avoid wrapping of URLs in references */
-@media screen {
-  .references a {
-    white-space: nowrap;
-  }
-}
 /* Tweak the bcp14 keyword presentation */
 .bcp14 {
   font-variant: small-caps;
@@ -988,7 +1008,7 @@
 }
 /* Make .olPercent look the same as <ol><li> */
 dl.olPercent > dd {
-  margin: 0 0 0.25em 0;
+  margin-bottom: 0.25em;
   min-height: initial;
 }
 /* Give aside some styling to set it apart */
@@ -1026,14 +1046,6 @@
     margin-bottom: 1em;
   }
 }
-/*
-  The margin-left: 0 on <dd> removes all distinction
-  between levels from nested <dl>s.  Undo that.
-*/
-dl.olPercent > dd,
-dd {
-  margin-left: revert;
-}
 /* Avoid narrow tables forcing too narrow table captions, which may render badly */
 table {
   min-width: 20em;
@@ -1059,6 +1071,108 @@
   #toc nav { display: none; }
   #toc.active nav { display: block; }
 }
+/* Add support for keepWithNext */
+.keepWithNext {
+  break-after: avoid-page;
+  break-after: avoid-page;
+}
+/* Add support for keepWithPrevious */
+.keepWithPrevious {
+  break-before: avoid-page;
+}
+/* Change the approach to avoiding breaks inside artwork etc. */
+figure, pre, table, .artwork, .sourcecode  {
+  break-before: auto;
+  break-after: auto;
+}
+/* Avoid breaks between <dt> and <dd> */
+dl {
+  break-before: auto;
+  break-inside: auto;
+}
+dt {
+  break-before: auto;
+  break-after: avoid-page;
+}
+dd {
+  break-before: avoid-page;
+  break-after: auto;
+  orphans: 3;
+  widows: 3
+}
+span.break, dd.break {
+  margin-bottom: 0;
+  min-height: 0;
+  break-before: auto;
+  break-inside: auto;
+  break-after: auto;
+}
+/* Undo break-before ToC */
+@media print {
+  #toc {
+    break-before: auto;
+  }
+}
+/* Text in compact lists should not get extra bottim margin space,
+   since that would makes the list not compact */
+ul.compact p, .ulCompact p,
+ol.compact p, .olCompact p {
+ margin: 0;
+}
+/* But the list as a whole needs the extra space at the end */
+section ul.compact,
+section .ulCompact,
+section ol.compact,
+section .olCompact {
+  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
+}
+/* The tt and code background above interferes with for instance table cell
+   backgrounds.  Changed to something a bit more selective. */
+tt, code {
+  background-color: transparent;
+}
+p tt, p code, li tt, li code {
+  background-color: #f8f8f8;
+}
+/* Tweak the pre margin -- 0px doesn't come out well */
+pre {
+   margin-top: 0.5px;
+}
+/* Tweak the comact list text */
+ul.compact, .ulCompact,
+ol.compact, .olCompact,
+dl.compact, .dlCompact {
+  line-height: normal;
+}
+/* Don't add top margin for nested lists */
+li > ul, li > ol, li > dl,
+dd > ul, dd > ol, dd > dl,
+dl > dd > dl {
+  margin-top: initial;
+}
+/* Elements that should not be rendered on the same line as a <dt> */
+/* This should match the element list in writer.text.TextWriter.render_dl() */
+dd > div.artwork:first-child,
+dd > aside:first-child,
+dd > figure:first-child,
+dd > ol:first-child,
+dd > div:first-child > pre.sourcecode,
+dd > table:first-child,
+dd > ul:first-child {
+  clear: left;
+}
+/* fix for weird browser behaviour when <dd/> is empty */
+dt+dd:empty::before{
+  content: "\00a0";
+}
+/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
+li > p {
+  margin-bottom: 0.5em
+}
+/* Don't let p margin spill out from inside list items */
+li > p:last-of-type {
+  margin-bottom: 0;
+}
 </style>
 <link href="rfc-local.css" rel="stylesheet" type="text/css">
 </head>
@@ -1068,10 +1182,10 @@
 <thead><tr>
 <td class="left"></td>
 <td class="center">OBB-FAPI-1-DCR-ID2</td>
-<td class="right">November 2021</td>
+<td class="right">February 2022</td>
 </tr></thead>
 <tfoot><tr>
-<td class="left">Bragg & Security</td>
+<td class="left">Security</td>
 <td class="center">Standards Track</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
@@ -1081,20 +1195,8 @@
 <dl id="identifiers">
 <dt class="label-workgroup">Workgroup:</dt>
 <dd class="workgroup">Open Banking Brasil GT Security</dd>
-<dt class="label-internet-draft">Internet-Draft:</dt>
-<dd class="internet-draft">open-banking-brasil-dynamic-client-registration-1_ID2-ptbr</dd>
-<dt class="label-published">Published:</dt>
-<dd class="published">
-<time datetime="2021-11-08" class="published">8 November 2021</time>
-    </dd>
-<dt class="label-intended-status">Intended Status:</dt>
-<dd class="intended-status">Standards Track</dd>
-<dt class="label-authors">Authors:</dt>
+<dt class="label-authors">Author:</dt>
 <dd class="authors">
-<div class="author">
-      <div class="author-name">R. Bragg</div>
-<div class="org">Raidiam</div>
-</div>
 <div class="author">
       <div class="author-name">GT. Security</div>
 <div class="org">OBBIS</div>
@@ -1110,14 +1212,13 @@ <h2 id="name-pref225cio">
 <p id="section-note.1-1">The normative version in <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html">English</a><a href="#section-note.1-1" class="pilcrow">¶</a></p>
 <p id="section-note.1-2">A Estrutura Inicial do Open Banking Brasil (EIOBB) &#233; respons&#225;vel por criar os padr&#245;es e especifica&#231;&#245;es necess&#225;rios para atender aos requisitos e obriga&#231;&#245;es da Legisla&#231;&#227;o do Open Banking do Brasil, conforme originalmente delineado pelo <a href="https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf">Banco Central do Brasil</a>. &#201; poss&#237;vel que alguns dos elementos deste documento estejam sujeitos a direitos de patente. O EIOBB n&#227;o se responsabiliza pela identifica&#231;&#227;o de qualquer ou todos os direitos de patente.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
 <p id="section-note.1-3">O Perfil de Seguran&#231;a Financial-grade API 1.0 do Open Banking Brasil consiste nas seguintes partes:<a href="#section-note.1-3" class="pilcrow">¶</a></p>
-<ul class="note">
-<li class="note" id="section-note.1-4.1">
-          <p id="section-note.1-4.1.1"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">Open Banking Brasil Financial-grade API Security Profile 1.0</a><a href="#section-note.1-4.1.1" class="pilcrow">¶</a></p>
+<ul class="compact note">
+<li class="compact note" id="section-note.1-4.1">
+          <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">Open Banking Brasil Financial-grade API Security Profile 1.0</a><a href="#section-note.1-4.1" class="pilcrow">¶</a>
 </li>
-<li class="note" id="section-note.1-4.2">
-          <p id="section-note.1-4.2.1">Open Banking Brasil Dynamic Client Registration Profile 1.0<a href="#section-note.1-4.2.1" class="pilcrow">¶</a></p>
+        <li class="compact note" id="section-note.1-4.2">Open Banking Brasil Dynamic Client Registration Profile 1.0<a href="#section-note.1-4.2" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 <p id="section-note.1-5">Essas partes devem ser usadas com <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>, <a href="https://tools.ietf.org/html/rfc6750">RFC6750</a>, <a href="https://tools.ietf.org/html/rfc7636">RFC7636</a>, <a href="https://openid.net/specs/openid-connect-core-1_0.html">OIDC</a>, <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OIDR</a>, <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a>, <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a>, <a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">FAPI-1-Baseline</a> e <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">FAPI-1-Advanced</a><a href="#section-note.1-5" class="pilcrow">¶</a></p>
 </section>
 <section class="note" id="section-note.2">
@@ -1132,20 +1233,16 @@ <h2 id="name-conven231245es-notacionais">
 <a href="#name-conven231245es-notacionais" class="section-name selfRef">Conven&#231;&#245;es Notacionais</a>
       </h2>
 <p id="section-note.3-1">As palavras-chave "<em>deve</em>" (shall), "<em>n&#227;o deve</em>" (shall not), "<em>deveria</em>" (should), "<em>n&#227;o deveria</em>" (should not) e "<em>pode</em>" (may) presentes nesse documento devem ser interpretadas conforme as diretrizes descritas em <a href="https://www.iso.org/sites/directives/current/part2/index.xhtml">ISO Directive Part 2</a> observando  seguinte equival&#234;ncia:<a href="#section-note.3-1" class="pilcrow">¶</a></p>
-<ul class="note">
-<li class="note" id="section-note.3-2.1">
-          <p id="section-note.3-2.1.1">"deve" =&gt; equivalente ao termo "shall" e expressa um requerimento definido no documento (nas tradu&#231;&#245;es &#233; similar ao termo "must", que pode denotar um requerimento externo ao documento);<a href="#section-note.3-2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact note">
+<li class="compact note" id="section-note.3-2.1">"deve" =&gt; equivalente ao termo "shall" e expressa um requerimento definido no documento (nas tradu&#231;&#245;es &#233; similar ao termo "must", que pode denotar um requerimento externo ao documento);<a href="#section-note.3-2.1" class="pilcrow">¶</a>
 </li>
-<li class="note" id="section-note.3-2.2">
-          <p id="section-note.3-2.2.1">"n&#227;o deve" =&gt; equivalente ao termo "shall not" e tamb&#233;m expressa um requerimento definido no documento;<a href="#section-note.3-2.2.1" class="pilcrow">¶</a></p>
+        <li class="compact note" id="section-note.3-2.2">"n&#227;o deve" =&gt; equivalente ao termo "shall not" e tamb&#233;m expressa um requerimento definido no documento;<a href="#section-note.3-2.2" class="pilcrow">¶</a>
 </li>
-<li class="note" id="section-note.3-2.3">
-          <p id="section-note.3-2.3.1">"deveria" e "n&#227;o deveria"=&gt; equivalente ao termo "should" e "should not" e expressa uma recomenda&#231;&#227;o<a href="#section-note.3-2.3.1" class="pilcrow">¶</a></p>
+        <li class="compact note" id="section-note.3-2.3">"deveria" e "n&#227;o deveria"=&gt; equivalente ao termo "should" e "should not" e expressa uma recomenda&#231;&#227;o<a href="#section-note.3-2.3" class="pilcrow">¶</a>
 </li>
-<li class="note" id="section-note.3-2.4">
-          <p id="section-note.3-2.4.1">"pode" =&gt; equivalente ao termo "may" indica uma permiss&#227;o<a href="#section-note.3-2.4.1" class="pilcrow">¶</a></p>
+        <li class="compact note" id="section-note.3-2.4">"pode" =&gt; equivalente ao termo "may" indica uma permiss&#227;o<a href="#section-note.3-2.4" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 <p id="section-note.3-3">Estas palavras-chave n&#227;o s&#227;o usadas como termos de dicion&#225;rio, de modo que qualquer ocorr&#234;ncia deles deve ser interpretada como palavras-chave e n&#227;o devem ser interpretados com seus significados de linguagem natural.<a href="#section-note.3-3" class="pilcrow">¶</a></p>
 </section>
 <div id="toc">
@@ -1153,100 +1250,100 @@ <h2 id="name-conven231245es-notacionais">
         <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
 <a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
         </h2>
-<nav class="toc"><ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.1">
-            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-escopo" class="xref">Escopo</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
+<nav class="toc"><ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
+            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-escopo" class="xref">Escopo</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.2">
-            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-refer234ncias-normativas" class="xref">Refer&#234;ncias normativas</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
+            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-refer234ncias-normativas" class="xref">Refer&#234;ncias normativas</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.3">
-            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-termos-e-defini231245es" class="xref">Termos e defini&#231;&#245;es</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
+            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-termos-e-defini231245es" class="xref">Termos e defini&#231;&#245;es</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.4">
-            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-s237mbolos-e-termos-abrevia" class="xref">S&#237;mbolos e Termos abreviados</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
+            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-s237mbolos-e-termos-abrevia" class="xref">S&#237;mbolos e Termos abreviados</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.5">
-            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-introdu231227o-2" class="xref">Introdu&#231;&#227;o</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
+            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-introdu231227o-2" class="xref">Introdu&#231;&#227;o</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.6">
-            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-provisionamentos-do-openid-" class="xref">Provisionamentos do OpenID Connect Discovery do Open Banking Brasil</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.1">
-                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-servidor-de-autoriza231227o" class="xref">Servidor de Autoriza&#231;&#227;o</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
+            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-provisionamentos-do-openid-" class="xref">Provisionamentos do OpenID Connect Discovery do Open Banking Brasil</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
+                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-servidor-de-autoriza231227o" class="xref">Servidor de Autoriza&#231;&#227;o</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.2">
-                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-cliente" class="xref">Cliente</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
+                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-cliente" class="xref">Cliente</a></p>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7">
-            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-provisionamento-de-registro" class="xref">Provisionamento de registro OpenID Connect do Open Banking Brasil</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1">
-                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-servidor-de-autoriza231227o-2" class="xref">Servidor de Autoriza&#231;&#227;o</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1.2.1">
-                    <p id="section-toc.1-1.7.2.1.2.1.1"><a href="#section-7.1.1" class="xref">7.1.1</a>.  <a href="#name-aplicando-server-defaults" class="xref">Aplicando Server Defaults</a><a href="#section-toc.1-1.7.2.1.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
+            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-provisionamento-de-registro" class="xref">Provisionamento de registro OpenID Connect do Open Banking Brasil</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
+                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-servidor-de-autoriza231227o-2" class="xref">Servidor de Autoriza&#231;&#227;o</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.1">
+                    <p id="section-toc.1-1.7.2.1.2.1.1"><a href="#section-7.1.1" class="xref">7.1.1</a>.  <a href="#name-aplicando-server-defaults" class="xref">Aplicando Server Defaults</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1.2.2">
-                    <p id="section-toc.1-1.7.2.1.2.2.1"><a href="#section-7.1.2" class="xref">7.1.2</a>.  <a href="#name-an225lise-do-distinguished-" class="xref">An&#225;lise do Distinguished Name do Certificado</a><a href="#section-toc.1-1.7.2.1.2.2.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.2">
+                    <p id="section-toc.1-1.7.2.1.2.2.1"><a href="#section-7.1.2" class="xref">7.1.2</a>.  <a href="#name-an225lise-do-distinguished-" class="xref">An&#225;lise do Distinguished Name do Certificado</a></p>
 </li>
-</ul>
+                </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.2">
-                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-fun231245es-regulat243rias-" class="xref">Fun&#231;&#245;es regulat&#243;rias para mapeamentos OpenID e OAuth 2.0</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
+                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-fun231245es-regulat243rias-" class="xref">Fun&#231;&#245;es regulat&#243;rias para mapeamentos OpenID e OAuth 2.0</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.3">
-                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-registro-do-cliente" class="xref">Registro do Cliente</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.3">
+                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-registro-do-cliente" class="xref">Registro do Cliente</a></p>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.8">
-            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-declara231227o-de-software" class="xref">Declara&#231;&#227;o de Software</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.8.2.1">
-                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-atributos-da-declara231227o" class="xref">Atributos da Declara&#231;&#227;o de Software (Claims)</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
+            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-declara231227o-de-software" class="xref">Declara&#231;&#227;o de Software</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
+                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-atributos-da-declara231227o" class="xref">Atributos da Declara&#231;&#227;o de Software (Claims)</a></p>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.9">
-            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-processamento-de-solicita23" class="xref">Processamento de solicita&#231;&#227;o de registro de cliente din&#226;mico</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.1">
-                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-enviar-uma-solicita231227o-" class="xref">Enviar uma solicita&#231;&#227;o com uma declara&#231;&#227;o de software</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
+            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-processamento-de-solicita23" class="xref">Processamento de solicita&#231;&#227;o de registro de cliente din&#226;mico</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.1">
+                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-enviar-uma-solicita231227o-" class="xref">Enviar uma solicita&#231;&#227;o com uma declara&#231;&#227;o de software</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.2">
-                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-open-banking-brasil-ssa-key" class="xref">Open Banking Brasil SSA Key Store e detalhes do emissor</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2">
+                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-open-banking-brasil-ssa-key" class="xref">Open Banking Brasil SSA Key Store e detalhes do emissor</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.3">
-                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-sobre-os-mecanismos-de-aute" class="xref">Sobre os mecanismos de autentica&#231;&#227;o e autoriza&#231;&#227;o dos servi&#231;os de DCR e DCM</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.3.2.1">
-                    <p id="section-toc.1-1.9.2.3.2.1.1"><a href="#section-9.3.1" class="xref">9.3.1</a>.  <a href="#name-registro-de-cliente-post-re" class="xref">Registro de cliente - POST /register</a><a href="#section-toc.1-1.9.2.3.2.1.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3">
+                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-sobre-os-mecanismos-de-aute" class="xref">Sobre os mecanismos de autentica&#231;&#227;o e autoriza&#231;&#227;o dos servi&#231;os de DCR e DCM</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3.2.1">
+                    <p id="section-toc.1-1.9.2.3.2.1.1"><a href="#section-9.3.1" class="xref">9.3.1</a>.  <a href="#name-registro-de-cliente-post-re" class="xref">Registro de cliente - POST /register</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.9.2.3.2.2">
-                    <p id="section-toc.1-1.9.2.3.2.2.1"><a href="#section-9.3.2" class="xref">9.3.2</a>.  <a href="#name-manuten231227o-de-cliente-g" class="xref">Manuten&#231;&#227;o de cliente - GET /register - PUT /register - DELETE /register</a><a href="#section-toc.1-1.9.2.3.2.2.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3.2.2">
+                    <p id="section-toc.1-1.9.2.3.2.2.1"><a href="#section-9.3.2" class="xref">9.3.2</a>.  <a href="#name-manuten231227o-de-cliente-g" class="xref">Manuten&#231;&#227;o de cliente - GET /register - PUT /register - DELETE /register</a></p>
 </li>
-</ul>
+                </ul>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.10">
-            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-reconhecimento" class="xref">Reconhecimento</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
+            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-reconhecimento" class="xref">Reconhecimento</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.11">
-            <p id="section-toc.1-1.11.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-avisos" class="xref">Avisos</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.11.2.1">
-                <p id="section-toc.1-1.11.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-ap234ndice-a-exemplo-de-afi" class="xref">Ap&#234;ndice A. Exemplo de afirma&#231;&#227;o de declara&#231;&#227;o de software</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
+            <p id="section-toc.1-1.11.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-avisos" class="xref">Avisos</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1">
+                <p id="section-toc.1-1.11.2.1.1"><a href="#appendix-A.1" class="xref">A.1</a>.  <a href="#name-ap234ndice-a-exemplo-de-afi" class="xref">Ap&#234;ndice A. Exemplo de afirma&#231;&#227;o de declara&#231;&#227;o de software</a></p>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.12">
-            <p id="section-toc.1-1.12.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
+            <p id="section-toc.1-1.12.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a></p>
 </li>
-</ul>
+        </ul>
 </nav>
 </section>
 </div>
@@ -1256,17 +1353,14 @@ <h2 id="name-escopo">
 <a href="#section-1" class="section-number selfRef">1. </a><a href="#name-escopo" class="section-name selfRef">Escopo</a>
       </h2>
 <p id="section-1-1">Este documento especifica o m&#233;todo de<a href="#section-1-1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-1-2.1">
-          <p id="section-1-2.1.1">aplicativos cadastrados no <a href="https://web.directory.openbankingbrasil.org.br">Diretorio de Participantes do Open Banking</a> para descobrir OpenID Providers que oferecem servi&#231;os no ecossistema Open Banking Brasil;<a href="#section-1-2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-1-2.1">aplicativos cadastrados no <a href="https://web.directory.openbankingbrasil.org.br">Diretorio de Participantes do Open Banking</a> para descobrir OpenID Providers que oferecem servi&#231;os no ecossistema Open Banking Brasil;<a href="#section-1-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-1-2.2">
-          <p id="section-1-2.2.1">aplicativos para usar o <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Registration</a> para integrar seus aplicativos com OpenID Providers dos bancos; e<a href="#section-1-2.2.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-1-2.2">aplicativos para usar o <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Registration</a> para integrar seus aplicativos com OpenID Providers dos bancos; e<a href="#section-1-2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-1-2.3">
-          <p id="section-1-2.3.1">aplicativos para usar <a href="https://tools.ietf.org/html/rfc7592">OAuth 2.0 Dynamic Client Registration Management Protocol</a> para gerenciar seus aplicativos com OpenID Providers;<a href="#section-1-2.3.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-1-2.3">aplicativos para usar <a href="https://tools.ietf.org/html/rfc7592">OAuth 2.0 Dynamic Client Registration Management Protocol</a> para gerenciar seus aplicativos com OpenID Providers;<a href="#section-1-2.3" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 <p id="section-1-3">Este documento &#233; aplic&#225;vel a todos os participantes do Open Banking no Brasil.<a href="#section-1-3" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -1298,6 +1392,7 @@ <h2 id="name-refer234ncias-normativas">
 <p id="section-2-21"><a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">FAPI-1-Advanced</a> - Financial-grade API Security Profile 1.0 - Part 2: Advanced<a href="#section-2-21" class="pilcrow">¶</a></p>
 <p id="section-2-22"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">OBB-FAPI</a> - Open Banking Brasil Financial-grade API Security Profile 1.0<a href="#section-2-22" class="pilcrow">¶</a></p>
 <p id="section-2-23"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">OBB-Cert-Standards</a> - Open Banking Brasil x.509 Certificate Standards<a href="#section-2-23" class="pilcrow">¶</a></p>
+<p id="section-2-24"><a href="https://raw.githubusercontent.com/OpenBanking-Brasil/specs-seguranca/main/dcr_review/dcr-dcm-swagger.yaml">OBB-DCR/DCM-Swagger</a> - DCR & DCM Swagger<a href="#section-2-24" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="Definitions">
@@ -1313,15 +1408,35 @@ <h2 id="name-termos-e-defini231245es">
       <h2 id="name-s237mbolos-e-termos-abrevia">
 <a href="#section-4" class="section-number selfRef">4. </a><a href="#name-s237mbolos-e-termos-abrevia" class="section-name selfRef">S&#237;mbolos e Termos abreviados</a>
       </h2>
-<p id="section-4-1"><strong>SSA</strong> - Software Statement Assertion (Afirma&#231;&#227;o de Declara&#231;&#227;o de Software)<a href="#section-4-1" class="pilcrow">¶</a></p>
-<p id="section-4-2"><strong>SS</strong> - Software Statement (Declara&#231;&#227;o de Software)<a href="#section-4-2" class="pilcrow">¶</a></p>
-<p id="section-4-3"><strong>DCR</strong> - Dynamic Client Registration (Registro de Cliente Din&#226;mico)<a href="#section-4-3" class="pilcrow">¶</a></p>
-<p id="section-4-4"><strong>API</strong> - Application Programming Interface (Interface de Programa&#231;&#227;o da Aplica&#231;&#227;o)<a href="#section-4-4" class="pilcrow">¶</a></p>
-<p id="section-4-5"><strong>FAPI</strong> - Financial-grade API<a href="#section-4-5" class="pilcrow">¶</a></p>
-<p id="section-4-6"><strong>HTTP</strong> - Hyper Text Transfer Protocol<a href="#section-4-6" class="pilcrow">¶</a></p>
-<p id="section-4-7"><strong>OIDF</strong> - OpenID Foundation<a href="#section-4-7" class="pilcrow">¶</a></p>
-<p id="section-4-8"><strong>REST</strong> - Representational State Transfer<a href="#section-4-8" class="pilcrow">¶</a></p>
-<p id="section-4-9"><strong>TLS</strong> - Transport Layer Security<a href="#section-4-9" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-4-1.1">
+          <strong>API</strong> - Application Programming Interface (Interface de Programa&#231;&#227;o da Aplica&#231;&#227;o)<a href="#section-4-1.1" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.2">
+          <strong>DCR</strong> - Dynamic Client Registration (Registro de Cliente Din&#226;mico)<a href="#section-4-1.2" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.3">
+          <strong>FAPI</strong> - Financial-grade API<a href="#section-4-1.3" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.4">
+          <strong>HTTP</strong> - Hyper Text Transfer Protocol<a href="#section-4-1.4" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.5">
+          <strong>OIDF</strong> - OpenID Foundation<a href="#section-4-1.5" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.6">
+          <strong>REST</strong> - Representational State Transfer<a href="#section-4-1.6" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.7">
+          <strong>SS</strong> - Software Statement (Declara&#231;&#227;o de Software)<a href="#section-4-1.7" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.8">
+          <strong>SSA</strong> - Software Statement Assertion (Afirma&#231;&#227;o de Declara&#231;&#227;o de Software)<a href="#section-4-1.8" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.9">
+          <strong>TLS</strong> - Transport Layer Security<a href="#section-4-1.9" class="pilcrow">¶</a>
+</li>
+      </ul>
 </section>
 </div>
 <div id="Intro">
@@ -1331,17 +1446,14 @@ <h2 id="name-introdu231227o-2">
       </h2>
 <p id="section-5-1">O ecossistema Open Banking Brasil apoia-se em um provedor de confian&#231;a ou <em>diret&#243;rio de participantes</em> como a fonte mais valiosa de informa&#231;&#245;es sobre participantes credenciados e softwares que est&#227;o autorizados a participar do ecossistema Open Banking Brasil.<a href="#section-5-1" class="pilcrow">¶</a></p>
 <p id="section-5-2">Os servi&#231;os do Diret&#243;rio incluem:<a href="#section-5-2" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-5-3.1">
-          <p id="section-5-3.1.1">Registro e gerenciamento de software<a href="#section-5-3.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-5-3.1">Registro e gerenciamento de software<a href="#section-5-3.1" class="pilcrow">¶</a>
 </li>
-<li id="section-5-3.2">
-          <p id="section-5-3.2.1">Registro e gerenciamento de credenciais de software usando certificados ICP<a href="#section-5-3.2.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-5-3.2">Registro e gerenciamento de credenciais de software usando certificados ICP<a href="#section-5-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-5-3.3">
-          <p id="section-5-3.3.1">Gera&#231;&#227;o de Software Statement Assertion (SSA)<a href="#section-5-3.3.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-5-3.3">Gera&#231;&#227;o de Software Statement Assertion (SSA)<a href="#section-5-3.3" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 <p id="section-5-4">Os participantes do ecossistema devem aproveitar esses servi&#231;os para facilitar o registro de cliente OAuth orientado por API usando o processo descrito na cl&#225;usula 3.1.1 do <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a> com metadados adicionais necess&#225;rios para oferecer suporte ao OpenID Connect definido em <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Registration</a>.<a href="#section-5-4" class="pilcrow">¶</a></p>
 <p id="section-5-5">&#201; importante refor&#231;ar que o payload de registro de clientes possui a maior parte de seus atributos n&#227;o obrigat&#243;rios, e que os atributos cujos valores  conflitem com os presentes no software statement assertion <em>ser&#227;o sobrepostos pelos valores do pr&#243;prio software statement assertion emitido pelo diret&#243;rio central</em>. Nem todos os metadados que um cliente deseja fornecer podem estar contidos em um <em>software statement</em>, por exemplo, alternativa <a href="https://openid.net/specs/openid-connect-registration-1_0.html#LanguagesAndScripts">Metadata Languages and Script values</a>. H&#225; casos ainda de metadados de cliente que s&#227;o um subconjunto dos valores existentes no SSA, como por exemplo os redirect_URIs.<a href="#section-5-5" class="pilcrow">¶</a></p>
 </section>
@@ -1358,29 +1470,22 @@ <h3 id="name-servidor-de-autoriza231227o">
         </h3>
 <p id="section-6.1-1">O servidor de autoriza&#231;&#227;o deve suportar <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery</a> conforme exigido pelo <a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">Financial-grade API Security Profile 1.0 - Part 1: Baseline</a>. Este suporte deve estar explicito tanto na forma como o Servidor de Autoriza&#231;&#227;o est&#225; registrado no Diret&#243;rio de Participantes quanto na declara&#231;&#227;o dos seus atributos no arquivo de Discovery (well-known), respeitando os mecanismos de autentica&#231;&#227;o certificados pela institi&#231;&#227;o atrav&#233;s dos testes de conformidade do Open Banking Brasil.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
 <p id="section-6.1-2">Adicionalmente, o Servidor de Autoriza&#231;&#227;o:<a href="#section-6.1-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-6.1-3">
-          <li id="section-6.1-3.1">
-            <p id="section-6.1-3.1.1">deve anunciar sua presen&#231;a no ecossistema Open Banking Brasil, sendo listada no Diret&#243;rio de Participantes;<a href="#section-6.1-3.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-6.1-3">
+<li id="section-6.1-3.1">deve anunciar sua presen&#231;a no ecossistema Open Banking Brasil, sendo listada no Diret&#243;rio de Participantes;<a href="#section-6.1-3.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-3.2">
-            <p id="section-6.1-3.2.1">deve anunciar todos os recursos API REST do Open Banking Brasil protegidos pelo Provedor OpenID no Diret&#243;rio de Participantes;<a href="#section-6.1-3.2.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.2">deve anunciar todos os recursos API REST do Open Banking Brasil protegidos pelo Provedor OpenID no Diret&#243;rio de Participantes;<a href="#section-6.1-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-3.3">
-            <p id="section-6.1-3.3.1">deve anunciar suporte para todos os mecanismos de assinatura, criptografia, autentica&#231;&#227;o e padr&#245;es necess&#225;rios para suportar o <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">Open Banking Brasil Financial API</a>;<a href="#section-6.1-3.3.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.3">deve anunciar suporte para todos os mecanismos de assinatura, criptografia, autentica&#231;&#227;o e padr&#245;es necess&#225;rios para suportar o <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">Open Banking Brasil Financial API</a>;<a href="#section-6.1-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-3.4">
-            <p id="section-6.1-3.4.1">deve anunciar suporte para <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Dynamic Client Registration</a>;<a href="#section-6.1-3.4.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.4">deve anunciar suporte para <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Dynamic Client Registration</a>;<a href="#section-6.1-3.4" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-3.5">
-            <p id="section-6.1-3.5.1">deve anunciar <code>mtls_endpoint_aliases</code> de acordo com a cl&#225;usula 5 <a href="https://tools.ietf.org/html/rfc8705">RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication e Certificate-Bound Access Tokens</a> o <code>token_endpoint</code>, <code>registration_endpoint</code> e <code>userinfo_endpoint</code>;<a href="#section-6.1-3.5.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.5">deve anunciar <code>mtls_endpoint_aliases</code> de acordo com a cl&#225;usula 5 <a href="https://tools.ietf.org/html/rfc8705">RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication e Certificate-Bound Access Tokens</a> o <code>token_endpoint</code>, <code>registration_endpoint</code> e <code>userinfo_endpoint</code>;<a href="#section-6.1-3.5" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-3.6">
-            <p id="section-6.1-3.6.1">se suportar <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">OAuth 2.0 Pushed Authorisation Requests</a>, deve anunciar por meio de <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> <code>mtls_endpoint_aliases</code> o <code>push_authorization_request_endpoint</code>;<a href="#section-6.1-3.6.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.6">se suportar <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">OAuth 2.0 Pushed Authorisation Requests</a>, deve anunciar por meio de <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> <code>mtls_endpoint_aliases</code> o <code>push_authorization_request_endpoint</code>;<a href="#section-6.1-3.6" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-3.7">
-            <p id="section-6.1-3.7.1">se suportar <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md">Financial API - Client Initiated Back Channel Authentication</a>, deve anunciar atrav&#233;s de <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> <code>mtls_endpoint_aliases</code> o <code>backchannel_authentication_endpoint</code>;<a href="#section-6.1-3.7.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.7">se suportar <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md">Financial API - Client Initiated Back Channel Authentication</a>, deve anunciar atrav&#233;s de <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> <code>mtls_endpoint_aliases</code> o <code>backchannel_authentication_endpoint</code>;<a href="#section-6.1-3.7" class="pilcrow">¶</a>
 </li>
-</ol>
+        </ol>
 </section>
 </div>
 <div id="Client">
@@ -1390,17 +1495,14 @@ <h3 id="name-cliente">
         </h3>
 <p id="section-6.2-1">O cliente deve suportar <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery</a> conforme exigido pelo <a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">Financial-grade API Security Profile 1.0 - Part 1: Baseline</a>.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
 <p id="section-6.2-2">Al&#233;m disso, o servidor de autoriza&#231;&#227;o<a href="#section-6.2-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-6.2-3">
-          <li id="section-6.2-3.1">
-            <p id="section-6.2-3.1.1">deve contar com servi&#231;os de descoberta do ecossistemas fornecidos apenas pelo Diret&#243;rio de Participantes;<a href="#section-6.2-3.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-6.2-3">
+<li id="section-6.2-3.1">deve contar com servi&#231;os de descoberta do ecossistemas fornecidos apenas pelo Diret&#243;rio de Participantes;<a href="#section-6.2-3.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.2-3.2">
-            <p id="section-6.2-3.2.1">deve derivar os metadados necess&#225;rios do Authorization Server somente por meio do servi&#231;o OpenID Connect Discovery dos Authorization Servers;<a href="#section-6.2-3.2.1" class="pilcrow">¶</a></p>
+          <li id="section-6.2-3.2">deve derivar os metadados necess&#225;rios do Authorization Server somente por meio do servi&#231;o OpenID Connect Discovery dos Authorization Servers;<a href="#section-6.2-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-6.2-3.3">
-            <p id="section-6.2-3.3.1">quando presente, deve usar endpoints anunciados em <code>mtls_endpoint_aliases</code> conforme a cl&#225;usula 5 <a href="https://tools.ietf.org/html/rfc8705">RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication e Certificate-Bound Access Tokens</a>;<a href="#section-6.2-3.3.1" class="pilcrow">¶</a></p>
+          <li id="section-6.2-3.3">quando presente, deve usar endpoints anunciados em <code>mtls_endpoint_aliases</code> conforme a cl&#225;usula 5 <a href="https://tools.ietf.org/html/rfc8705">RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication e Certificate-Bound Access Tokens</a>;<a href="#section-6.2-3.3" class="pilcrow">¶</a>
 </li>
-</ol>
+        </ol>
 </section>
 </div>
 </section>
@@ -1417,47 +1519,35 @@ <h3 id="name-servidor-de-autoriza231227o-2">
         </h3>
 <p id="section-7.1-1">O servidor de autoriza&#231;&#227;o deve suportar as RFCs de Dynamic Client Registration (DCR) <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a>, Dynamic Client Management (DCM) <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a> e <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Registration</a><a href="#section-7.1-1" class="pilcrow">¶</a></p>
 <p id="section-7.1-2">Al&#233;m disso, o servidor de autoriza&#231;&#227;o<a href="#section-7.1-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-7.1-3">
-          <li id="section-7.1-3.1">
-            <p id="section-7.1-3.1.1">deve rejeitar as solicita&#231;&#245;es de registro de cliente din&#226;mico n&#227;o realizadas em uma conex&#227;o protegida com mTLS usando certificados emitidos pelo Brasil ICP (produ&#231;&#227;o) ou o Diret&#243;rio de Participantes (sandbox);<a href="#section-7.1-3.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-7.1-3">
+<li id="section-7.1-3.1">deve rejeitar as solicita&#231;&#245;es de registro de cliente din&#226;mico n&#227;o realizadas em uma conex&#227;o protegida com mTLS usando certificados emitidos pelo Brasil ICP (produ&#231;&#227;o) ou o Diret&#243;rio de Participantes (sandbox);<a href="#section-7.1-3.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.2">
-            <p id="section-7.1-3.2.1">deve validar que a solicita&#231;&#227;o cont&#233;m <em>software_statement</em> JWT assinado usando o algoritmo <code>PS256</code> emitido pelo Diret&#243;rio de Participantes do Open Banking Brasil;<a href="#section-7.1-3.2.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.2">deve validar que a solicita&#231;&#227;o cont&#233;m <em>software_statement</em> JWT assinado usando o algoritmo <code>PS256</code> emitido pelo Diret&#243;rio de Participantes do Open Banking Brasil;<a href="#section-7.1-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.3">
-            <p id="section-7.1-3.3.1">deve validar que o <em>software_statement</em> foi emitido (iat  - <em>issued at</em>) n&#227;o mais de 5 minutos antes do pedido ser recebido;<a href="#section-7.1-3.3.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.3">deve validar que o <em>software_statement</em> foi emitido (iat  - <em>issued at</em>) n&#227;o mais de 5 minutos antes do pedido ser recebido;<a href="#section-7.1-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.4">
-            <p id="section-7.1-3.4.1">deve validar que um atributo <code>jwks</code> (definida por valor) <strong>n&#227;o</strong> foi inclu&#237;do, e sim declarado como refer&#234;ncia no atributo <code>jwks_uri</code>;<a href="#section-7.1-3.4.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.4">deve validar que um atributo <code>jwks</code> (definida por valor) <strong>n&#227;o</strong> foi inclu&#237;do, e sim declarado como refer&#234;ncia no atributo <code>jwks_uri</code>;<a href="#section-7.1-3.4" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.5">
-            <p id="section-7.1-3.5.1">deve, quando informado, validar que o <code>jwks_uri</code> corresponda ao <code>software_jwks_uri</code> fornecido na declara&#231;&#227;o do software;<a href="#section-7.1-3.5.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.5">deve, quando informado, validar que o <code>jwks_uri</code> corresponda ao <code>software_jwks_uri</code> fornecido na declara&#231;&#227;o do software;<a href="#section-7.1-3.5" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.6">
-            <p id="section-7.1-3.6.1">deve exigir e validar que o <code>redirect_uris</code> corresponda ou contenha um subconjunto dos valores de <code>software_redirect_uris</code> fornecidos no <em>software_statement</em>;<a href="#section-7.1-3.6.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.6">deve exigir e validar que o <code>redirect_uris</code> corresponda ou contenha um subconjunto dos valores de <code>software_redirect_uris</code> fornecidos no <em>software_statement</em>;<a href="#section-7.1-3.6" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.7">
-            <p id="section-7.1-3.7.1">deve exigir e validar que todos os mecanismos de autentica&#231;&#227;o de cliente cumpram os requisitos definidos nas <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a> e <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a>, atrav&#233;s da valida&#231;&#227;o do <code>registration_access_token</code> e, como conex&#227;o segura, da cadeia de certificados confi&#225;veis ICP-Brasil.<a href="#section-7.1-3.7.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.7">deve exigir e validar que todos os mecanismos de autentica&#231;&#227;o de cliente cumpram os requisitos definidos nas <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a> e <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a>, atrav&#233;s da valida&#231;&#227;o do <code>registration_access_token</code> e, como conex&#227;o segura, da cadeia de certificados confi&#225;veis ICP-Brasil.<a href="#section-7.1-3.7" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.8">
-            <p id="section-7.1-3.8.1"><em>removido</em>;<a href="#section-7.1-3.8.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.8">
+            <em>removido</em>;<a href="#section-7.1-3.8" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.9">
-            <p id="section-7.1-3.9.1">deve validar se os escopos solicitados s&#227;o adequados para as permiss&#245;es regulat&#243;rias autorizadas da institui&#231;&#227;o e contidas no _software_statement. A rela&#231;&#227;o de permiss&#245;es regulat&#243;rias e os escopos correspondentes est&#225; descrita nas se&#231;&#245;es a seguir.<a href="#section-7.1-3.9.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.9">deve validar se os escopos solicitados s&#227;o adequados para as permiss&#245;es regulat&#243;rias autorizadas da institui&#231;&#227;o e contidas no _software_statement. A rela&#231;&#227;o de permiss&#245;es regulat&#243;rias e os escopos correspondentes est&#225; descrita nas se&#231;&#245;es a seguir.<a href="#section-7.1-3.9" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.10">
-            <p id="section-7.1-3.10.1">deve, sempre que poss&#237;vel, validar os metadados declarados pelo cliente em rela&#231;&#227;o aos metadados fornecidos no <em>software_statement</em>, adotando os valores presentes no SSA com preced&#234;ncia.<a href="#section-7.1-3.10.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.10">deve, sempre que poss&#237;vel, validar os metadados declarados pelo cliente em rela&#231;&#227;o aos metadados fornecidos no <em>software_statement</em>, adotando os valores presentes no SSA com preced&#234;ncia.<a href="#section-7.1-3.10" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.11">
-            <p id="section-7.1-3.11.1">deve aceitar todos os nomes x.500 AttributeType definidas no <em>Distinguished Name</em> dos Perfis de Certificado x.509 definidos em <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a>;<a href="#section-7.1-3.11.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.11">deve aceitar todos os nomes x.500 AttributeType definidas no <em>Distinguished Name</em> dos Perfis de Certificado x.509 definidos em <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a>;<a href="#section-7.1-3.11" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.12">
-            <p id="section-7.1-3.12.1">se for compat&#237;vel com o mecanismo de autentica&#231;&#227;o do cliente <code>tls_client_auth</code>, conforme definido em <a href="https://tools.ietf.org/html/rfc8705">RFC8705</a>, somente deve aceitar <code>tls_client_auth_subject_dn</code> como uma indica&#231;&#227;o do valor do atributo <em>subject</em> do certificado, conforme definido na cl&#225;usula 2.1.2 <a href="https://tools.ietf.org/html/rfc8705">RFC8705</a>;<a href="#section-7.1-3.12.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.12">se for compat&#237;vel com o mecanismo de autentica&#231;&#227;o do cliente <code>tls_client_auth</code>, conforme definido em <a href="https://tools.ietf.org/html/rfc8705">RFC8705</a>, somente deve aceitar <code>tls_client_auth_subject_dn</code> como uma indica&#231;&#227;o do valor do atributo <em>subject</em> do certificado, conforme definido na cl&#225;usula 2.1.2 <a href="https://tools.ietf.org/html/rfc8705">RFC8705</a>;<a href="#section-7.1-3.12" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1-3.13">
-            <p id="section-7.1-3.13.1">Os valores dos campos <em>UID</em> e <em>OU</em> do certificado devem coincidir com os enviados no SSA. O campo <em>OU</em> deve conter o valor do campo <em>org_id</em> do SSA e campo <em>UID</em> deve conter o valor do campo <em>software_id</em> do SSA.<a href="#section-7.1-3.13.1" class="pilcrow">¶</a></p>
+          <li id="section-7.1-3.13">Os valores dos campos <em>UID</em> e <em>OU</em> do certificado devem coincidir com os enviados no SSA. O campo <em>OU</em> deve conter o valor do campo <em>org_id</em> do SSA e campo <em>UID</em> deve conter o valor do campo <em>software_id</em> do SSA.<a href="#section-7.1-3.13" class="pilcrow">¶</a>
 </li>
-</ol>
+        </ol>
 <p id="section-7.1-4">Estas disposi&#231;&#245;es aplicam-se igualmente ao processamento de pedidos <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a>, <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a> e <a href="https://openid.net/specs/openid-connect-registration-1_0.html">OpenID Registration</a><a href="#section-7.1-4" class="pilcrow">¶</a></p>
 <div id="Server">
 <section id="section-7.1.1">
@@ -1465,17 +1555,14 @@ <h4 id="name-aplicando-server-defaults">
 <a href="#section-7.1.1" class="section-number selfRef">7.1.1. </a><a href="#name-aplicando-server-defaults" class="section-name selfRef">Aplicando Server Defaults</a>
           </h4>
 <p id="section-7.1.1-1">Quando as propriedades de uma solicita&#231;&#227;o DCR n&#227;o est&#227;o inclu&#237;das e n&#227;o s&#227;o obrigat&#243;rias na especifica&#231;&#227;o, o Authorization Server deve aplicar os padr&#245;es do cliente da seguinte maneira:<a href="#section-7.1.1-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-7.1.1-2">
-            <li id="section-7.1.1-2.1">
-              <p id="section-7.1.1-2.1.1">deve selecionar e aplicar o algoritmo de criptografia e a escolha da cifra a partir dos conjuntos mais recomendados de cifra da IANA que s&#227;o suportados pelo Servidor de Autoriza&#231;&#227;o;<a href="#section-7.1.1-2.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-7.1.1-2">
+<li id="section-7.1.1-2.1">deve selecionar e aplicar o algoritmo de criptografia e a escolha da cifra a partir dos conjuntos mais recomendados de cifra da IANA que s&#227;o suportados pelo Servidor de Autoriza&#231;&#227;o;<a href="#section-7.1.1-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.1-2.2">
-              <p id="section-7.1.1-2.2.1">deve preencher <em>defaults</em> a partir de valores da afirma&#231;&#227;o de <em>software_statement</em>, sempre que poss&#237;vel;<a href="#section-7.1.1-2.2.1" class="pilcrow">¶</a></p>
+            <li id="section-7.1.1-2.2">deve preencher <em>defaults</em> a partir de valores da afirma&#231;&#227;o de <em>software_statement</em>, sempre que poss&#237;vel;<a href="#section-7.1.1-2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.1-2.3">
-              <p id="section-7.1.1-2.3.1">deve conceder ao cliente permiss&#227;o para o conjunto completo de escopos potenciais com base nas permiss&#245;es regulat&#243;rias de softwares inclu&#237;das no <em>software_statement</em>;<a href="#section-7.1.1-2.3.1" class="pilcrow">¶</a></p>
+            <li id="section-7.1.1-2.3">deve conceder ao cliente permiss&#227;o para o conjunto completo de escopos potenciais com base nas permiss&#245;es regulat&#243;rias de softwares inclu&#237;das no <em>software_statement</em>;<a href="#section-7.1.1-2.3" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 </section>
 </div>
 <div id="Certificate">
@@ -1487,17 +1574,14 @@ <h4 id="name-an225lise-do-distinguished-">
 <p id="section-7.1.2-2">Para resolver essa ambiguidade, o Servidor de Autoriza&#231;&#227;o deve aceitar exclusivamente os AttributeType (descritores) definidas no &#250;ltimo par&#225;grafo da cl&#225;usula 3 <a href="https://www.rfc-editor.org/rfc/rfc4514">RFC4514</a> em formato string,  tamb&#233;m deve aceitar em formato OID, com seus valores em ASN.1, todos os AttributeTypes definidos no Distinguished Name <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html">Open Banking Brasil x.509 Certificate Standards</a> ou adicionados pela Autoridade Certificadora.<a href="#section-7.1.2-2" class="pilcrow">¶</a></p>
 <p id="section-7.1.2-3">Em caso de n&#227;o atendimento destes requisitos o Servidor de Autoriza&#231;&#227;o dever&#225; rejeitar o registro.<a href="#section-7.1.2-3" class="pilcrow">¶</a></p>
 <p id="section-7.1.2-4">Segue na tabela abaixo como deve ser feita a decodifica&#231;&#227;o:<a href="#section-7.1.2-4" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-7.1.2-5.1">
-              <p id="section-7.1.2-5.1.1">Obtenha na ordem reversa os atributos do certificado<a href="#section-7.1.2-5.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-7.1.2-5.1">Obtenha na ordem reversa os atributos do certificado<a href="#section-7.1.2-5.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.2-5.2">
-              <p id="section-7.1.2-5.2.1">Concatene cada RDN (RelativeDistinguishedName) com uma virgula (',')<a href="#section-7.1.2-5.2.1" class="pilcrow">¶</a></p>
+            <li class="compact" id="section-7.1.2-5.2">Concatene cada RDN (RelativeDistinguishedName) com uma virgula (',')<a href="#section-7.1.2-5.2" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.2-5.3">
-              <p id="section-7.1.2-5.3.1">Use as strings da RFC (CN, L, ST, O, OU, C, Street, DC, UID) com o valor dos seus atribudos em "printable string", ou seja leg&#237;vel para humanos + os OIDs dos atributos definidos nesta especifica&#231;&#227;o para uso no OBB (businessCategory=OID 2.5.4.15,jurisdictionCountryName=OID: 1.3.6.1.4.1.311.60.2.1.3, serialNumber=2.5.4.5) com o valor dos seus atributos em formato ASN.1"<a href="#section-7.1.2-5.3.1" class="pilcrow">¶</a></p>
+            <li class="compact" id="section-7.1.2-5.3">Use as strings da RFC (CN, L, ST, O, OU, C, Street, DC, UID) com o valor dos seus atribudos em "printable string", ou seja leg&#237;vel para humanos + os OIDs dos atributos definidos nesta especifica&#231;&#227;o para uso no OBB (businessCategory=OID 2.5.4.15,jurisdictionCountryName=OID: 1.3.6.1.4.1.311.60.2.1.3, serialNumber=2.5.4.5) com o valor dos seus atributos em formato ASN.1"<a href="#section-7.1.2-5.3" class="pilcrow">¶</a>
 </li>
-</ul>
+          </ul>
 <p id="section-7.1.2-6">Seguem abaixo exemplos para os atributos obrigat&#243;rios da CAs atualmente ativas:<a href="#section-7.1.2-6" class="pilcrow">¶</a></p>
 <table class="center" id="table-1">
             <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
@@ -1557,7 +1641,7 @@ <h3 id="name-fun231245es-regulat243rias-">
             <tr>
               <td class="text-left" rowspan="1" colspan="1">PAGTO</td>
               <td class="text-left" rowspan="1" colspan="1">Institui&#231;&#227;o prestadora de servi&#231;o de inicia&#231;&#227;o de pagamentos (PISP)</td>
-              <td class="text-left" rowspan="1" colspan="1">openid payments </td>
+              <td class="text-left" rowspan="1" colspan="1">openid payments</td>
               <td class="text-left" rowspan="1" colspan="1">Phase 3</td>
             </tr>
             <tr>
@@ -1574,6 +1658,7 @@ <h3 id="name-fun231245es-regulat243rias-">
             </tr>
           </tbody>
         </table>
+<p id="section-7.2-4">&#201; necess&#225;rio validar as roles ativas no <em>software_statement</em> da aplica&#231;&#227;o. Na valida&#231;&#227;o dessa informa&#231;&#227;o deve ser utilizado o campo _software_statement_roles, e deve ser verificado se as roles listadas est&#227;o ativas.<a href="#section-7.2-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="registro_tls_client_auth">
@@ -1581,8 +1666,7 @@ <h3 id="name-fun231245es-regulat243rias-">
         <h3 id="name-registro-do-cliente">
 <a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-registro-do-cliente" class="section-name selfRef">Registro do Cliente</a>
         </h3>
-<p id="section-7.3-1">No processo de registro do cliente, utilizando-se o m&#233;todo de autentica&#231;&#227;o <em>tls_client_auth</em>, o cliente deve encaminhar o campo <em>tls_client_auth_subject_dn</em> com os AttibuteTypes (Descritores) em formato definido no item 7.1.2.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
-<p id="section-7.3-2">Em caso de n&#227;o aderencia a este padr&#227;o o registro ser&#225; rejeitado.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
+<p id="section-7.3-1">No processo de registro do cliente, utilizando-se o m&#233;todo de autentica&#231;&#227;o <em>tls_client_auth</em>, o cliente deve encaminhar o campo _tls_client_auth_subject_dn_ com os AttibuteTypes(Descritores) em formato definido no item 7.1.2. Em caso de n&#227;o aderencia a este padr&#227;o o registro ser&#225; rejeitado.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>
@@ -1599,7 +1683,7 @@ <h3 id="name-atributos-da-declara231227o">
 <a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-atributos-da-declara231227o" class="section-name selfRef">Atributos da Declara&#231;&#227;o de Software (Claims)</a>
         </h3>
 <p id="section-8.1-1">O exemplo a seguir cont&#233;m todos os atributos atualmente inclu&#237;dos em um <em>software_statement</em>:<a href="#section-8.1-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-8.1-2">
+<div class="alignLeft art-text artwork" id="section-8.1-2">
 <pre>{
   "software_mode": "Live",
   "software_redirect_uris": [
@@ -1685,15 +1769,136 @@ <h3 id="name-atributos-da-declara231227o">
       <h2 id="name-processamento-de-solicita23">
 <a href="#section-9" class="section-number selfRef">9. </a><a href="#name-processamento-de-solicita23" class="section-name selfRef">Processamento de solicita&#231;&#227;o de registro de cliente din&#226;mico</a>
       </h2>
-	  	  <p><img src="images/dynamic-client-registration.png" alt="Dynamic Client Registration Request Processing" /></p>
+<figure id="figure-1">
+        <div class="alignLeft art-svg artwork" id="section-9-1.1">
+<svg xmlns="http://www.w3.org/2000/svg" contentstyletype="text/css" height="auto" preserveAspectRatio="none" style="width:100%;height:auto;background:#FFFFFF;" version="1.1" viewBox="0 0 1153 906" width="100%" zoomAndPan="magnify">
+            <desc>Dynamic Client Registration</desc>
+            <g>
+              <rect height="26.2969" style="stroke:#00000000;stroke-width:1.0;fill:none;" width="238" x="456.75" y="10"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" font-weight="bold" lengthAdjust="spacing" textLength="228" x="461.75" y="27.9951" style="white-space: pre;">Dynamic Client Registration</text>
+              <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="298" x2="298" y1="73.5938" y2="870.9141"></line>
+              <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="482" x2="482" y1="73.5938" y2="870.9141"></line>
+              <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="624" x2="624" y1="73.5938" y2="870.9141"></line>
+              <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="746" x2="746" y1="73.5938" y2="870.9141"></line>
+              <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="877" x2="877" y1="73.5938" y2="870.9141"></line>
+              <line style="stroke:#181818;stroke-width:0.5;stroke-dasharray:5.0,5.0;" x1="1109.5" x2="1109.5" y1="73.5938" y2="870.9141"></line>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="41" x="278" y="42.2969"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="27" x="285" y="62.292" style="white-space: pre;">TPP</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="41" x="278" y="869.9141"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="27" x="285" y="889.9092" style="white-space: pre;">TPP</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="101" x="432" y="42.2969"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="87" x="439" y="62.292" style="white-space: pre;">DirectoryAS</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="101" x="432" y="869.9141"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="87" x="439" y="889.9092" style="white-space: pre;">DirectoryAS</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="105" x="572" y="42.2969"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="91" x="579" y="62.292" style="white-space: pre;">DirectoryAPI</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="105" x="572" y="869.9141"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="91" x="579" y="889.9092" style="white-space: pre;">DirectoryAPI</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="119" x="687" y="42.2969"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="105" x="694" y="62.292" style="white-space: pre;">DirectoryJWKS</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="119" x="687" y="869.9141"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="105" x="694" y="889.9092" style="white-space: pre;">DirectoryJWKS</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="69" x="843" y="42.2969"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="55" x="850" y="62.292" style="white-space: pre;">BankAS</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="69" x="843" y="869.9141"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="55" x="850" y="889.9092" style="white-space: pre;">BankAS</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="76" x="1071.5" y="42.2969"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="62" x="1078.5" y="62.292" style="white-space: pre;">ICPBrasil</text>
+              <rect fill="#E2E2F0" height="30.2969" rx="2.5" ry="2.5" style="stroke:#181818;stroke-width:0.5;" width="76" x="1071.5" y="869.9141"></rect>
+              <text fill="#000000" font-family="sans-serif" font-size="14" lengthAdjust="spacing" textLength="62" x="1078.5" y="889.9092" style="white-space: pre;">ICPBrasil</text>
+              <polygon fill="#181818" points="470.5,100.7266,480.5,104.7266,470.5,108.7266,474.5,104.7266" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="476.5" y1="104.7266" y2="104.7266"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="160" x="305.5" y="99.6606" style="white-space: pre;">OAuth 2.0 tls_client_auth</text>
+              <path d="M110,117.7266 L110,157.7266 L293,157.7266 L293,127.7266 L283,117.7266 L110,117.7266 " fill="#FEFFDD" style="stroke:#181818;stroke-width:0.5;"></path>
+              <path d="M283,117.7266 L283,127.7266 L293,127.7266 L283,117.7266 " fill="#FEFFDD" style="stroke:#181818;stroke-width:0.5;"></path>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="152" x="116" y="134.7935" style="white-space: pre;">Client Credentials Grant</text>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="162" x="116" y="149.9263" style="white-space: pre;">Scope directory:software</text>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="482.5" x2="524.5" y1="184.125" y2="184.125"></line>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="524.5" x2="524.5" y1="184.125" y2="197.125"></line>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="483.5" x2="524.5" y1="197.125" y2="197.125"></line>
+              <polygon fill="#181818" points="493.5,193.125,483.5,197.125,493.5,201.125,489.5,197.125" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="122" x="489.5" y="179.0591" style="white-space: pre;">Validate Certificate</text>
+              <polygon fill="#181818" points="1097.5,222.2578,1107.5,226.2578,1097.5,230.2578,1101.5,226.2578" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="482.5" x2="1103.5" y1="226.2578" y2="226.2578"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="160" x="489.5" y="221.1919" style="white-space: pre;">Check Revocation Status</text>
+              <polygon fill="#181818" points="493.5,251.3906,483.5,255.3906,493.5,259.3906,489.5,255.3906" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="487.5" x2="1108.5" y1="255.3906" y2="255.3906"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="88" x="499.5" y="250.3247" style="white-space: pre;">Certificate OK</text>
+              <polygon fill="#181818" points="309.5,280.5234,299.5,284.5234,309.5,288.5234,305.5,284.5234" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="481.5" y1="284.5234" y2="284.5234"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="88" x="315.5" y="279.4575" style="white-space: pre;">Access Token</text>
+              <polygon fill="#181818" points="612.5,309.6563,622.5,313.6563,612.5,317.6563,616.5,313.6563" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="618.5" y1="313.6563" y2="313.6563"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="302" x="305.5" y="308.5903" style="white-space: pre;">Retrieve Authorisation Servers + Access Token</text>
+              <polygon fill="#181818" points="309.5,338.7891,299.5,342.7891,309.5,346.7891,305.5,342.7891" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="623.5" y1="342.7891" y2="342.7891"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="138" x="315.5" y="337.7231" style="white-space: pre;">Authorisation Servers</text>
+              <polygon fill="#181818" points="865.5,367.9219,875.5,371.9219,865.5,375.9219,869.5,371.9219" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="871.5" y1="371.9219" y2="371.9219"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="195" x="305.5" y="366.856" style="white-space: pre;">Retrieve OpenID Configuration</text>
+              <polygon fill="#181818" points="309.5,397.0547,299.5,401.0547,309.5,405.0547,305.5,401.0547" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="876.5" y1="401.0547" y2="401.0547"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="221" x="315.5" y="395.9888" style="white-space: pre;">JSON OpenID Discovery Clause 4.2</text>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="340.5" y1="430.1875" y2="430.1875"></line>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="340.5" x2="340.5" y1="430.1875" y2="443.1875"></line>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="299.5" x2="340.5" y1="443.1875" y2="443.1875"></line>
+              <polygon fill="#181818" points="309.5,439.1875,299.5,443.1875,309.5,447.1875,305.5,443.1875" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="165" x="305.5" y="425.1216" style="white-space: pre;">Extract Desired MetaData</text>
+              <polygon fill="#181818" points="612.5,468.3203,622.5,472.3203,612.5,476.3203,616.5,472.3203" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="618.5" y1="472.3203" y2="472.3203"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="83" x="305.5" y="467.2544" style="white-space: pre;">Retrieve SSA</text>
+              <polygon fill="#181818" points="309.5,497.4531,299.5,501.4531,309.5,505.4531,305.5,501.4531" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="623.5" y1="501.4531" y2="501.4531"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="54" x="315.5" y="496.3872" style="white-space: pre;">SSA JWT</text>
+              <polygon fill="#181818" points="865.5,526.5859,875.5,530.5859,865.5,534.5859,869.5,530.5859" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="871.5" y1="530.5859" y2="530.5859"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="332" x="305.5" y="525.52" style="white-space: pre;">Post RFC7591 with SSA JWT as software_statement</text>
+              <polygon fill="#181818" points="1097.5,555.7188,1107.5,559.7188,1097.5,563.7188,1101.5,559.7188" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="877.5" x2="1103.5" y1="559.7188" y2="559.7188"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="160" x="884.5" y="554.6528" style="white-space: pre;">Check Revocation Status</text>
+              <polygon fill="#181818" points="888.5,584.8516,878.5,588.8516,888.5,592.8516,884.5,588.8516" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="882.5" x2="1108.5" y1="588.8516" y2="588.8516"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="88" x="894.5" y="583.7856" style="white-space: pre;">Certificate OK</text>
+              <polygon fill="#181818" points="757.5,613.9844,747.5,617.9844,757.5,621.9844,753.5,617.9844" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="751.5" x2="876.5" y1="617.9844" y2="617.9844"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="107" x="763.5" y="612.9185" style="white-space: pre;">Retrieve Key Set</text>
+              <polygon fill="#181818" points="865.5,643.1172,875.5,647.1172,865.5,651.1172,869.5,647.1172" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="746.5" x2="871.5" y1="647.1172" y2="647.1172"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="96" x="753.5" y="642.0513" style="white-space: pre;">Return Key Set</text>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="877.5" x2="919.5" y1="676.25" y2="676.25"></line>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="919.5" x2="919.5" y1="676.25" y2="689.25"></line>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="878.5" x2="919.5" y1="689.25" y2="689.25"></line>
+              <polygon fill="#181818" points="888.5,685.25,878.5,689.25,888.5,693.25,884.5,689.25" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="218" x="884.5" y="671.1841" style="white-space: pre;">Validate SSA in RFC 7591 Request</text>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="877.5" x2="919.5" y1="718.3828" y2="718.3828"></line>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="919.5" x2="919.5" y1="718.3828" y2="731.3828"></line>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="878.5" x2="919.5" y1="731.3828" y2="731.3828"></line>
+              <polygon fill="#181818" points="888.5,727.3828,878.5,731.3828,888.5,735.3828,884.5,731.3828" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="170" x="884.5" y="713.3169" style="white-space: pre;">Validate RFC7591 Request</text>
+              <path d="M5,744.3828 L5,784.3828 L294,784.3828 L294,754.3828 L284,744.3828 L5,744.3828 " fill="#FEFFDD" style="stroke:#181818;stroke-width:0.5;"></path>
+              <path d="M284,744.3828 L284,754.3828 L294,754.3828 L284,744.3828 " fill="#FEFFDD" style="stroke:#181818;stroke-width:0.5;"></path>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="268" x="11" y="761.4497" style="white-space: pre;">Request must be made to token endpoint</text>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="154" x="11" y="776.5825" style="white-space: pre;">secured with mutual tls.</text>
+              <polygon fill="#181818" points="309.5,806.7813,299.5,810.7813,309.5,814.7813,305.5,810.7813" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <line style="stroke:#181818;stroke-width:1.0;stroke-dasharray:2.0,2.0;" x1="303.5" x2="876.5" y1="810.7813" y2="810.7813"></line>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="448" x="315.5" y="805.7153" style="white-space: pre;">Return RFC7591 Client Configuration +   RFC7592 Management Token</text>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="298.5" x2="340.5" y1="839.9141" y2="839.9141"></line>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="340.5" x2="340.5" y1="839.9141" y2="852.9141"></line>
+              <line style="stroke:#181818;stroke-width:1.0;" x1="299.5" x2="340.5" y1="852.9141" y2="852.9141"></line>
+              <polygon fill="#181818" points="309.5,848.9141,299.5,852.9141,309.5,856.9141,305.5,852.9141" style="stroke:#181818;stroke-width:1.0;"></polygon>
+              <text fill="#000000" font-family="sans-serif" font-size="13" lengthAdjust="spacing" textLength="163" x="305.5" y="834.8481" style="white-space: pre;">Save Management Token</text>
+            </g>
+          </svg>
+        </div>
+<figcaption><a href="#figure-1" class="selfRef">Figure 1</a></figcaption></figure>
 <div id="exampleDcr">
 <section id="section-9.1">
         <h3 id="name-enviar-uma-solicita231227o-">
 <a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-enviar-uma-solicita231227o-" class="section-name selfRef">Enviar uma solicita&#231;&#227;o com uma declara&#231;&#227;o de software</a>
         </h3>
-<p id="section-9.1-1">Este exemplo inclui v&#225;rios campos opcionais, alguns dos quais podem n&#227;o ser aplic&#225;veis a algumas implanta&#231;&#245;es. Para um guia completo dos atributos e sua obrigatoriedade, consultar o Swagger DCR --link aqui--.
+<p id="section-9.1-1">Este exemplo inclui v&#225;rios campos opcionais, alguns dos quais podem n&#227;o ser aplic&#225;veis a algumas implanta&#231;&#245;es. Para um guia completo dos atributos e sua obrigatoriedade, consultar o Swagger DCR <a href="https://raw.githubusercontent.com/OpenBanking-Brasil/specs-seguranca/main/dcr_review/dcr-dcm-swagger.yaml">OBB-DCR/DCM-Swagger</a>.
 A quebra de linha dentro dos valores s&#227;o apenas para fins de exibi&#231;&#227;o.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
-<div class="artwork art-text alignLeft" id="section-9.1-2">
+<div class="alignLeft art-text artwork" id="section-9.1-2">
 <pre>POST /reg HTTP/1.1
 Host: auth.raidiam.com
 Content-Type: application/json
@@ -1760,20 +1965,16 @@ <h3 id="name-sobre-os-mecanismos-de-aute">
           <h4 id="name-registro-de-cliente-post-re">
 <a href="#section-9.3.1" class="section-number selfRef">9.3.1. </a><a href="#name-registro-de-cliente-post-re" class="section-name selfRef">Registro de cliente - POST /register</a>
           </h4>
-<ol start="1" type="1" class="normal type-1" id="section-9.3.1-1">
-            <li id="section-9.3.1-1.1">
-              <p id="section-9.3.1-1.1.1">validar que o certificado apresentado pela aplica&#231;&#227;o cliente &#233; subordinado &#224;s cadeias do ICP-Brasil definidas no Padr&#227;o de Certificados do Open Banking Brasil;<a href="#section-9.3.1-1.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-9.3.1-1">
+<li id="section-9.3.1-1.1">validar que o certificado apresentado pela aplica&#231;&#227;o cliente &#233; subordinado &#224;s cadeias do ICP-Brasil definidas no Padr&#227;o de Certificados do Open Banking Brasil;<a href="#section-9.3.1-1.1" class="pilcrow">¶</a>
 </li>
-<li id="section-9.3.1-1.2">
-              <p id="section-9.3.1-1.2.1">assegurar que a assinatura do <em>software_statement</em> apresentado pela aplica&#231;&#227;o cliente durante o registro tenha sido feita pelo Diret&#243;rio de Participantes atrav&#233;s das chaves p&#250;blicas descritas na se&#231;&#227;o anterior;<a href="#section-9.3.1-1.2.1" class="pilcrow">¶</a></p>
+            <li id="section-9.3.1-1.2">assegurar que a assinatura do <em>software_statement</em> apresentado pela aplica&#231;&#227;o cliente durante o registro tenha sido feita pelo Diret&#243;rio de Participantes atrav&#233;s das chaves p&#250;blicas descritas na se&#231;&#227;o anterior;<a href="#section-9.3.1-1.2" class="pilcrow">¶</a>
 </li>
-<li id="section-9.3.1-1.3">
-              <p id="section-9.3.1-1.3.1">assegurar que o <em>software_statement</em> apresentado pela aplica&#231;&#227;o cliente durante o registro corresponda &#224; mesma institui&#231;&#227;o do certificado de cliente apresentado, validando-o atrav&#233;s dos atributos que trazem <code>organization_id</code> no certificado X.509.<a href="#section-9.3.1-1.3.1" class="pilcrow">¶</a></p>
+            <li id="section-9.3.1-1.3">assegurar que o <em>software_statement</em> apresentado pela aplica&#231;&#227;o cliente durante o registro corresponda &#224; mesma institui&#231;&#227;o do certificado de cliente apresentado, validando-o atrav&#233;s dos atributos que trazem <code>organization_id</code> no certificado X.509.<a href="#section-9.3.1-1.3" class="pilcrow">¶</a>
 </li>
-<li id="section-9.3.1-1.4">
-              <p id="section-9.3.1-1.4.1">emitir, na resposta do registro, um <code>registration_access_token</code> para ser usado como token de autentica&#231;&#227;o nas opera&#231;&#245;es de manuten&#231;&#227;o da aplica&#231;&#227;o cliente registrada, seguindo as especifica&#231;&#245;es descritas na <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a>.<a href="#section-9.3.1-1.4.1" class="pilcrow">¶</a></p>
+            <li id="section-9.3.1-1.4">emitir, na resposta do registro, um <code>registration_access_token</code> para ser usado como token de autentica&#231;&#227;o nas opera&#231;&#245;es de manuten&#231;&#227;o da aplica&#231;&#227;o cliente registrada, seguindo as especifica&#231;&#245;es descritas na <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a>.<a href="#section-9.3.1-1.4" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 </section>
 </div>
 <div id="get-put-delete">
@@ -1781,14 +1982,12 @@ <h4 id="name-registro-de-cliente-post-re">
           <h4 id="name-manuten231227o-de-cliente-g">
 <a href="#section-9.3.2" class="section-number selfRef">9.3.2. </a><a href="#name-manuten231227o-de-cliente-g" class="section-name selfRef">Manuten&#231;&#227;o de cliente - GET /register - PUT /register - DELETE /register</a>
           </h4>
-<ol start="1" type="1" class="normal type-1" id="section-9.3.2-1">
-            <li id="section-9.3.2-1.1">
-              <p id="section-9.3.2-1.1.1">validar que o certificado apresentado pela aplica&#231;&#227;o cliente &#233; subordinado &#224;s cadeias do ICP-Brasil definidas no Padr&#227;o de Certificados do Open Banking Brasil;<a href="#section-9.3.2-1.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-9.3.2-1">
+<li id="section-9.3.2-1.1">validar que o certificado apresentado pela aplica&#231;&#227;o cliente &#233; subordinado &#224;s cadeias do ICP-Brasil definidas no Padr&#227;o de Certificados do Open Banking Brasil;<a href="#section-9.3.2-1.1" class="pilcrow">¶</a>
 </li>
-<li id="section-9.3.2-1.2">
-              <p id="section-9.3.2-1.2.1">validar a presen&#231;a e a correspond&#234;ncia do header Bearer <code>Authorization</code> contendo o valor do atributo <code>registration_access_token</code> retornado durante o registro do cliente correspondente.<a href="#section-9.3.2-1.2.1" class="pilcrow">¶</a></p>
+            <li id="section-9.3.2-1.2">validar a presen&#231;a e a correspond&#234;ncia do header Bearer <code>Authorization</code> contendo o valor do atributo <code>registration_access_token</code> retornado durante o registro do cliente correspondente.<a href="#section-9.3.2-1.2" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 <p id="section-9.3.2-2"><em>Observa&#231;&#227;o:</em> A <a href="https://tools.ietf.org/html/rfc7592">RFC7592</a> prev&#234; a possibilidade de rota&#231;&#227;o do <code>registration_access_token</code> emitido pelo Servidor de Autoriza&#231;&#227;o a cada uso, tornando-o um token de uso &#250;nico. As institui&#231;&#245;es devem considerar esse aspecto no registro de suas aplica&#231;&#245;es cliente para receber e atualizar o <code>registration_access_token</code> pelo novo valor recebido nas chamadas de manuten&#231;&#227;o de cliente.<a href="#section-9.3.2-2" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -1803,69 +2002,56 @@ <h2 id="name-reconhecimento">
       </h2>
 <p id="section-10-1">Agradecemos a todos que estabeleceram as bases para o compartilhamento seguro de dados por meio da forma&#231;&#227;o do Grupo de Trabalho OpenID Foundation FAPI, o GT de Seguran&#231;a do Open Banking Brasil e aos pioneiros que ficar&#227;o em seus ombros.<a href="#section-10-1" class="pilcrow">¶</a></p>
 <p id="section-10-2">As seguintes pessoas contribu&#237;ram para este documento:<a href="#section-10-2" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-10-3.1">
-          <p id="section-10-3.1.1">Ralph Bragg (Raidiam)<a href="#section-10-3.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-10-3.1">Alexandre Daniel Dalabrida (Cooperativa Central Ailos)<a href="#section-10-3.1" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-10-3.2">Alexandre Siqueira (Mercado Pago)<a href="#section-10-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.2">
-          <p id="section-10-3.2.1">Alexandre Siqueira (Mercado Pago)<a href="#section-10-3.2.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.3">Andr&#233; Borges (Banco Fibra)<a href="#section-10-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.3">
-          <p id="section-10-3.3.1">Bernardo Vale (Banco Inter)<a href="#section-10-3.3.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.4">Bernardo Vale (Banco Inter)<a href="#section-10-3.4" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.4">
-          <p id="section-10-3.4.1">Andr&#233; Borges (Banco Fibra)<a href="#section-10-3.4.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.5">Danilo Sasaki (Banco Ita&#250;)<a href="#section-10-3.5" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.5">
-          <p id="section-10-3.5.1">Danilo Sasaki (Banco Ita&#250;)<a href="#section-10-3.5.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.6">Jo&#227;o Rodolfo Vieira da Silva (Banco Ita&#250;)<a href="#section-10-3.6" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.6">
-          <p id="section-10-3.6.1">Jo&#227;o Rodolfo Vieira da Silva (Banco Ita&#250;)<a href="#section-10-3.6.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.7">Michelle Bandarra (Chicago)<a href="#section-10-3.7" class="pilcrow">¶</a>
 </li>
-<li id="section-10-3.7">
-          <p id="section-10-3.7.1">Michelle Bandarra (Chicago)<a href="#section-10-3.7.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-10-3.8">Nic Marcondes (Quanto)<a href="#section-10-3.8" class="pilcrow">¶</a>
 </li>
-</ul>
+        <li class="compact" id="section-10-3.9">Rafael Gonzalez Hashimoto (Banco C6)<a href="#section-10-3.9" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-10-3.10">Ralph Bragg (Raidiam)<a href="#section-10-3.10" class="pilcrow">¶</a>
+</li>
+      </ul>
 </section>
 </div>
 <div id="Notice">
-<section id="section-appendix.a">
+<section id="appendix-A">
       <h2 id="name-avisos">
-<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-avisos" class="section-name selfRef">Avisos</a>
+<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-avisos" class="section-name selfRef">Avisos</a>
       </h2>
-<p id="section-appendix.a-1">Copyright (c) 2021 Estrutura Inicial do Open Banking Brasil<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
-<p id="section-appendix.a-2">A Estrutura Inicial do Open Banking Brasil (EIOBB) concede a qualquer Colaborador, desenvolvedor, implementador ou outra parte interessada uma licen&#231;a de direitos autorais mundial n&#227;o exclusiva, livre de royalties para reproduzir, preparar trabalhos derivados, distribuir, executar e exibir, estes Implementadores Rascunho ou Especifica&#231;&#227;o Final exclusivamente para fins de (i) desenvolver especifica&#231;&#245;es e (ii) implementar Rascunhos de Implementadores e Especifica&#231;&#245;es Finais com base em tais documentos, desde que a atribui&#231;&#227;o seja feita ao EIOBB como a fonte do material, mas que tal atribui&#231;&#227;o o fa&#231;a n&#227;o indica endosso do EIOBB.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
-<p id="section-appendix.a-3">A tecnologia descrita nesta especifica&#231;&#227;o foi disponibilizada a partir de contribui&#231;&#245;es de v&#225;rias fontes, incluindo membros da OpenID Foundation, do Grupo de Trabalho de Seguran&#231;a do Open Banking Brasil e outros. Embora a Estrutura Inicial do Open Banking Brasil tenha tomado medidas para ajudar a garantir que a tecnologia esteja dispon&#237;vel para distribui&#231;&#227;o, ela n&#227;o toma posi&#231;&#227;o quanto &#224; validade ou escopo de qualquer propriedade intelectual ou outros direitos que possam ser reivindicados como pertencentes &#224; implementa&#231;&#227;o ou uso do tecnologia descrita nesta especifica&#231;&#227;o ou at&#233; que ponto qualquer licen&#231;a sob tais direitos pode ou n&#227;o estar dispon&#237;vel; nem representa que fez qualquer esfor&#231;o independente para identificar tais direitos. A Estrutura Inicial do Open Banking Brasil e os contribuidores desta especifica&#231;&#227;o n&#227;o oferecem (e por meio deste expressamente se isentam de quaisquer) garantias (expressas, impl&#237;citas ou de outra forma), incluindo garantias impl&#237;citas de comercializa&#231;&#227;o, n&#227;o viola&#231;&#227;o, adequa&#231;&#227;o a uma finalidade espec&#237;fica ou t&#237;tulo, relacionados a esta especifica&#231;&#227;o, e todo o risco quanto &#224; implementa&#231;&#227;o desta especifica&#231;&#227;o &#233; assumido pelo implementador. A pol&#237;tica de Direitos de Propriedade Intelectual do Open Banking Brasil exige que os contribuidores ofere&#231;am uma promessa de patente de n&#227;o fazer valer certas reivindica&#231;&#245;es de patentes contra outros contribuidores e implementadores. A Estrutura Inicial do Open Banking Brasil convida qualquer parte interessada a trazer &#224; sua aten&#231;&#227;o quaisquer direitos autorais, patentes, pedidos de patentes ou outros direitos de propriedade que possam abranger a tecnologia que possa ser necess&#225;ria para praticar esta especifica&#231;&#227;o.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
+<p id="appendix-A-1">Copyright (c) 2022 Estrutura Inicial do Open Banking Brasil<a href="#appendix-A-1" class="pilcrow">¶</a></p>
+<p id="appendix-A-2">A Estrutura Inicial do Open Banking Brasil (EIOBB) concede a qualquer Colaborador, desenvolvedor, implementador ou outra parte interessada uma licen&#231;a de direitos autorais mundial n&#227;o exclusiva, livre de royalties para reproduzir, preparar trabalhos derivados, distribuir, executar e exibir, estes Implementadores Rascunho ou Especifica&#231;&#227;o Final exclusivamente para fins de (i) desenvolver especifica&#231;&#245;es e (ii) implementar Rascunhos de Implementadores e Especifica&#231;&#245;es Finais com base em tais documentos, desde que a atribui&#231;&#227;o seja feita ao EIOBB como a fonte do material, mas que tal atribui&#231;&#227;o o fa&#231;a n&#227;o indica endosso do EIOBB.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
+<p id="appendix-A-3">A tecnologia descrita nesta especifica&#231;&#227;o foi disponibilizada a partir de contribui&#231;&#245;es de v&#225;rias fontes, incluindo membros da OpenID Foundation, do Grupo de Trabalho de Seguran&#231;a do Open Banking Brasil e outros. Embora a Estrutura Inicial do Open Banking Brasil tenha tomado medidas para ajudar a garantir que a tecnologia esteja dispon&#237;vel para distribui&#231;&#227;o, ela n&#227;o toma posi&#231;&#227;o quanto &#224; validade ou escopo de qualquer propriedade intelectual ou outros direitos que possam ser reivindicados como pertencentes &#224; implementa&#231;&#227;o ou uso do tecnologia descrita nesta especifica&#231;&#227;o ou at&#233; que ponto qualquer licen&#231;a sob tais direitos pode ou n&#227;o estar dispon&#237;vel; nem representa que fez qualquer esfor&#231;o independente para identificar tais direitos. A Estrutura Inicial do Open Banking Brasil e os contribuidores desta especifica&#231;&#227;o n&#227;o oferecem (e por meio deste expressamente se isentam de quaisquer) garantias (expressas, impl&#237;citas ou de outra forma), incluindo garantias impl&#237;citas de comercializa&#231;&#227;o, n&#227;o viola&#231;&#227;o, adequa&#231;&#227;o a uma finalidade espec&#237;fica ou t&#237;tulo, relacionados a esta especifica&#231;&#227;o, e todo o risco quanto &#224; implementa&#231;&#227;o desta especifica&#231;&#227;o &#233; assumido pelo implementador. A pol&#237;tica de Direitos de Propriedade Intelectual do Open Banking Brasil exige que os contribuidores ofere&#231;am uma promessa de patente de n&#227;o fazer valer certas reivindica&#231;&#245;es de patentes contra outros contribuidores e implementadores. A Estrutura Inicial do Open Banking Brasil convida qualquer parte interessada a trazer &#224; sua aten&#231;&#227;o quaisquer direitos autorais, patentes, pedidos de patentes ou outros direitos de propriedade que possam abranger a tecnologia que possa ser necess&#225;ria para praticar esta especifica&#231;&#227;o.<a href="#appendix-A-3" class="pilcrow">¶</a></p>
 <div id="ExampleA">
-<section id="section-a.1">
-        <h2 id="name-ap234ndice-a-exemplo-de-afi">
-<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-ap234ndice-a-exemplo-de-afi" class="section-name selfRef">Ap&#234;ndice A. Exemplo de afirma&#231;&#227;o de declara&#231;&#227;o de software</a>
-        </h2>
-<div class="artwork art-text alignLeft" id="section-a.1-1">
+<section id="appendix-A.1">
+        <h3 id="name-ap234ndice-a-exemplo-de-afi">
+<a href="#appendix-A.1" class="section-number selfRef">A.1. </a><a href="#name-ap234ndice-a-exemplo-de-afi" class="section-name selfRef">Ap&#234;ndice A. Exemplo de afirma&#231;&#227;o de declara&#231;&#227;o de software</a>
+        </h3>
+<div class="alignLeft art-text artwork" id="appendix-A.1-1">
 <pre>eyJraWQiOiJzaWduZXIiLCJ0eXAiOiJKV1QiLCJhbGciOiJQUzI1NiJ9.eyJzb2Z0d2FyZV9tb2RlIjoiTGl2ZSIsInNvZnR3YXJlX3JlZGlyZWN0X3VyaXMiOlsiaHR0cHM6XC9cL3d3dy5yYWlkaWFtLmNvbVwvYWNjb3VudGluZ1wvY2IiXSwic29mdHdhcmVfc3RhdGVtZW50X3JvbGVzIjpbeyJyb2xlIjoiREFET1MiLCJhdXRob3Jpc2F0aW9uX2RvbWFpbiI6Ik9wZW4gQmFua2luZyIsInN0YXR1cyI6IkFjdGl2ZSJ9LHsicm9sZSI6IlBBR1RPIiwiYXV0aG9yaXNhdGlvbl9kb21haW4iOiJPcGVuIEJhbmtpbmciLCJzdGF0dXMiOiJBY3RpdmUifV0sInNvZnR3YXJlX2NsaWVudF9uYW1lIjoiUmFpZGlhbSBBY2NvdW50aW5nIiwib3JnX3N0YXR1cyI6IkFjdGl2ZSIsInNvZnR3YXJlX2NsaWVudF9pZCI6IkNraTFFYnZqd3loUEIxMk5HTGx6MiIsImlzcyI6Ik9wZW4gQmFua2luZyBPcGVuIEJhbmtpbmcgQnJhc2lsIHByb2QgU1NBIGlzc3VlciIsInNvZnR3YXJlX3Rvc191cmkiOiJodHRwczpcL1wvd3d3LnJhaWRpYW0uY29tXC9hY2NvdW50aW5nXC90b3MuaHRtbCIsInNvZnR3YXJlX2NsaWVudF9kZXNjcmlwdGlvbiI6IlJhaWRpYW0gQWNjb3VudGluZyBsZXZlcmFnZSBjdXR0aW5nIGVkZ2Ugb3BlbiBiYW5raW5nIGFjY2VzcyB0byBicmluZyB5b3UgcmVhbCB0aW1lIHVwIHRvIGRhdGUgdmlld3Mgb2YgeW91ciBmaW5hbmNlcyIsInNvZnR3YXJlX2p3a3NfZW5kcG9pbnQiOiJodHRwczpcL1wva2V5c3RvcmUuZGlyZWN0b3J5Lm9wZW5iYW5raW5nYnJhc2lsLm9yZy5iclwvYjk2MWM0ZWItNTA5ZC00ZWRmLWFmZWItMzU2NDJiMzgxODVkXC8yNTU1NmQ1YS1iOWRkLTRlMjctYWExYS1jY2U3MzJmZTc0ZGVcL2FwcGxpY2F0aW9uLmp3a3MiLCJzb2Z0d2FyZV9wb2xpY3lfdXJpIjoiaHR0cHM6XC9cL3d3dy5yYWlkaWFtLmNvbVwvYWNjb3VudGluZ1wvcG9saWN5Lmh0bWwiLCJzb2Z0d2FyZV9pZCI6IjI1NTU2ZDVhLWI5ZGQtNGUyNy1hYTFhLWNjZTczMmZlNzRkZSIsInNvZnR3YXJlX2NsaWVudF91cmkiOiJodHRwczpcL1wvd3d3LnJhaWRpYW0uY29tXC9hY2NvdW50aW5nLmh0bWwiLCJzb2Z0d2FyZV9qd2tzX2luYWN0aXZlX2VuZHBvaW50IjoiaHR0cHM6XC9cL2tleXN0b3JlLmRpcmVjdG9yeS5vcGVuYmFua2luZ2JyYXNpbC5vcmcuYnJcL2I5NjFjNGViLTUwOWQtNGVkZi1hZmViLTM1NjQyYjM4MTg1ZFwvMjU1NTZkNWEtYjlkZC00ZTI3LWFhMWEtY2NlNzMyZmU3NGRlXC9pbmFjdGl2ZVwvYXBwbGljYXRpb24uandrcyIsInNvZnR3YXJlX2p3a3NfdHJhbnNwb3J0X2luYWN0aXZlX2VuZHBvaW50IjoiaHR0cHM6XC9cL2tleXN0b3JlLmRpcmVjdG9yeS5vcGVuYmFua2luZ2JyYXNpbC5vcmcuYnJcL2I5NjFjNGViLTUwOWQtNGVkZi1hZmViLTM1NjQyYjM4MTg1ZFwvMjU1NTZkNWEtYjlkZC00ZTI3LWFhMWEtY2NlNzMyZmU3NGRlXC9pbmFjdGl2ZVwvdHJhbnNwb3J0Lmp3a3MiLCJzb2Z0d2FyZV9qd2tzX3RyYW5zcG9ydF9lbmRwb2ludCI6Imh0dHBzOlwvXC9rZXlzdG9yZS5kaXJlY3Rvcnkub3BlbmJhbmtpbmdicmFzaWwub3JnLmJyXC9iOTYxYzRlYi01MDlkLTRlZGYtYWZlYi0zNTY0MmIzODE4NWRcLzI1NTU2ZDVhLWI5ZGQtNGUyNy1hYTFhLWNjZTczMmZlNzRkZVwvdHJhbnNwb3J0Lmp3a3MiLCJzb2Z0d2FyZV9sb2dvX3VyaSI6Imh0dHBzOlwvXC93d3cucmFpZGlhbS5jb21cL2FjY291bnRpbmdcL2xvZ28ucG5nIiwib3JnX2lkIjoiYjk2MWM0ZWItNTA5ZC00ZWRmLWFmZWItMzU2NDJiMzgxODVkIiwic29mdHdhcmVfZW52aXJvbm1lbnQiOiJwcm9kdWN0aW9uIiwic29mdHdhcmVfdmVyc2lvbiI6MS4xMCwic29mdHdhcmVfcm9sZXMiOlsiREFET1MiLCJQQUdUTyJdLCJvcmdfbmFtZSI6Ik9wZW4gQmFua2luZyBCcmFzaWwiLCJpYXQiOjE2MTgzMzYyNjIsIm9yZ2FuaXNhdGlvbl9jb21wZXRlbnRfYXV0aG9yaXR5X2NsYWltcyI6W3siYXV0aG9yaXNhdGlvbl9kb21haW4iOiJPcGVuIEJhbmtpbmciLCJhdXRob3Jpc2F0aW9ucyI6W10sInJlZ2lzdHJhdGlvbl9pZCI6IjEzMzUzMjM2LU9CQi1DT05UQSIsImF1dGhvcml0eV9pZCI6IjY4N2ExYzk0LWIzNjAtNGUwNC05NTg5LTBmYTVjYjE2NDUxYiIsImF1dGhvcmlzYXRpb25fcm9sZSI6IkNPTlRBIiwiYXV0aG9yaXR5X2NvZGUiOiJCQ0IiLCJzdGF0dXMiOiJBY3RpdmUifSx7ImF1dGhvcmlzYXRpb25fZG9tYWluIjoiT3BlbiBCYW5raW5nIiwiYXV0aG9yaXNhdGlvbnMiOltdLCJyZWdpc3RyYXRpb25faWQiOiIxMzM1MzIzNi1PQkItREFET1MiLCJhdXRob3JpdHlfaWQiOiI2ODdhMWM5NC1iMzYwLTRlMDQtOTU4OS0wZmE1Y2IxNjQ1MWIiLCJhdXRob3Jpc2F0aW9uX3JvbGUiOiJEQURPUyIsImF1dGhvcml0eV9jb2RlIjoiQkNCIiwic3RhdHVzIjoiQWN0aXZlIn0seyJhdXRob3Jpc2F0aW9uX2RvbWFpbiI6Ik9wZW4gQmFua2luZyIsImF1dGhvcmlzYXRpb25zIjpbXSwicmVnaXN0cmF0aW9uX2lkIjoiMTMzNTMyMzYtT0JCLVBBR1RPIiwiYXV0aG9yaXR5X2lkIjoiNjg3YTFjOTQtYjM2MC00ZTA0LTk1ODktMGZhNWNiMTY0NTFiIiwiYXV0aG9yaXNhdGlvbl9yb2xlIjoiUEFHVE8iLCJhdXRob3JpdHlfY29kZSI6IkJDQiIsInN0YXR1cyI6IkFjdGl2ZSJ9XX0.W6hUAYhjT6I61rxEIVMKYKre93LTbRdzKnk9dJvUdzVgAz5B9KxZNutf27oO3k0hrjYVWBdWq23o_e4Y_AaKdpS9-rtU84JiHtmqV0wcFYIM8nqcUVWqQ-Ux6Nq9L2G-s2YNd3PcJ1e3yGg9h8553Gr7iJusKEgApzXUpkM2rBELQuumktUE_JBiuIkXmWxoRnO1cW-Osbk3MT3bxG43SPcxii07Q5S8qXI6PjCPA3fYlnaUAygwZM3O0oa7jqmSr7d9UsHuDMJfYhIKdq2wyQQKORCN-D2UopmMX-lHMvAVkkrAO08T0-7odjr4PJk-PrwuoCxeAfa7440ZDOrlmQ
-</pre><a href="#section-a.1-1" class="pilcrow">¶</a>
+</pre><a href="#appendix-A.1-1" class="pilcrow">¶</a>
 </div>
 </section>
 </div>
 </section>
 </div>
 <div id="authors-addresses">
-<section id="section-appendix.b">
-      <h2 id="name-authors-addresses">
-<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
+<section id="appendix-B">
+      <h2 id="name-authors-address">
+<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
       </h2>
-<address class="vcard">
-        <div dir="auto" class="left"><span class="fn nameRole">Ralph Bragg</span></div>
-<div dir="auto" class="left"><span class="org">Raidiam</span></div>
-<div class="email">
-<span>Email:</span>
-<a href="mailto:ralph.bragg@raidiam.com" class="email">ralph.bragg@raidiam.com</a>
-</div>
-<div class="url">
-<span>URI:</span>
-<a href="https://www.raidiam.com/" class="url">https://www.raidiam.com/</a>
-</div>
-</address>
 <address class="vcard">
         <div dir="auto" class="left"><span class="fn nameRole">OBBIS GT Security</span></div>
 <div dir="auto" class="left"><span class="org">Open Banking Brasil Initial Structure</span></div>
diff --git a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
index 5d82ba8..f4afbb4 100644
--- a/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
+++ b/open-banking-brasil-dynamic-client-registration-1_ID2-ptbr.md
@@ -17,16 +17,6 @@
     status = "standard"
     value = "open-banking-brasil-dynamic-client-registration-1_ID2-ptbr"
 
-    [[author]]
-    initials = "R."
-    surname = "Bragg"
-    fullname = "Ralph Bragg"
-    organization = "Raidiam"
-    abbrev = "Raidiam"
-      [author.address]
-      email = "ralph.bragg@raidiam.com"
-      uri = "https://www.raidiam.com/"
-
     [[author]]
     initials = "GT"
     surname = "Security"
@@ -160,23 +150,15 @@ Para efeitos deste documento, aplicam-se os termos definidos em [RFC6749], [RFC6
 
 # Símbolos e Termos abreviados  {#Abreviations}
 
-**SSA** – Software Statement Assertion (Afirmação de Declaração de Software)
-
-**SS** – Software Statement (Declaração de Software)
-
-**DCR** – Dynamic Client Registration (Registro de Cliente Dinâmico)
-
-**API** – Application Programming Interface (Interface de Programação da Aplicação)
-
-**FAPI** - Financial-grade API
-
-**HTTP** – Hyper Text Transfer Protocol
-
-**OIDF** - OpenID Foundation
-
-**REST** – Representational State Transfer
-
-**TLS** – Transport Layer Security
+* **API** – Application Programming Interface (Interface de Programação da Aplicação)
+* **DCR** – Dynamic Client Registration (Registro de Cliente Dinâmico)
+* **FAPI** - Financial-grade API
+* **HTTP** – Hyper Text Transfer Protocol
+* **OIDF** - OpenID Foundation
+* **REST** – Representational State Transfer
+* **SS** – Software Statement (Declaração de Software)
+* **SSA** – Software Statement Assertion (Afirmação de Declaração de Software)
+* **TLS** – Transport Layer Security
 
 # Introdução  {#Intro}
 
@@ -267,12 +249,12 @@ Segue na tabela abaixo como deve ser feita a decodificação:
 
 Seguem abaixo exemplos para os atributos obrigatórios da CAs atualmente ativas:
 
-| subject_dn | Issuer |
-| --- | --- |
-| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839, CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L= BRASILIA, ST=DF, C=BR | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR |
-| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, CN=mycn.bank.gov.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L=BRASILIA, ST=DF, C=BR | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, UID=67c57882-043b-11ec-9a03-0242ac130003, CN=openbanking.mybank.com.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Goiania, ST=GO, O=MyBank SA, C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
-| CN=mycn.bank.com.br, UID=67c57882-043b-11ec-9a03-0242ac130003, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Sao Paulo, ST=SP, O=MyBank SA, C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| subject_dn                                                                                                                                                                                                                                                                                | Issuer                                                                                                                 |
+|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, 2.5.4.5=#130d31333335333233363030313839, CN= mycn.bank.gov.br,OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L= BRASILIA, ST=DF, C=BR   | issuer=CN=Open Banking SANDBOX Issuing CA   - G1,OU=Open Banking,O=Open   Banking Brasil,C=BR                          |
+| UID=67c57882-043b-11ec-9a03-0242ac130003, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, CN=mycn.bank.gov.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, O=My Public Bank, L=BRASILIA, ST=DF, C=BR    | issuer=CN=Autoridade Certificadora do SERPRO SSLv1,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR |
+| 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e, UID=67c57882-043b-11ec-9a03-0242ac130003, CN=openbanking.mybank.com.br, 2.5.4.5=#130d31333335333233363030313839, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Goiania, ST=GO, O=MyBank SA, C=BR | issuer=CN=AC SOLUTI SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR                         |
+| CN=mycn.bank.com.br, UID=67c57882-043b-11ec-9a03-0242ac130003, OU=497e1ffe-b2a2-4a4e-8ef0-70633fd11b59, L=Sao Paulo, ST=SP, O=MyBank SA, C=BR,2.5.4.5=#130d31333335333233363030313839, 1.3.6.1.4.1.311.60.2.1.3=#13024252, 2.5.4.15=#131450726976617465204f7267616e697a6174696f6e         | issuer=CN=AC SERASA SSL EV,OU=Autoridade   Certificadora Raiz Brasileira v10,O=ICP-Brasil,C=BR                         |
 
 
 ## Funções regulatórias para mapeamentos OpenID e OAuth 2.0  {#Regs}
@@ -281,12 +263,12 @@ Para participar do ecossistema do Open Banking, as instituições credenciadas d
 
 A tabela a seguir descreve as funções regulatórias do Open Banking e o mapeamento de escopos do OAuth 2.0 relacionado. Se os escopos forem omitidos durante o processo de DCR, o Servidor de Autorização deve conceder o conjunto completo de escopos potenciais com base nas funções regulatórias registradas para o banco, conforme descrito na seção Server Defaults.
 
-| Papel Regulador | Descrição | Escopos Permitidos | Fase-alvo |
-| --- | --- | --- | --- |
-| DADOS | Instituição transmissora / receptora de dados (AISP) | openid accounts credit-cards-accounts consents customers invoice-financings financings loans unarranged-accounts-overdraft resources | Phase 2 |
-| PAGTO | Instituição prestadora de serviço de iniciação de pagamentos (PISP) | openid payments | Phase 3 |
-| CONTA | Instituição detentora de conta (ASPSP) | openid | Phase 3 |
-| CCORR | Correspondente de crédito | openid | Phase 3* |
+| Papel Regulador | Descrição                                                           | Escopos Permitidos                                                                                                                   | Fase-alvo |
+|-----------------|---------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|-----------|
+| DADOS           | Instituição transmissora / receptora de dados (AISP)                | openid accounts credit-cards-accounts consents customers invoice-financings financings loans unarranged-accounts-overdraft resources | Phase 2   |
+| PAGTO           | Instituição prestadora de serviço de iniciação de pagamentos (PISP) | openid payments                                                                                                                      | Phase 3   |
+| CONTA           | Instituição detentora de conta (ASPSP)                              | openid                                                                                                                               | Phase 3   |
+| CCORR           | Correspondente de crédito                                           | openid                                                                                                                               | Phase 3*  |
 
 É necessário validar as roles ativas no _software\_statement_ da aplicação. Na validação dessa informação deve ser utilizado o campo _software\_statement\_roles, e deve ser verificado se as roles listadas estão ativas.
 
@@ -384,7 +366,7 @@ O exemplo a seguir contém todos os atributos atualmente incluídos em um _softw
 # Processamento de solicitação de registro de cliente dinâmico  {#dcr}
 
 !---
-![Dynamic Client Registration](images/dynamic-client-registration.png)
+![Dynamic Client Registration](images/dynamic-client-registration.svg)
 !---
 
 ## Enviar uma solicitação com uma declaração de software  {#exampleDcr}
@@ -471,19 +453,22 @@ Agradecemos a todos que estabeleceram as bases para o compartilhamento seguro de
 
 As seguintes pessoas contribuíram para este documento:
 
-* Ralph Bragg (Raidiam)
+* Alexandre Daniel Dalabrida (Cooperativa Central Ailos)
 * Alexandre Siqueira (Mercado Pago)
-* Bernardo Vale (Banco Inter)
 * André Borges (Banco Fibra)
+* Bernardo Vale (Banco Inter)
 * Danilo Sasaki (Banco Itaú)
 * João Rodolfo Vieira da Silva (Banco Itaú)
 * Michelle Bandarra (Chicago)
+* Nic Marcondes (Quanto)
+* Rafael Gonzalez Hashimoto (Banco C6)
+* Ralph Bragg (Raidiam)
 
 {backmatter}
 
 # Avisos  {#Notice}
 
-Copyright (c) 2021 Estrutura Inicial do Open Banking Brasil
+Copyright (c) 2022 Estrutura Inicial do Open Banking Brasil
 
 A Estrutura Inicial do Open Banking Brasil (EIOBB) concede a qualquer Colaborador, desenvolvedor, implementador ou outra parte interessada uma licença de direitos autorais mundial não exclusiva, livre de royalties para reproduzir, preparar trabalhos derivados, distribuir, executar e exibir, estes Implementadores Rascunho ou Especificação Final exclusivamente para fins de (i) desenvolver especificações e (ii) implementar Rascunhos de Implementadores e Especificações Finais com base em tais documentos, desde que a atribuição seja feita ao EIOBB como a fonte do material, mas que tal atribuição o faça não indica endosso do EIOBB.
 

From 7f15fde66a4cc75d44c13499f384d0b1c6682e32 Mon Sep 17 00:00:00 2001
From: Nic <qbitnic@gmail.com>
Date: Thu, 17 Feb 2022 21:59:08 -0300
Subject: [PATCH 54/59] chore(md): Fix and export
 open-banking-brasil-financial-api-1_ID3.md

---
 open-banking-brasil-financial-api-1_ID3.html | 774 ++++++++++---------
 open-banking-brasil-financial-api-1_ID3.md   |  46 +-
 2 files changed, 429 insertions(+), 391 deletions(-)

diff --git a/open-banking-brasil-financial-api-1_ID3.html b/open-banking-brasil-financial-api-1_ID3.html
index 2f2971c..99b3a46 100644
--- a/open-banking-brasil-financial-api-1_ID3.html
+++ b/open-banking-brasil-financial-api-1_ID3.html
@@ -5,12 +5,29 @@
 <meta content="Common,Latin" name="scripts">
 <meta content="initial-scale=1.0" name="viewport">
 <title>Open Banking Brasil Financial-grade API Security Profile 1.0 Implementers Draft 3</title>
-<meta content="Ralph Bragg" name="author">
 <meta content="OBBIS GT Security" name="author">
-<meta content="xml2rfc 2.40.1" name="generator">
+<meta content="xml2rfc 3.12.2" name="generator">
 <meta content="FAPI" name="keyword">
 <meta content="Open Banking Brasil GT Security" name="keyword">
 <meta content="open-banking-brasil-financial-api-1_ID3" name="ietf.draft">
+<!-- Generator version information:
+  xml2rfc 3.12.2
+    Python 3.10.2
+    appdirs 1.4.4
+    ConfigArgParse 1.5.3
+    google-i18n-address 2.5.0
+    html5lib 1.1
+    intervaltree 3.1.0
+    Jinja2 2.11.3
+    kitchen 1.2.6
+    lxml 4.8.0
+    pycountry 22.1.10
+    pyflakes 2.4.0
+    PyYAML 6.0
+    requests 2.27.1
+    setuptools 58.1.0
+    six 1.16.0
+-->
 <link href="./open-banking-brasil-financial-api-1_ID3.xml" rel="alternate" type="application/rfc+xml">
 <link href="#copyright" rel="license">
 <style type="text/css">/*
@@ -179,6 +196,9 @@
 ul.empty li, .ulEmpty li {
   margin-top: 0.5em;
 }
+ul.ulBare, li.ulBare {
+  margin-left: 0em !important;
+}
 ul.compact, .ulCompact,
 ol.compact, .olCompact {
   line-height: 100%;
@@ -362,6 +382,12 @@
   float: left;
   margin-bottom: 0;
 }
+/* Fix PDF info block run off issue */
+@media print {
+  #identifiers dd {
+    float: none;
+  }
+}
 #identifiers .authors .author {
   display: inline-block;
   margin-right: 1.5em;
@@ -912,12 +938,6 @@
   }
 
 }
-/* Avoid wrapping of URLs in references */
-@media screen {
-  .references a {
-    white-space: nowrap;
-  }
-}
 /* Tweak the bcp14 keyword presentation */
 .bcp14 {
   font-variant: small-caps;
@@ -988,7 +1008,7 @@
 }
 /* Make .olPercent look the same as <ol><li> */
 dl.olPercent > dd {
-  margin: 0 0 0.25em 0;
+  margin-bottom: 0.25em;
   min-height: initial;
 }
 /* Give aside some styling to set it apart */
@@ -1026,14 +1046,6 @@
     margin-bottom: 1em;
   }
 }
-/*
-  The margin-left: 0 on <dd> removes all distinction
-  between levels from nested <dl>s.  Undo that.
-*/
-dl.olPercent > dd,
-dd {
-  margin-left: revert;
-}
 /* Avoid narrow tables forcing too narrow table captions, which may render badly */
 table {
   min-width: 20em;
@@ -1059,6 +1071,108 @@
   #toc nav { display: none; }
   #toc.active nav { display: block; }
 }
+/* Add support for keepWithNext */
+.keepWithNext {
+  break-after: avoid-page;
+  break-after: avoid-page;
+}
+/* Add support for keepWithPrevious */
+.keepWithPrevious {
+  break-before: avoid-page;
+}
+/* Change the approach to avoiding breaks inside artwork etc. */
+figure, pre, table, .artwork, .sourcecode  {
+  break-before: auto;
+  break-after: auto;
+}
+/* Avoid breaks between <dt> and <dd> */
+dl {
+  break-before: auto;
+  break-inside: auto;
+}
+dt {
+  break-before: auto;
+  break-after: avoid-page;
+}
+dd {
+  break-before: avoid-page;
+  break-after: auto;
+  orphans: 3;
+  widows: 3
+}
+span.break, dd.break {
+  margin-bottom: 0;
+  min-height: 0;
+  break-before: auto;
+  break-inside: auto;
+  break-after: auto;
+}
+/* Undo break-before ToC */
+@media print {
+  #toc {
+    break-before: auto;
+  }
+}
+/* Text in compact lists should not get extra bottim margin space,
+   since that would makes the list not compact */
+ul.compact p, .ulCompact p,
+ol.compact p, .olCompact p {
+ margin: 0;
+}
+/* But the list as a whole needs the extra space at the end */
+section ul.compact,
+section .ulCompact,
+section ol.compact,
+section .olCompact {
+  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
+}
+/* The tt and code background above interferes with for instance table cell
+   backgrounds.  Changed to something a bit more selective. */
+tt, code {
+  background-color: transparent;
+}
+p tt, p code, li tt, li code {
+  background-color: #f8f8f8;
+}
+/* Tweak the pre margin -- 0px doesn't come out well */
+pre {
+   margin-top: 0.5px;
+}
+/* Tweak the comact list text */
+ul.compact, .ulCompact,
+ol.compact, .olCompact,
+dl.compact, .dlCompact {
+  line-height: normal;
+}
+/* Don't add top margin for nested lists */
+li > ul, li > ol, li > dl,
+dd > ul, dd > ol, dd > dl,
+dl > dd > dl {
+  margin-top: initial;
+}
+/* Elements that should not be rendered on the same line as a <dt> */
+/* This should match the element list in writer.text.TextWriter.render_dl() */
+dd > div.artwork:first-child,
+dd > aside:first-child,
+dd > figure:first-child,
+dd > ol:first-child,
+dd > div:first-child > pre.sourcecode,
+dd > table:first-child,
+dd > ul:first-child {
+  clear: left;
+}
+/* fix for weird browser behaviour when <dd/> is empty */
+dt+dd:empty::before{
+  content: "\00a0";
+}
+/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
+li > p {
+  margin-bottom: 0.5em
+}
+/* Don't let p margin spill out from inside list items */
+li > p:last-of-type {
+  margin-bottom: 0;
+}
 </style>
 <link href="rfc-local.css" rel="stylesheet" type="text/css">
 </head>
@@ -1068,10 +1182,10 @@
 <thead><tr>
 <td class="left"></td>
 <td class="center">OBB-FAPI-1-ID3</td>
-<td class="right">September 2021</td>
+<td class="right">February 2022</td>
 </tr></thead>
 <tfoot><tr>
-<td class="left">Bragg & Security</td>
+<td class="left">Security</td>
 <td class="center">Standards Track</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
@@ -1081,20 +1195,8 @@
 <dl id="identifiers">
 <dt class="label-workgroup">Workgroup:</dt>
 <dd class="workgroup">Open Banking Brasil GT Security</dd>
-<dt class="label-internet-draft">Internet-Draft:</dt>
-<dd class="internet-draft">open-banking-brasil-financial-api-1_ID3</dd>
-<dt class="label-published">Published:</dt>
-<dd class="published">
-<time datetime="2021-09-27" class="published">27 September 2021</time>
-    </dd>
-<dt class="label-intended-status">Intended Status:</dt>
-<dd class="intended-status">Standards Track</dd>
-<dt class="label-authors">Authors:</dt>
+<dt class="label-authors">Author:</dt>
 <dd class="authors">
-<div class="author">
-      <div class="author-name">R. Bragg</div>
-<div class="org">Raidiam</div>
-</div>
 <div class="author">
       <div class="author-name">GT. Security</div>
 <div class="org">OBBIS</div>
@@ -1110,14 +1212,13 @@ <h2 id="name-foreword">
 <p id="section-note.1-1">Este documento tamb&#233;m est&#225; dispon&#237;vel em <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3-ptbr.html">portugu&#234;s</a><a href="#section-note.1-1" class="pilcrow">¶</a></p>
 <p id="section-note.1-2">The Open Banking Brasil Initial Structure is responsible for creating standards and specifications necessary to meet the requirements and obligations of the Brasil Open Banking Legislation as originally outlined by the <a href="https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf">Brasil Central Bank</a>. There is a possibility that some of the elements of this document may be the subject to patent rights. OBBIS shall not be held responsible for identifying any or all such patent rights.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
 <p id="section-note.1-3">Open Banking Brasil Financial-grade API Security Profile 1.0 consists of the following parts:<a href="#section-note.1-3" class="pilcrow">¶</a></p>
-<ul class="note">
-<li class="note" id="section-note.1-4.1">
-          <p id="section-note.1-4.1.1">Open Banking Brasil Financial-grade API Security Profile 1.0<a href="#section-note.1-4.1.1" class="pilcrow">¶</a></p>
+<ul class="compact note">
+<li class="compact note" id="section-note.1-4.1">Open Banking Brasil Financial-grade API Security Profile 1.0<a href="#section-note.1-4.1" class="pilcrow">¶</a>
 </li>
-<li class="note" id="section-note.1-4.2">
-          <p id="section-note.1-4.2.1"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1.html">Open Banking Brasil Dynamic Client Registration Profile 1.0</a><a href="#section-note.1-4.2.1" class="pilcrow">¶</a></p>
+        <li class="compact note" id="section-note.1-4.2">
+          <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html">Open Banking Brasil Dynamic Client Registration Profile 1.0</a><a href="#section-note.1-4.2" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 <p id="section-note.1-5">These parts are intended to be used with <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>, <a href="https://tools.ietf.org/html/rfc6750">RFC6750</a>, <a href="https://tools.ietf.org/html/rfc7636">RFC7636</a>, <a href="https://openid.net/specs/openid-connect-core-1_0.html">OIDC</a>, <a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">FAPI-1-Baseline</a> and <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">FAPI-1-Advanced</a><a href="#section-note.1-5" class="pilcrow">¶</a></p>
 </section>
 <section class="note" id="section-note.2">
@@ -1144,103 +1245,103 @@ <h2 id="name-notational-conventions">
         <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
 <a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
         </h2>
-<nav class="toc"><ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.1">
-            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-scope" class="xref">Scope</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
+<nav class="toc"><ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
+            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-scope" class="xref">Scope</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.2">
-            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-normative-references" class="xref">Normative references</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
+            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-normative-references" class="xref">Normative references</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.3">
-            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-terms-and-definitions" class="xref">Terms and definitions</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
+            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-terms-and-definitions" class="xref">Terms and definitions</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.4">
-            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-symbols-and-abbreviated-ter" class="xref">Symbols and Abbreviated terms</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
+            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-symbols-and-abbreviated-ter" class="xref">Symbols and Abbreviated terms</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.5">
-            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-brasil-open-banking-securit" class="xref">Brasil Open Banking Security Profile</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.5.2.1">
-                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-introduction-2" class="xref">Introduction</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
+            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-brasil-open-banking-securit" class="xref">Brasil Open Banking Security Profile</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
+                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-introduction-2" class="xref">Introduction</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.5.2.2">
-                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-open-banking-brasil-securit" class="xref">Open Banking Brasil security provisions</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.5.2.2.2.1">
-                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-introduction-3" class="xref">Introduction</a><a href="#section-toc.1-1.5.2.2.2.1.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
+                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-open-banking-brasil-securit" class="xref">Open Banking Brasil security provisions</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.1">
+                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-introduction-3" class="xref">Introduction</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.5.2.2.2.2">
-                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-authorization-server" class="xref">Authorization server</a><a href="#section-toc.1-1.5.2.2.2.2.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.2">
+                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-authorization-server" class="xref">Authorization server</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.5.2.2.2.3">
-                    <p id="section-toc.1-1.5.2.2.2.3.1"><a href="#section-5.2.3" class="xref">5.2.3</a>.  <a href="#name-confidential-client" class="xref">Confidential client</a><a href="#section-toc.1-1.5.2.2.2.3.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.3">
+                    <p id="section-toc.1-1.5.2.2.2.3.1"><a href="#section-5.2.3" class="xref">5.2.3</a>.  <a href="#name-confidential-client" class="xref">Confidential client</a></p>
 </li>
-</ul>
+                </ul>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.6">
-            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.1">
-                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-message-content-signing-con" class="xref">Message Content Signing Considerations (JWS)</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
+            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security considerations</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
+                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-message-content-signing-con" class="xref">Message Content Signing Considerations (JWS)</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.2">
-                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-algorithm-considerations" class="xref">Algorithm considerations</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.2.2.1">
-                    <p id="section-toc.1-1.6.2.2.2.1.1"><a href="#section-6.2.1" class="xref">6.2.1</a>.  <a href="#name-encryption-algorithm-consid" class="xref">Encryption algorithm considerations</a><a href="#section-toc.1-1.6.2.2.2.1.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
+                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-algorithm-considerations" class="xref">Algorithm considerations</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2.2.1">
+                    <p id="section-toc.1-1.6.2.2.2.1.1"><a href="#section-6.2.1" class="xref">6.2.1</a>.  <a href="#name-encryption-algorithm-consid" class="xref">Encryption algorithm considerations</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.2.2.2">
-                    <p id="section-toc.1-1.6.2.2.2.2.1"><a href="#section-6.2.2" class="xref">6.2.2</a>.  <a href="#name-secure-use-of-transport-lay" class="xref">Secure Use of Transport Layer Security considerations</a><a href="#section-toc.1-1.6.2.2.2.2.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2.2.2">
+                    <p id="section-toc.1-1.6.2.2.2.2.1"><a href="#section-6.2.2" class="xref">6.2.2</a>.  <a href="#name-secure-use-of-transport-lay" class="xref">Secure Use of Transport Layer Security considerations</a></p>
 </li>
-</ul>
+                </ul>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7">
-            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-data-sharing-considerations" class="xref">Data Sharing Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1">
-                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-authorisation-mechanism" class="xref">Authorisation Mechanism</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1.2.1">
-                    <p id="section-toc.1-1.7.2.1.2.1.1"><a href="#section-7.1.1" class="xref">7.1.1</a>.  <a href="#name-introduction-4" class="xref">Introduction</a><a href="#section-toc.1-1.7.2.1.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
+            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-data-sharing-considerations" class="xref">Data Sharing Considerations</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
+                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-authorisation-mechanism" class="xref">Authorisation Mechanism</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.1">
+                    <p id="section-toc.1-1.7.2.1.2.1.1"><a href="#section-7.1.1" class="xref">7.1.1</a>.  <a href="#name-introduction-4" class="xref">Introduction</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1.2.2">
-                    <p id="section-toc.1-1.7.2.1.2.2.1"><a href="#section-7.1.2" class="xref">7.1.2</a>.  <a href="#name-dynamic-consent-scope-defin" class="xref">Dynamic Consent Scope Definition</a><a href="#section-toc.1-1.7.2.1.2.2.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.2">
+                    <p id="section-toc.1-1.7.2.1.2.2.1"><a href="#section-7.1.2" class="xref">7.1.2</a>.  <a href="#name-dynamic-consent-scope-defin" class="xref">Dynamic Consent Scope Definition</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1.2.3">
-                    <p id="section-toc.1-1.7.2.1.2.3.1"><a href="#section-7.1.3" class="xref">7.1.3</a>.  <a href="#name-dynamic-consent-scope-examp" class="xref">Dynamic Consent Scope Example</a><a href="#section-toc.1-1.7.2.1.2.3.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.3">
+                    <p id="section-toc.1-1.7.2.1.2.3.1"><a href="#section-7.1.3" class="xref">7.1.3</a>.  <a href="#name-dynamic-consent-scope-examp" class="xref">Dynamic Consent Scope Example</a></p>
 </li>
-</ul>
+                </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.2">
-                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-authorisation-life-cycle" class="xref">Authorisation Life Cycle</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.1">
-                    <p id="section-toc.1-1.7.2.2.2.1.1"><a href="#section-7.2.1" class="xref">7.2.1</a>.  <a href="#name-introduction-5" class="xref">Introduction</a><a href="#section-toc.1-1.7.2.2.2.1.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
+                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-authorisation-life-cycle" class="xref">Authorisation Life Cycle</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2.2.1">
+                    <p id="section-toc.1-1.7.2.2.2.1.1"><a href="#section-7.2.1" class="xref">7.2.1</a>.  <a href="#name-introduction-5" class="xref">Introduction</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.2">
-                    <p id="section-toc.1-1.7.2.2.2.2.1"><a href="#section-7.2.2" class="xref">7.2.2</a>.  <a href="#name-authorization-server-2" class="xref">Authorization server</a><a href="#section-toc.1-1.7.2.2.2.2.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2.2.2">
+                    <p id="section-toc.1-1.7.2.2.2.2.1"><a href="#section-7.2.2" class="xref">7.2.2</a>.  <a href="#name-authorization-server-2" class="xref">Authorization server</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.3">
-                    <p id="section-toc.1-1.7.2.2.2.3.1"><a href="#section-7.2.3" class="xref">7.2.3</a>.  <a href="#name-confidential-client-2" class="xref">Confidential Client</a><a href="#section-toc.1-1.7.2.2.2.3.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2.2.3">
+                    <p id="section-toc.1-1.7.2.2.2.3.1"><a href="#section-7.2.3" class="xref">7.2.3</a>.  <a href="#name-confidential-client-2" class="xref">Confidential Client</a></p>
 </li>
-</ul>
+                </ul>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.8">
-            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
+            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.9">
-            <p id="section-toc.1-1.9.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-notices" class="xref">Notices</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
+            <p id="section-toc.1-1.9.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-notices" class="xref">Notices</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.10">
-            <p id="section-toc.1-1.10.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
+            <p id="section-toc.1-1.10.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a></p>
 </li>
-</ul>
+        </ul>
 </nav>
 </section>
 </div>
@@ -1250,17 +1351,14 @@ <h2 id="name-scope">
 <a href="#section-1" class="section-number selfRef">1. </a><a href="#name-scope" class="section-name selfRef">Scope</a>
       </h2>
 <p id="section-1-1">This document specifies the method of<a href="#section-1-1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-1-2.1">
-          <p id="section-1-2.1.1">applications to obtain the OAuth tokens in an appropriately secure manner for higher risk access to data in a manner that meets the requirements of <a href="https://www.in.gov.br/en/web/dou/-/resolucao-conjunta-n-1-de-4-de-maio-de-2020-255165055">Open Banking Brasil</a>;<a href="#section-1-2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-1-2.1">applications to obtain the OAuth tokens in an appropriately secure manner for higher risk access to data in a manner that meets the requirements of <a href="https://www.in.gov.br/en/web/dou/-/resolucao-conjunta-n-1-de-4-de-maio-de-2020-255165055">Open Banking Brasil</a>;<a href="#section-1-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-1-2.2">
-          <p id="section-1-2.2.1">applications to use OpenID Connect to identify the customer; and<a href="#section-1-2.2.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-1-2.2">applications to use OpenID Connect to identify the customer; and<a href="#section-1-2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-1-2.3">
-          <p id="section-1-2.3.1">applications to use OpenID Connect to assert identity of the customer;<a href="#section-1-2.3.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-1-2.3">applications to use OpenID Connect to assert identity of the customer;<a href="#section-1-2.3" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 <p id="section-1-3">This document is applicable to all participants engaging in Open Banking in Brasil.<a href="#section-1-3" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -1293,7 +1391,7 @@ <h2 id="name-normative-references">
 <p id="section-2-22"><a href="https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md">FAPI-2-Baseline</a> - Financial-grade API Security Profile 2.0 - Part 1: Baseline<a href="#section-2-22" class="pilcrow">¶</a></p>
 <p id="section-2-23"><a href="https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Advanced_Profile.md">FAPI-2-Advanced</a> - Financial-grade API Security Profile 2.0 - Part 2: Advanced<a href="#section-2-23" class="pilcrow">¶</a></p>
 <p id="section-2-24"><a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md">LIWP</a> - OIDF FAPI WG Lodging Intent Working Paper<a href="#section-2-24" class="pilcrow">¶</a></p>
-<p id="section-2-25"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1.html">OBB-FAPI-DCR</a> - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0<a href="#section-2-25" class="pilcrow">¶</a></p>
+<p id="section-2-25"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html">OBB-FAPI-DCR</a> - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0<a href="#section-2-25" class="pilcrow">¶</a></p>
 <p id="section-2-26"><a href="https://tools.ietf.org/html/rfc4648">RFC4648</a> - The Base16, Base32, and Base64 Data Encodings<a href="#section-2-26" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -1310,16 +1408,38 @@ <h2 id="name-terms-and-definitions">
       <h2 id="name-symbols-and-abbreviated-ter">
 <a href="#section-4" class="section-number selfRef">4. </a><a href="#name-symbols-and-abbreviated-ter" class="section-name selfRef">Symbols and Abbreviated terms</a>
       </h2>
-<p id="section-4-1"><strong>API</strong> - Application Programming Interface<a href="#section-4-1" class="pilcrow">¶</a></p>
-<p id="section-4-2"><strong>OBBIS</strong> - Open Banking Brasil Initial Structure<a href="#section-4-2" class="pilcrow">¶</a></p>
-<p id="section-4-3"><strong>CSRF</strong> - Cross Site Request Forgery<a href="#section-4-3" class="pilcrow">¶</a></p>
-<p id="section-4-4"><strong>DCR</strong> - Dynamic Client Registration<a href="#section-4-4" class="pilcrow">¶</a></p>
-<p id="section-4-5"><strong>FAPI</strong> - Financial-grade API<a href="#section-4-5" class="pilcrow">¶</a></p>
-<p id="section-4-6"><strong>HTTP</strong> - Hyper Text Transfer Protocol<a href="#section-4-6" class="pilcrow">¶</a></p>
-<p id="section-4-7"><strong>OIDF</strong> - OpenID Foundation<a href="#section-4-7" class="pilcrow">¶</a></p>
-<p id="section-4-8"><strong>REST</strong> - Representational State Transfer<a href="#section-4-8" class="pilcrow">¶</a></p>
-<p id="section-4-9"><strong>TLS</strong> - Transport Layer Security<a href="#section-4-9" class="pilcrow">¶</a></p>
-<p id="section-4-10"><strong>MFA</strong> - Multi-Factor Authentication<a href="#section-4-10" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-4-1.1">
+          <strong>API</strong> - Application Programming Interface<a href="#section-4-1.1" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.2">
+          <strong>CSRF</strong> - Cross Site Request Forgery<a href="#section-4-1.2" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.3">
+          <strong>DCR</strong> - Dynamic Client Registration<a href="#section-4-1.3" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.4">
+          <strong>FAPI</strong> - Financial-grade API<a href="#section-4-1.4" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.5">
+          <strong>HTTP</strong> - Hyper Text Transfer Protocol<a href="#section-4-1.5" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.6">
+          <strong>MFA</strong> - Multi-Factor Authentication<a href="#section-4-1.6" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.7">
+          <strong>OBBIS</strong> - Open Banking Brasil Initial Structure<a href="#section-4-1.7" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.8">
+          <strong>OIDF</strong> - OpenID Foundation<a href="#section-4-1.8" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.9">
+          <strong>REST</strong> - Representational State Transfer<a href="#section-4-1.9" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.10">
+          <strong>TLS</strong> - Transport Layer Security<a href="#section-4-1.10" class="pilcrow">¶</a>
+</li>
+      </ul>
 </section>
 </div>
 <div id="brasil-open-banking-security-profile">
@@ -1327,27 +1447,23 @@ <h2 id="name-symbols-and-abbreviated-ter">
       <h2 id="name-brasil-open-banking-securit">
 <a href="#section-5" class="section-number selfRef">5. </a><a href="#name-brasil-open-banking-securit" class="section-name selfRef">Brasil Open Banking Security Profile</a>
       </h2>
-<div id="introduction">
+<div id="introduction-1">
 <section id="section-5.1">
         <h3 id="name-introduction-2">
 <a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-introduction-2" class="section-name selfRef">Introduction</a>
         </h3>
 <p id="section-5.1-1">The Brasil Open Banking Security profile specifies additional security and identity requirements for high risk API resources protected by the OAuth 2.0 Authorization Framework that consists of <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>, <a href="https://tools.ietf.org/html/rfc6750">RFC6750</a>, <a href="https://tools.ietf.org/html/rfc7636">RFC7636</a>, <a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">FAPI-1-Baseline</a>, <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">FAPI-1-Advanced</a> and other specifications.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
 <p id="section-5.1-2">This profile describes security and features provisions for a server and client that are necessary for the Brasil Open Banking Programme by defining the measures to mitigate or address:<a href="#section-5.1-2" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-5.1-3.1">
-            <p id="section-5.1-3.1.1">attacks that address privacy considerations identified in clause 9.1 of [FAPI1 Advanced]<a href="#section-5.1-3.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-5.1-3.1">attacks that address privacy considerations identified in clause 9.1 of [FAPI1 Advanced]<a href="#section-5.1-3.1" class="pilcrow">¶</a>
 </li>
-<li id="section-5.1-3.2">
-            <p id="section-5.1-3.2.1">the requirement to support fine-grained access to resources for data minimisation purposes<a href="#section-5.1-3.2.1" class="pilcrow">¶</a></p>
+          <li class="compact" id="section-5.1-3.2">the requirement to support fine-grained access to resources for data minimisation purposes<a href="#section-5.1-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-5.1-3.3">
-            <p id="section-5.1-3.3.1">the requirement to convey the Authentication Context Request that was performed by an OpenID Provider to a Client to enable a appropriate client management of customer conduct risk.<a href="#section-5.1-3.3.1" class="pilcrow">¶</a></p>
+          <li class="compact" id="section-5.1-3.3">the requirement to convey the Authentication Context Request that was performed by an OpenID Provider to a Client to enable a appropriate client management of customer conduct risk.<a href="#section-5.1-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-5.1-3.4">
-            <p id="section-5.1-3.4.1">the requirement for clients to assert a pre-existing customer relationship by asserting a customer identity claim as part of the authorization flow.<a href="#section-5.1-3.4.1" class="pilcrow">¶</a></p>
+          <li class="compact" id="section-5.1-3.4">the requirement for clients to assert a pre-existing customer relationship by asserting a customer identity claim as part of the authorization flow.<a href="#section-5.1-3.4" class="pilcrow">¶</a>
 </li>
-</ul>
+        </ul>
 </section>
 </div>
 <div id="open-banking-brasil-security-provisions">
@@ -1355,7 +1471,7 @@ <h3 id="name-introduction-2">
         <h3 id="name-open-banking-brasil-securit">
 <a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-open-banking-brasil-securit" class="section-name selfRef">Open Banking Brasil security provisions</a>
         </h3>
-<div id="introduction-1">
+<div id="introduction-2">
 <section id="section-5.2.1">
           <h4 id="name-introduction-3">
 <a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-introduction-3" class="section-name selfRef">Introduction</a>
@@ -1374,56 +1490,42 @@ <h4 id="name-authorization-server">
           </h4>
 <p id="section-5.2.2-1">The Authorization Server shall support the provisions specified in clause 5.2.2 of <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">Financial-grade API Security Profile 1.0 - Part 2: Advanced</a><a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
 <p id="section-5.2.2-2">In addition, the Authorization Server<a href="#section-5.2.2-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-5.2.2-3">
-            <li id="section-5.2.2-3.1">
-              <p id="section-5.2.2-3.1.1">shall support a signed and encrypted JWE request object passed by value or shall require pushed authorization requests <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a>;<a href="#section-5.2.2-3.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-5.2.2-3">
+<li id="section-5.2.2-3.1">shall support a signed and encrypted JWE request object passed by value or shall require pushed authorization requests <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a>;<a href="#section-5.2.2-3.1" class="pilcrow">¶</a>
+</li>
+            <li id="section-5.2.2-3.2">shall distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> and [RFC8414];<a href="#section-5.2.2-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.2">
-              <p id="section-5.2.2-3.2.1">shall distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> and [RFC8414]<a href="#section-5.2.2-3.2.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.3">shall support the claims parameter as defined in clause 5.5 <a href="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core</a>;<a href="#section-5.2.2-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.3">
-              <p id="section-5.2.2-3.3.1">shall support the claims parameter as defined in clause 5.5 <a href="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core</a><a href="#section-5.2.2-3.3.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.4">shall support the oidc standard claim "cpf" as defined in clause 5.2.2.2 of this document;<a href="#section-5.2.2-3.4" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.4">
-              <p id="section-5.2.2-3.4.1">shall support the oidc standard claim "cpf" as defined in clause 5.2.2.2 of this document<a href="#section-5.2.2-3.4.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.5">shall support the oidc standard claim "cnpj" as defined in clause 5.2.2.3 of this document if providing access to resources where the resource owner is not a <code>natural person</code>;<a href="#section-5.2.2-3.5" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.5">
-              <p id="section-5.2.2-3.5.1">shall support the oidc standard claim "cnpj" as defined in clause 5.2.2.3 of this document if providing access to resources where the resource owner is not a <code>natural person</code><a href="#section-5.2.2-3.5.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.6">shall support the acr "urn:brasil:openbanking:loa2" as defined in clause 5.2.2.4 of this document;<a href="#section-5.2.2-3.6" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.6">
-              <p id="section-5.2.2-3.6.1">shall support the acr "urn:brasil:openbanking:loa2" as defined in clause 5.2.2.4 of this document<a href="#section-5.2.2-3.6.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.7">should support the acr "urn:brasil:openbanking:loa3" as defined in clause 5.2.2.4 of this document;<a href="#section-5.2.2-3.7" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.7">
-              <p id="section-5.2.2-3.7.1">should support the acr "urn:brasil:openbanking:loa3" as defined in clause 5.2.2.4 of this document<a href="#section-5.2.2-3.7.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.8">shall implement the userinfo endpoint as defined in clause 5.3 <a href="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core</a>;<a href="#section-5.2.2-3.8" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.8">
-              <p id="section-5.2.2-3.8.1">shall implement the userinfo endpoint as defined in clause 5.3 <a href="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core</a><a href="#section-5.2.2-3.8.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.9">shall support parameterized OAuth 2.0 resource scope <em>consent</em> as defined in clause 6.3.1 <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md">OIDF FAPI WG Lodging Intent Pattern</a>;<a href="#section-5.2.2-3.9" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.9">
-              <p id="section-5.2.2-3.9.1">shall support parameterized OAuth 2.0 resource scope <em>consent</em> as defined in clause 6.3.1 <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md">OIDF FAPI WG Lodging Intent Pattern</a><a href="#section-5.2.2-3.9.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.10">may support <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md">Financial-grade API: Client Initiated Backchannel Authentication Profile</a>;<a href="#section-5.2.2-3.10" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.10">
-              <p id="section-5.2.2-3.10.1">may support <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md">Financial-grade API: Client Initiated Backchannel Authentication Profile</a><a href="#section-5.2.2-3.10.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.11">(withdrawn);<a href="#section-5.2.2-3.11" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.11">
-              <p id="section-5.2.2-3.11.1">(withdrawn)<a href="#section-5.2.2-3.11.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.12">shall support refresh tokens;<a href="#section-5.2.2-3.12" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.12">
-              <p id="section-5.2.2-3.12.1">shall support refresh tokens<a href="#section-5.2.2-3.12.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.13">shall issue access tokens with an expiry no greater than 900 seconds and no less than 300 seconds;<a href="#section-5.2.2-3.13" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.13">
-              <p id="section-5.2.2-3.13.1">shall issue access tokens with an expiry no greater than 900 seconds and no less than 300 seconds<a href="#section-5.2.2-3.13.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.14">shall always include an acr claim in the <code>id_token</code>;<a href="#section-5.2.2-3.14" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.14">
-              <p id="section-5.2.2-3.14.1">shall always include an acr claim in the <code>id_token</code><a href="#section-5.2.2-3.14.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.15">shall support the <code>response_type</code> value <code>code id_token</code>;<a href="#section-5.2.2-3.15" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.15">
-              <p id="section-5.2.2-3.15.1">shall support the <code>response_type</code> value <code>code id_token</code><a href="#section-5.2.2-3.15.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.16">may support <code>response_type</code> value <code>code</code> in conjunction with the <code>response_mode</code> value <code>jwt</code>;<a href="#section-5.2.2-3.16" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.16">
-              <p id="section-5.2.2-3.16.1">may support <code>response_type</code> value <code>code</code> in conjunction with the <code>response_mode</code> value <code>jwt</code><a href="#section-5.2.2-3.16.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.17">shall not allow <code>refresh tokens</code> rotation feature.<a href="#section-5.2.2-3.17" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 <div id="id-token-as-detached-signature">
 <section id="section-5.2.2.1">
             <h5 id="name-id-token-as-detached-signat">
@@ -1431,12 +1533,11 @@ <h5 id="name-id-token-as-detached-signat">
             </h5>
 <p id="section-5.2.2.1-1">The Authorization Server shall support the provisions specified in clause 5.2.2.1 of <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">Financial-grade API Security Profile 1.0 - Part 2: Advanced</a><a href="#section-5.2.2.1-1" class="pilcrow">¶</a></p>
 <p id="section-5.2.2.1-2">In addition, if the <code>response_type</code> value <code>code id_token</code> is used, the Authorization Server<a href="#section-5.2.2.1-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-5.2.2.1-3">
-              <li id="section-5.2.2.1-3.1">
-                <p id="section-5.2.2.1-3.1.1">should not return sensitive PII in the ID Token in the authorization response, but if it needs to,
-then it shall encrypt the ID Token.<a href="#section-5.2.2.1-3.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-5.2.2.1-3">
+<li id="section-5.2.2.1-3.1">should not return sensitive PII in the ID Token in the authorization response, but if it needs to,
+then it shall encrypt the ID Token.<a href="#section-5.2.2.1-3.1" class="pilcrow">¶</a>
 </li>
-</ol>
+            </ol>
 </section>
 </div>
 <div id="requesting-the-cpf-claim">
@@ -1488,45 +1589,41 @@ <h5 id="name-requesting-the-urnbrasilope">
             </h5>
 <p id="section-5.2.2.4-1">This profile defines "urn:brasil:openbanking:loa2" and "urn:brasil:openbanking:loa3" as
  new Authentication Context Request classes.<a href="#section-5.2.2.4-1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-5.2.2.4-2.1">
-                <p id="section-5.2.2.4-2.1.1"><strong>LoA2:</strong> Authentication performed using single factor;<a href="#section-5.2.2.4-2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-5.2.2.4-2.1">
+                <strong>LoA2:</strong> Authentication performed using single factor;<a href="#section-5.2.2.4-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2.4-2.2">
-                <p id="section-5.2.2.4-2.2.1"><strong>LoA3:</strong> Authentication performed using multi factor (MFA)<a href="#section-5.2.2.4-2.2.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-5.2.2.4-2.2">
+                <strong>LoA3:</strong> Authentication performed using multi factor (MFA)<a href="#section-5.2.2.4-2.2" class="pilcrow">¶</a>
 </li>
-</ul>
+            </ul>
 <p id="section-5.2.2.4-3">The following rules are applicable to <strong>access control to Open Banking Brazil API's:</strong><a href="#section-5.2.2.4-3" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-5.2.2.4-4.1">
-                <p id="section-5.2.2.4-4.1.1">In accordance to Art. 17 of <a href="https://www.in.gov.br/en/web/dou/-/resolucao-conjunta-n-1-de-4-de-maio-de-2020-255165055">Joint Resolution n&#186; 01 - Open Banking Brasil</a>, institutions must adopt procedures and controls for client authentication <strong>compatible with those applicable in their electronic service channels</strong>.<a href="#section-5.2.2.4-4.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-5.2.2.4-4.1">In accordance to Art. 17 of <a href="https://www.in.gov.br/en/web/dou/-/resolucao-conjunta-n-1-de-4-de-maio-de-2020-255165055">Joint Resolution n&#186; 01 - Open Banking Brasil</a>, institutions must adopt procedures and controls for client authentication <strong>compatible with those applicable in their electronic service channels</strong>.<a href="#section-5.2.2.4-4.1" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2.4-4.2">
+              <li class="compact" id="section-5.2.2.4-4.2">
                 <p id="section-5.2.2.4-4.2.1">So, in compliance with the regulation, it is suggested that:<a href="#section-5.2.2.4-4.2.1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-5.2.2.4-4.2.2.1">
-                    <p id="section-5.2.2.4-4.2.2.1.1"><strong>For Read-Only APIs  (Phase 2)</strong>: the <em>Authorization Servers</em> <strong>should</strong> adopt, at least, an authentication method compatible with <code>LoA2</code>; and<a href="#section-5.2.2.4-4.2.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-5.2.2.4-4.2.2.1">
+                    <strong>For Read-Only APIs  (Phase 2)</strong>: the <em>Authorization Servers</em> <strong>should</strong> adopt, at least, an authentication method compatible with <code>LoA2</code>; and<a href="#section-5.2.2.4-4.2.2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2.4-4.2.2.2">
-                    <p id="section-5.2.2.4-4.2.2.2.1"><strong>For Read-Write API's (subsequent phases)</strong>: the <em>Authorization Servers</em> <strong>should</strong> adopt an authentication method compatible with <code>LoA3</code> or higher.<a href="#section-5.2.2.4-4.2.2.2.1" class="pilcrow">¶</a></p>
+                  <li class="compact" id="section-5.2.2.4-4.2.2.2">
+                    <strong>For Read-Write API's (subsequent phases)</strong>: the <em>Authorization Servers</em> <strong>should</strong> adopt an authentication method compatible with <code>LoA3</code> or higher.<a href="#section-5.2.2.4-4.2.2.2" class="pilcrow">¶</a>
 </li>
-</ul>
+                </ul>
 </li>
-</ul>
+            </ul>
 <p id="section-5.2.2.4-5">In all cases, the adoption of a more rigorous authentication mechanism (<code>LoA3</code> or higher) is at the discretion of the Bank (ASPSP), according to its risk assessment and in a manner compatible with the mechanisms usually used.<a href="#section-5.2.2.4-5" class="pilcrow">¶</a></p>
 <p id="section-5.2.2.4-6"><strong>Authentication factors clarification</strong><a href="#section-5.2.2.4-6" class="pilcrow">¶</a></p>
 <p id="section-5.2.2.4-7">The authentication methods are:<a href="#section-5.2.2.4-7" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-5.2.2.4-8.1">
-                <p id="section-5.2.2.4-8.1.1">Something you know, such as password or phrase<a href="#section-5.2.2.4-8.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-5.2.2.4-8.1">Something you know, such as password or phrase<a href="#section-5.2.2.4-8.1" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2.4-8.2">
-                <p id="section-5.2.2.4-8.2.1">Something you have, such as token or smartcard;<a href="#section-5.2.2.4-8.2.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-5.2.2.4-8.2">Something you have, such as token or smartcard;<a href="#section-5.2.2.4-8.2" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2.4-8.3">
-                <p id="section-5.2.2.4-8.3.1">Something you are, such as biometric validation.<a href="#section-5.2.2.4-8.3.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-5.2.2.4-8.3">Something you are, such as biometric validation.<a href="#section-5.2.2.4-8.3" class="pilcrow">¶</a>
 </li>
-</ul>
+            </ul>
 <p id="section-5.2.2.4-9">To performe a MFA authentication is necessary the end user to present at least two different methods as listed above. A unique method used more than once is not accepted as MFA.<a href="#section-5.2.2.4-9" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -1540,32 +1637,26 @@ <h4 id="name-confidential-client">
 <p id="section-5.2.3-1">A confidential client shall support the provisions specified in clause 5.2.3 of
 <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">Financial-grade API Security Profile 1.0 - Part 2: Advanced</a>,<a href="#section-5.2.3-1" class="pilcrow">¶</a></p>
 <p id="section-5.2.3-2">In addition, the confidential client<a href="#section-5.2.3-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-5.2.3-3">
-            <li id="section-5.2.3-3.1">
-              <p id="section-5.2.3-3.1.1">shall support <em>encrypted</em> request objects<a href="#section-5.2.3-3.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-5.2.3-3">
+<li id="section-5.2.3-3.1">shall support <em>encrypted</em> request objects;<a href="#section-5.2.3-3.1" class="pilcrow">¶</a>
+</li>
+            <li id="section-5.2.3-3.2">shall support Pushed Authorisation Requests <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a>;<a href="#section-5.2.3-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.2">
-              <p id="section-5.2.3-3.2.1">shall support Pushed Authorisation Requests <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a><a href="#section-5.2.3-3.2.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.3">shall use <em>encrypted</em> request objects if not using <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a>;<a href="#section-5.2.3-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.3">
-              <p id="section-5.2.3-3.3.1">shall use <em>encrypted</em> request objects if not using <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a><a href="#section-5.2.3-3.3.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.4">shall support parameterized OAuth 2.0 resource scope <em>consent</em> as defined in clause 6.3.1 <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md">OIDF FAPI WG Lodging Intent Pattern</a>;<a href="#section-5.2.3-3.4" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.4">
-              <p id="section-5.2.3-3.4.1">shall support parameterized OAuth 2.0 resource scope <em>consent</em> as defined in clause 6.3.1 <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md">OIDF FAPI WG Lodging Intent Pattern</a><a href="#section-5.2.3-3.4.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.5">shall support refresh tokens;<a href="#section-5.2.3-3.5" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.5">
-              <p id="section-5.2.3-3.5.1">shall support refresh tokens<a href="#section-5.2.3-3.5.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.6">shall not populate the <code>acr</code> claim with required values;<a href="#section-5.2.3-3.6" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.6">
-              <p id="section-5.2.3-3.6.1">shall not populate the <code>acr</code> claim with required values<a href="#section-5.2.3-3.6.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.7">shall require the <code>acr</code> claim as an essential claim;<a href="#section-5.2.3-3.7" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.7">
-              <p id="section-5.2.3-3.7.1">shall require the <code>acr</code> claim as an essential claim<a href="#section-5.2.3-3.7.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.8">shall support all authentication methods specified in clause 5.2.2-14 of <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">Financial-grade API Security Profile 1.0 - Part 2: Advanced</a> including diferent combinations of the methods to send requests (using <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a> or not - item 11);<a href="#section-5.2.3-3.8" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.8">
-              <p id="section-5.2.3-3.8.1">shall support all authentication methods specified in clause 5.2.2-14 of <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">Financial-grade API Security Profile 1.0 - Part 2: Advanced</a> including diferent combinations of the methods to send requests (using <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a> or not - item 11).<a href="#section-5.2.3-3.8.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.9">shall not allow <code>refresh tokens</code> rotation feature.<a href="#section-5.2.3-3.9" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 </section>
 </div>
 </section>
@@ -1587,77 +1678,78 @@ <h3 id="name-message-content-signing-con">
 <a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-message-content-signing-con" class="section-name selfRef">Message Content Signing Considerations (JWS)</a>
         </h3>
 <ol start="1" type="1" class="normal type-1" id="section-6.1-1">
-          <li id="section-6.1-1.1">
+<li id="section-6.1-1.1">
             <p id="section-6.1-1.1.1">JWS standad defined in <a href="https://tools.ietf.org/html/rfc7515">RFC7515</a> shall be adopted to ensure integrity and non-repudiation of information processed in sensitive <strong>API's (message sign requirement is indicated at API's documentation/swagger)</strong>, which includes:<a href="#section-6.1-1.1.1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-6.1-1.1.2.1">
-                <p id="section-6.1-1.1.2.1.1">Header (<em>JSON Object Signing and Encryption - JOSE Header</em>), which defines the algorithm used and includes information about the public key or certificate that can be used to validate the signature;<a href="#section-6.1-1.1.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-6.1-1.1.2.1">Header (<em>JSON Object Signing and Encryption - JOSE Header</em>), which defines the algorithm used and includes information about the public key or certificate that can be used to validate the signature;<a href="#section-6.1-1.1.2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.1.2.2">
-                <p id="section-6.1-1.1.2.2.1">Payload (<em>JWS Payload</em>): content itself as detailed in the API specification;<a href="#section-6.1-1.1.2.2.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.1.2.2">Payload (<em>JWS Payload</em>): content itself as detailed in the API specification;<a href="#section-6.1-1.1.2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.1.2.3">
-                <p id="section-6.1-1.1.2.3.1">Digital signature (<em>JWS Signature</em>): digital signature, performed according to header parameters.<a href="#section-6.1-1.1.2.3.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.1.2.3">Digital signature (<em>JWS Signature</em>): digital signature, performed according to header parameters.<a href="#section-6.1-1.1.2.3" class="pilcrow">¶</a>
 </li>
-</ul>
+            </ul>
 </li>
-<li id="section-6.1-1.2">
+          <li id="section-6.1-1.2">
             <p id="section-6.1-1.2.1">Each of elements above must be encoded using the Base64url pattern <a href="https://tools.ietf.org/html/rfc4648#section-5">RFC4648</a> and the elements must be concatenated with "." (JWS Compact Serialization method as defined in <a href="https://tools.ietf.org/html/rfc7515">RFC7515</a>).<a href="#section-6.1-1.2.1" class="pilcrow">¶</a></p>
 </li>
-<li id="section-6.1-1.3">
+          <li id="section-6.1-1.3">
             <p id="section-6.1-1.3.1">The payload of signed messages (request <em>JWT</em> and response <em>JWT</em>) shall include the following claims as defined at <a href="JWT">RFC7519</a>:<a href="#section-6.1-1.3.1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-6.1-1.3.2.1">
-                <p id="section-6.1-1.3.2.1.1"><strong>aud</strong> (in the <em>JWT</em> request): the Resource Provider (eg the institution holding the account) must validate if the value of the <strong>aud</strong> field matches the endpoint being triggered;<a href="#section-6.1-1.3.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-6.1-1.3.2.1">
+                <strong>aud</strong> (in the <em>JWT</em> request): the Resource Provider (eg the institution holding the account) must validate if the value of the <strong>aud</strong> field matches the endpoint being triggered;<a href="#section-6.1-1.3.2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.3.2.2">
-                <p id="section-6.1-1.3.2.2.1"><strong>aud</strong> (in <em>JWT</em> response): the API client (eg initiating institution) shall validate if the value of the <strong>aud</strong> field matches its own <code>organisationId</code> listed in the directory;<a href="#section-6.1-1.3.2.2.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.3.2.2">
+                <strong>aud</strong> (in <em>JWT</em> response): the API client (eg initiating institution) shall validate if the value of the <strong>aud</strong> field matches its own <code>organisationId</code> listed in the directory;<a href="#section-6.1-1.3.2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.3.2.3">
-                <p id="section-6.1-1.3.2.3.1"><strong>iss</strong> (in the <em>JWT</em> request and in the <em>JWT</em> response): the receiver of the message shall validate if the value of the <strong>iss</strong> field matches the <code>organisationId</code> of the sender;<a href="#section-6.1-1.3.2.3.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.3.2.3">
+                <strong>iss</strong> (in the <em>JWT</em> request and in the <em>JWT</em> response): the receiver of the message shall validate if the value of the <strong>iss</strong> field matches the <code>organisationId</code> of the sender;<a href="#section-6.1-1.3.2.3" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.3.2.4">
-                <p id="section-6.1-1.3.2.4.1"><strong>jti</strong> (in the <em>JWT</em> request and in the <em>JWT</em> response): the value of the <strong>jti</strong> field shall be filled with the UUID defined by the institution according to [RFC4122] version 4;<a href="#section-6.1-1.3.2.4.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.3.2.4">
+                <strong>jti</strong> (in the <em>JWT</em> request and in the <em>JWT</em> response): the value of the <strong>jti</strong> field shall be filled with the UUID defined by the institution according to [RFC4122] version 4;<a href="#section-6.1-1.3.2.4" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.3.2.5">
-                <p id="section-6.1-1.3.2.5.1"><strong>iat</strong> (in the <em>JWT</em> request and in the <em>JWT</em> response): the <strong>iat</strong> field  shall be filled with the message generation time and according to the standard established in <a href="https://%20datatracker.ietf.org/doc/html/rfc7519#section-2">RFC7519</a> to the <em>NumericDate</em> format.<a href="#section-6.1-1.3.2.5.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.3.2.5">
+                <strong>iat</strong> (in the <em>JWT</em> request and in the <em>JWT</em> response): the <strong>iat</strong> field  shall be filled with the message generation time and according to the standard established in <a href="https://%20datatracker.ietf.org/doc/html/rfc7519#section-2">RFC7519</a> to the <em>NumericDate</em> format.<a href="#section-6.1-1.3.2.5" class="pilcrow">¶</a>
 </li>
-</ul>
+            </ul>
 </li>
-<li id="section-6.1-1.4">
+          <li id="section-6.1-1.4">
             <p id="section-6.1-1.4.1">The HTTP content-type of requests and responses with JWS messages shall be defined as: "application/jwt".<a href="#section-6.1-1.4.1" class="pilcrow">¶</a></p>
 </li>
-<li id="section-6.1-1.5">
+          <li id="section-6.1-1.5">
             <p id="section-6.1-1.5.1">The JOSE header must contain the following attributes:<a href="#section-6.1-1.5.1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-6.1-1.5.2.1">
-                <p id="section-6.1-1.5.2.1.1"><strong>alg</strong> - shall be filled with the value <code>PS256</code>";<a href="#section-6.1-1.5.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-6.1-1.5.2.1">
+                <strong>alg</strong> - shall be filled with the value <code>PS256</code>";<a href="#section-6.1-1.5.2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.5.2.2">
-                <p id="section-6.1-1.5.2.2.1"><strong>kid</strong> - shall be filled with the key identifier value used for the signature;<a href="#section-6.1-1.5.2.2.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.5.2.2">
+                <strong>kid</strong> - shall be filled with the key identifier value used for the signature;<a href="#section-6.1-1.5.2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.5.2.3">
-                <p id="section-6.1-1.5.2.3.1"><strong>typ</strong> - shall be filled with the value <code>JWT</code>.<a href="#section-6.1-1.5.2.3.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.5.2.3">
+                <strong>typ</strong> - shall be filled with the value <code>JWT</code>.<a href="#section-6.1-1.5.2.3" class="pilcrow">¶</a>
 </li>
-</ul>
+            </ul>
 </li>
-</ol>
-<ul>
-<li id="section-6.1-2.1">
-            <p id="section-6.1-2.1.1">In case of error in signature validation by <code>Resource Provider</code> the API provider shall return HTTP error message with <code>status code</code> <strong>400</strong> and the <code>ResponseError</code> content shall include, in the <code>code</code> property, the content <code>BAD_SIGNATURE</code>.<a href="#section-6.1-2.1.1" class="pilcrow">¶</a></p>
+        </ol>
+<ul class="compact">
+<li class="compact" id="section-6.1-2.1">In case of error in signature validation by <code>Resource Provider</code> the API provider shall return HTTP error message with <code>status code</code> <strong>400</strong> and the <code>ResponseError</code> content shall include, in the <code>code</code> property, the content <code>BAD_SIGNATURE</code>.<a href="#section-6.1-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-2.2">
-            <p id="section-6.1-2.2.1">Errors in validating the signed messages received by the client application (eg payment initiator) must be logged and the <code>Resource Provider</code> (eg account holding institution) must be notified.<a href="#section-6.1-2.2.1" class="pilcrow">¶</a></p>
+          <li class="compact" id="section-6.1-2.2">Errors in validating the signed messages received by the client application (eg payment initiator) must be logged and the <code>Resource Provider</code> (eg account holding institution) must be notified.<a href="#section-6.1-2.2" class="pilcrow">¶</a>
 </li>
-</ul>
+        </ul>
 <ol start="6" type="1" class="normal type-1" id="section-6.1-3">
-          <li id="section-6.1-3.1">
+<li id="section-6.1-3.1">
             <p id="section-6.1-3.1.1">The receiver shall validate the consistency of the JWS message's digital signature <strong>exclusively based on the information obtained from the directory</strong>, that is, based on the keys published in the institution's JWKS in the directory.<a href="#section-6.1-3.1.1" class="pilcrow">¶</a></p>
 </li>
-<li id="section-6.1-3.2">
-            <p id="section-6.1-3.2.1">Signatures must be performed using the digital signature certificate specified in the <a href="https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil%20-certificate-standards-1_ID1-ptbr.md#certificate-of-signing-certificatesignature">Open Banking Brazil Certificates Standard</a>.<a href="#section-6.1-3.2.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.2">
+            <p id="section-6.1-3.2.1">Signatures must be performed using the digital signature certificate specified in the <a href="https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil%20-certificate-standards-1_ID1-ptbr.md#certificate-of-signing-certificatesignature">Open Banking Brazil Certificates Standard</a>;<a href="#section-6.1-3.2.1" class="pilcrow">¶</a></p>
+</li>
+          <li id="section-6.1-3.3">
+            <p id="section-6.1-3.3.1">the <em>iat</em> claim must be numeric in Unix Time format GMT+0 with a tolerance of +/- 60 seconds;<a href="#section-6.1-3.3.1" class="pilcrow">¶</a></p>
+</li>
+          <li id="section-6.1-3.4">
+            <p id="section-6.1-3.4.1">the <em>jti</em> claim must be unique for a <em>clientId</em> within a time frame of 86,400 seconds (24h), and cannot be reused within this period. In case of reuse, the HTTP error code 403 shall be return.<a href="#section-6.1-3.4.1" class="pilcrow">¶</a></p>
 </li>
-</ol>
+        </ol>
 </section>
 </div>
 <div id="algorithm-considerations">
@@ -1666,22 +1758,20 @@ <h3 id="name-algorithm-considerations">
 <a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-algorithm-considerations" class="section-name selfRef">Algorithm considerations</a>
         </h3>
 <p id="section-6.2-1">For JWS, both clients and Authorization Servers<a href="#section-6.2-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-6.2-2">
-          <li id="section-6.2-2.1">
-            <p id="section-6.2-2.1.1">shall use PS256 algorithm;<a href="#section-6.2-2.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-6.2-2">
+<li id="section-6.2-2.1">shall use PS256 algorithm;<a href="#section-6.2-2.1" class="pilcrow">¶</a>
 </li>
-</ol>
+        </ol>
 <div id="encryption-algorithm-considerations">
 <section id="section-6.2.1">
           <h4 id="name-encryption-algorithm-consid">
 <a href="#section-6.2.1" class="section-number selfRef">6.2.1. </a><a href="#name-encryption-algorithm-consid" class="section-name selfRef">Encryption algorithm considerations</a>
           </h4>
 <p id="section-6.2.1-1">For JWE, both clients and Authorization Servers<a href="#section-6.2.1-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-6.2.1-2">
-            <li id="section-6.2.1-2.1">
-              <p id="section-6.2.1-2.1.1">shall use RSA-OAEP with A256GCM<a href="#section-6.2.1-2.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-6.2.1-2">
+<li id="section-6.2.1-2.1">shall use RSA-OAEP with A256GCM<a href="#section-6.2.1-2.1" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 </section>
 </div>
 <div id="secure-use-of-transport-layer-security-considerations">
@@ -1690,14 +1780,14 @@ <h4 id="name-secure-use-of-transport-lay">
 <a href="#section-6.2.2" class="section-number selfRef">6.2.2. </a><a href="#name-secure-use-of-transport-lay" class="section-name selfRef">Secure Use of Transport Layer Security considerations</a>
           </h4>
 <p id="section-6.2.2-1">For TLS, Authorization Server endpoints and Resource Server endpoints used directly by the Client<a href="#section-6.2.2-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-6.2.2-2">
-            <li id="section-6.2.2-2.1">
-              <p id="section-6.2.2-2.1.1">shall support <code>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</code><a href="#section-6.2.2-2.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-6.2.2-2">
+<li id="section-6.2.2-2.1">shall support <code>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</code><a href="#section-6.2.2-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.2.2-2.2">
-              <p id="section-6.2.2-2.2.1">shall support <code>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</code><a href="#section-6.2.2-2.2.1" class="pilcrow">¶</a></p>
+            <li id="section-6.2.2-2.2">shall support <code>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</code><a href="#section-6.2.2-2.2" class="pilcrow">¶</a>
 </li>
-</ol>
+            <li id="section-6.2.2-2.3">The "TLS Session Resumption" e "TLS Renegotiation" features shall be disabled<a href="#section-6.2.2-2.3" class="pilcrow">¶</a>
+</li>
+          </ol>
 </section>
 </div>
 </section>
@@ -1714,7 +1804,7 @@ <h2 id="name-data-sharing-considerations">
         <h3 id="name-authorisation-mechanism">
 <a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-authorisation-mechanism" class="section-name selfRef">Authorisation Mechanism</a>
         </h3>
-<div id="introduction-2">
+<div id="introduction-3">
 <section id="section-7.1.1">
           <h4 id="name-introduction-4">
 <a href="#section-7.1.1" class="section-number selfRef">7.1.1. </a><a href="#name-introduction-4" class="section-name selfRef">Introduction</a>
@@ -1728,29 +1818,23 @@ <h4 id="name-dynamic-consent-scope-defin">
 <a href="#section-7.1.2" class="section-number selfRef">7.1.2. </a><a href="#name-dynamic-consent-scope-defin" class="section-name selfRef">Dynamic Consent Scope Definition</a>
           </h4>
 <p id="section-7.1.2-1">This profile defines OAuth 2.0 dynamic scope "consent" as follows:<a href="#section-7.1.2-1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-7.1.2-2.1">
-              <p id="section-7.1.2-2.1.1">string 'consent'; and<a href="#section-7.1.2-2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-7.1.2-2.1">string 'consent'; and<a href="#section-7.1.2-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.2-2.2">
-              <p id="section-7.1.2-2.2.1">delimiter of a colon ":"; and<a href="#section-7.1.2-2.2.1" class="pilcrow">¶</a></p>
+            <li class="compact" id="section-7.1.2-2.2">delimiter of a colon ":"; and<a href="#section-7.1.2-2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.2-2.3">
-              <p id="section-7.1.2-2.3.1">Consent API REST Resource Id as returned by a successful creation of <a href="https://openbanking-brasil.github.io/areadesenvolvedor/#fase-2-apis-do-open-banking-brasil-api-consentimento">Open Banking Consent Resource</a>;<a href="#section-7.1.2-2.3.1" class="pilcrow">¶</a></p>
+            <li class="compact" id="section-7.1.2-2.3">Consent API REST Resource Id as returned by a successful creation of <a href="https://openbanking-brasil.github.io/areadesenvolvedor/#fase-2-apis-do-open-banking-brasil-api-consentimento">Open Banking Consent Resource</a>;<a href="#section-7.1.2-2.3" class="pilcrow">¶</a>
 </li>
-</ul>
+          </ul>
 <p id="section-7.1.2-3">In addition:<a href="#section-7.1.2-3" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-7.1.2-4.1">
-              <p id="section-7.1.2-4.1.1">the Consent Resource Id must include url safe characters only;<a href="#section-7.1.2-4.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-7.1.2-4.1">the Consent Resource Id must include url safe characters only;<a href="#section-7.1.2-4.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.2-4.2">
-              <p id="section-7.1.2-4.2.1">the Consent Resource Id must be namespaced;<a href="#section-7.1.2-4.2.1" class="pilcrow">¶</a></p>
+            <li class="compact" id="section-7.1.2-4.2">the Consent Resource Id must be namespaced;<a href="#section-7.1.2-4.2" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.2-4.3">
-              <p id="section-7.1.2-4.3.1">the Consent Resource Id must have the properties of a nonce;<a href="#section-7.1.2-4.3.1" class="pilcrow">¶</a></p>
+            <li class="compact" id="section-7.1.2-4.3">the Consent Resource Id must have the properties of a nonce;<a href="#section-7.1.2-4.3" class="pilcrow">¶</a>
 </li>
-</ul>
+          </ul>
 </section>
 </div>
 <div id="dynamic-consent-scope-example">
@@ -1768,7 +1852,7 @@ <h4 id="name-dynamic-consent-scope-examp">
         <h3 id="name-authorisation-life-cycle">
 <a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-authorisation-life-cycle" class="section-name selfRef">Authorisation Life Cycle</a>
         </h3>
-<div id="introduction-3">
+<div id="introduction-4">
 <section id="section-7.2.1">
           <h4 id="name-introduction-5">
 <a href="#section-7.2.1" class="section-number selfRef">7.2.1. </a><a href="#name-introduction-5" class="section-name selfRef">Introduction</a>
@@ -1782,41 +1866,30 @@ <h4 id="name-authorization-server-2">
 <a href="#section-7.2.2" class="section-number selfRef">7.2.2. </a><a href="#name-authorization-server-2" class="section-name selfRef">Authorization server</a>
           </h4>
 <p id="section-7.2.2-1">In addition to the requirements outlined in Open Banking Brasil security provisions the Authorization Server<a href="#section-7.2.2-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-7.2.2-2">
-            <li id="section-7.2.2-2.1">
-              <p id="section-7.2.2-2.1.1">shall only issue tokens on presentation of a refresh token when the consent resource the refresh token is bound to is active and valid;<a href="#section-7.2.2-2.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-7.2.2-2">
+<li id="section-7.2.2-2.1">shall only issue tokens on presentation of a refresh token when the consent resource the refresh token is bound to is active and valid;<a href="#section-7.2.2-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.2">
-              <p id="section-7.2.2-2.2.1">shall only share access to resources when presented with an access token linked to an active and valid consent;<a href="#section-7.2.2-2.2.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.2">shall only share access to resources when presented with an access token linked to an active and valid consent;<a href="#section-7.2.2-2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.3">
-              <p id="section-7.2.2-2.3.1">shall revoke refresh tokens and where practicable access tokens when the linked Consent Resource is deleted;<a href="#section-7.2.2-2.3.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.3">shall revoke refresh tokens and where practicable access tokens when the linked Consent Resource is deleted;<a href="#section-7.2.2-2.3" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.4">
-              <p id="section-7.2.2-2.4.1">shall ensure Access Tokens are issued with sufficient scope necessary for access to data specified in the Permissions element of a linked Consent Resource object;<a href="#section-7.2.2-2.4.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.4">shall ensure Access Tokens are issued with sufficient scope necessary for access to data specified in the Permissions element of a linked Consent Resource object;<a href="#section-7.2.2-2.4" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.5">
-              <p id="section-7.2.2-2.5.1">shall not reject an authorisation request requesting more scope than is necessary to access data specified in the Permissions element of a linked Consent Resource object;<a href="#section-7.2.2-2.5.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.5">shall not reject an authorisation request requesting more scope than is necessary to access data specified in the Permissions element of a linked Consent Resource object;<a href="#section-7.2.2-2.5" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.6">
-              <p id="section-7.2.2-2.6.1">may reduce requested scope to a level sufficient to enable access to data resources specified in the Permissions element of a linked Consent Resource object;<a href="#section-7.2.2-2.6.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.6">may reduce requested scope to a level sufficient to enable access to data resources specified in the Permissions element of a linked Consent Resource object;<a href="#section-7.2.2-2.6" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.7">
-              <p id="section-7.2.2-2.7.1">shall retain a complete audit history of the consent resource in accordance with current Central Bank brazilian regulation;<a href="#section-7.2.2-2.7.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.7">shall retain a complete audit history of the consent resource in accordance with current Central Bank brazilian regulation;<a href="#section-7.2.2-2.7" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.8">
-              <p id="section-7.2.2-2.8.1">shall return authentication failure and return code <em>access</em>denied_ in the <em>error</em> parameter (as specified in section 4.1.2.1 of <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>) if the CPF of the authenticated user is not the same as indicated in the <em>loggedUser</em> element of the Consent Resource Object;<a href="#section-7.2.2-2.8.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.8">shall return authentication failure and return code _access<em>denied</em> in the <em>error</em> parameter (as specified in section 4.1.2.1 of <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>) if the CPF of the authenticated user is not the same as indicated in the <em>loggedUser</em> element of the Consent Resource Object;<a href="#section-7.2.2-2.8" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.9">
-              <p id="section-7.2.2-2.9.1">shall return authentication failure and return code <em>access</em>denied_ in the <em>error</em> parameter (as specified in section 4.1.2.1 of <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>) if the <em>businessEntity</em> element has not been populated in the related Consent Resource Object and the user has selected or authenticated by using a credential related to a business account;<a href="#section-7.2.2-2.9.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.9">shall return authentication failure and return code _access<em>denied</em> in the <em>error</em> parameter (as specified in section 4.1.2.1 of <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>) if the <em>businessEntity</em> element has not been populated in the related Consent Resource Object and the user has selected or authenticated by using a credential related to a business account;<a href="#section-7.2.2-2.9" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.10">
-              <p id="section-7.2.2-2.10.1">an autenticated or selected business account's CNPJ must match the value present in the <em>businessEntity</em> element of the Consent Resource Object. In case of divergence authorization server shall return authentication failure and return code <em>access</em>denied_ in the <em>error</em> parameter (as specified in section 4.1.2.1 of <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>);<a href="#section-7.2.2-2.10.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.10">an autenticated or selected business account's CNPJ must match the value present in the <em>businessEntity</em> element of the Consent Resource Object. In case of divergence authorization server shall return authentication failure and return code _access<em>denied</em> in the <em>error</em> parameter (as specified in section 4.1.2.1 of <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>);<a href="#section-7.2.2-2.10" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.11">
-              <p id="section-7.2.2-2.11.1">shall ensure <em>refresh</em>tokens_ expiration time is at least equal to the linked consent resource expiration time.<a href="#section-7.2.2-2.11.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.11">shall ensure _refresh<em>tokens</em> expiration time is at least equal to the linked consent resource expiration time.<a href="#section-7.2.2-2.11" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 </section>
 </div>
 <div id="confidential-client-1">
@@ -1825,14 +1898,12 @@ <h4 id="name-confidential-client-2">
 <a href="#section-7.2.3" class="section-number selfRef">7.2.3. </a><a href="#name-confidential-client-2" class="section-name selfRef">Confidential Client</a>
           </h4>
 <p id="section-7.2.3-1">In addition to the requirements outlined in Open Banking Brasil security provisions the Confidential Client<a href="#section-7.2.3-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-7.2.3-2">
-            <li id="section-7.2.3-2.1">
-              <p id="section-7.2.3-2.1.1">shall revoke where possible and cease usage of refresh and access tokens that are bound to a Consent Resource that has been deleted;<a href="#section-7.2.3-2.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-7.2.3-2">
+<li id="section-7.2.3-2.1">shall revoke where possible and cease usage of refresh and access tokens that are bound to a Consent Resource that has been deleted;<a href="#section-7.2.3-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.3-2.2">
-              <p id="section-7.2.3-2.2.1">shall delete Consent Resource that are expired;<a href="#section-7.2.3-2.2.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.3-2.2">shall delete Consent Resource that are expired;<a href="#section-7.2.3-2.2" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 </section>
 </div>
 </section>
@@ -1846,52 +1917,37 @@ <h2 id="name-acknowledgements">
       </h2>
 <p id="section-8-1">With thanks to all who have set the foundations for secure and safe data sharing through the formation of the OpenID Foundation FAPI Working Group, the Open Banking Brasil GT Security and to the pioneers who will stand on their shoulders.<a href="#section-8-1" class="pilcrow">¶</a></p>
 <p id="section-8-2">The following people contributed to this document:<a href="#section-8-2" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-8-3.1">
-          <p id="section-8-3.1.1">Ralph Bragg (Raidiam)<a href="#section-8-3.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-8-3.1">Alexandre Siqueira (Mercado Pago)<a href="#section-8-3.1" class="pilcrow">¶</a>
 </li>
-<li id="section-8-3.2">
-          <p id="section-8-3.2.1">Joseph Heenan (Authlete)<a href="#section-8-3.2.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-8-3.2">Joseph Heenan (Authlete)<a href="#section-8-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-8-3.3">
-          <p id="section-8-3.3.1">Alexandre Siqueira (Mercado Pago)<a href="#section-8-3.3.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-8-3.3">Marcos Rodrigues (Ita&#250;)<a href="#section-8-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-8-3.4">
-          <p id="section-8-3.4.1">Marcos Rodrigues (Ita&#250;)<a href="#section-8-3.4.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-8-3.4">M&#225;rio Ginglass (BNDES)<a href="#section-8-3.4" class="pilcrow">¶</a>
 </li>
-<li id="section-8-3.5">
-          <p id="section-8-3.5.1">M&#225;rio Ginglass (BNDES)<a href="#section-8-3.5.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-8-3.5">Nic Marcondes (Quanto)<a href="#section-8-3.5" class="pilcrow">¶</a>
 </li>
-</ul>
+        <li class="compact" id="section-8-3.6">Ralph Bragg (Raidiam)<a href="#section-8-3.6" class="pilcrow">¶</a>
+</li>
+      </ul>
 </section>
 </div>
 <div id="notices">
-<section id="section-appendix.a">
+<section id="appendix-A">
       <h2 id="name-notices">
-<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-notices" class="section-name selfRef">Notices</a>
+<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-notices" class="section-name selfRef">Notices</a>
       </h2>
-<p id="section-appendix.a-1">Copyright (c) 2021 Open Banking Brasil Initial Structure.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
-<p id="section-appendix.a-2">The Open Banking Brasil Initial Structure (OBBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OBBIS as the source of the material, but that such attribution does not indicate an endorsement by the OBBIS.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
-<p id="section-appendix.a-3">The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation, the Open Banking Brasil GT Security Working Group and others. Although the Open Banking Brasil Initial Structure has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The Open Banking Brasil Initial Structure and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The Open Banking Brasil Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The Open Banking Brasil Initial Structure invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
+<p id="appendix-A-1">Copyright (c) 2022 Open Banking Brasil Initial Structure.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
+<p id="appendix-A-2">The Open Banking Brasil Initial Structure (OBBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OBBIS as the source of the material, but that such attribution does not indicate an endorsement by the OBBIS.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
+<p id="appendix-A-3">The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation, the Open Banking Brasil GT Security Working Group and others. Although the Open Banking Brasil Initial Structure has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The Open Banking Brasil Initial Structure and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The Open Banking Brasil Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The Open Banking Brasil Initial Structure invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.<a href="#appendix-A-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="authors-addresses">
-<section id="section-appendix.b">
-      <h2 id="name-authors-addresses">
-<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
+<section id="appendix-B">
+      <h2 id="name-authors-address">
+<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
       </h2>
-<address class="vcard">
-        <div dir="auto" class="left"><span class="fn nameRole">Ralph Bragg</span></div>
-<div dir="auto" class="left"><span class="org">Raidiam</span></div>
-<div class="email">
-<span>Email:</span>
-<a href="mailto:ralph.bragg@raidiam.com" class="email">ralph.bragg@raidiam.com</a>
-</div>
-<div class="url">
-<span>URI:</span>
-<a href="https://www.raidiam.com/" class="url">https://www.raidiam.com/</a>
-</div>
-</address>
 <address class="vcard">
         <div dir="auto" class="left"><span class="fn nameRole">OBBIS GT Security</span></div>
 <div dir="auto" class="left"><span class="org">Open Banking Brasil Initial Structure</span></div>
diff --git a/open-banking-brasil-financial-api-1_ID3.md b/open-banking-brasil-financial-api-1_ID3.md
index 31f7c76..76a235d 100644
--- a/open-banking-brasil-financial-api-1_ID3.md
+++ b/open-banking-brasil-financial-api-1_ID3.md
@@ -17,16 +17,6 @@
     status = "standard"
     value = "open-banking-brasil-financial-api-1_ID3"
 
-    [[author]]
-    initials = "R."
-    surname = "Bragg"
-    fullname = "Ralph Bragg"
-    organization = "Raidiam"
-    abbrev = "Raidiam"
-      [author.address]
-      email = "ralph.bragg@raidiam.com"
-      uri = "https://www.raidiam.com/"
-
     [[author]]
     initials = "GT"
     surname = "Security"
@@ -164,25 +154,16 @@ For the purpose of this document, the terms defined in [RFC6749], [RFC6750], [RF
 
 # Symbols and Abbreviated terms
 
-**API** – Application Programming Interface
-
-**OBBIS** – Open Banking Brasil Initial Structure
-
-**CSRF** - Cross Site Request Forgery
-
-**DCR** – Dynamic Client Registration
-
-**FAPI** - Financial-grade API
-
-**HTTP** – Hyper Text Transfer Protocol
-
-**OIDF** - OpenID Foundation
-
-**REST** – Representational State Transfer
-
-**TLS** – Transport Layer Security
-
-**MFA** - Multi-Factor Authentication
+* **API** – Application Programming Interface
+* **CSRF** - Cross Site Request Forgery
+* **DCR** – Dynamic Client Registration
+* **FAPI** - Financial-grade API
+* **HTTP** – Hyper Text Transfer Protocol
+* **MFA** - Multi-Factor Authentication
+* **OBBIS** – Open Banking Brasil Initial Structure
+* **OIDF** - OpenID Foundation
+* **REST** – Representational State Transfer
+* **TLS** – Transport Layer Security
 
 # Brasil Open Banking Security Profile
 
@@ -445,17 +426,18 @@ With thanks to all who have set the foundations for secure and safe data sharing
 
 The following people contributed to this document:
 
-* Ralph Bragg (Raidiam)
-* Joseph Heenan (Authlete)
 * Alexandre Siqueira (Mercado Pago)
+* Joseph Heenan (Authlete)
 * Marcos Rodrigues (Itaú)
 * Mário Ginglass (BNDES)
+* Nic Marcondes (Quanto)
+* Ralph Bragg (Raidiam)
 
 {backmatter}
 
 # Notices
 
-Copyright (c) 2021 Open Banking Brasil Initial Structure.
+Copyright (c) 2022 Open Banking Brasil Initial Structure.
 
 The Open Banking Brasil Initial Structure (OBBIS) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty-free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OBBIS as the source of the material, but that such attribution does not indicate an endorsement by the OBBIS.
 

From a1f10a87bf5d5ad4797a3ff2d2b5dd146ffc5a60 Mon Sep 17 00:00:00 2001
From: Nic <qbitnic@gmail.com>
Date: Thu, 17 Feb 2022 22:05:24 -0300
Subject: [PATCH 55/59] chore(md): Fix and export
 open-banking-brasil-financial-api-1_ID3-ptbr.md

---
 ...nking-brasil-financial-api-1_ID3-ptbr.html | 764 ++++++++++--------
 ...banking-brasil-financial-api-1_ID3-ptbr.md |  46 +-
 2 files changed, 423 insertions(+), 387 deletions(-)

diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.html b/open-banking-brasil-financial-api-1_ID3-ptbr.html
index cd7f1d8..9d893c0 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.html
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.html
@@ -5,12 +5,29 @@
 <meta content="Common,Latin" name="scripts">
 <meta content="initial-scale=1.0" name="viewport">
 <title>Open Banking Brasil Financial-grade API Security Profile 1.0 Implementers Draft 3</title>
-<meta content="Ralph Bragg" name="author">
 <meta content="OBBIS GT Security" name="author">
-<meta content="xml2rfc 2.40.1" name="generator">
+<meta content="xml2rfc 3.12.2" name="generator">
 <meta content="FAPI" name="keyword">
 <meta content="Open Banking Brasil GT Security" name="keyword">
 <meta content="open-banking-brasil-financial-api-1_ID3-ptbr" name="ietf.draft">
+<!-- Generator version information:
+  xml2rfc 3.12.2
+    Python 3.10.2
+    appdirs 1.4.4
+    ConfigArgParse 1.5.3
+    google-i18n-address 2.5.0
+    html5lib 1.1
+    intervaltree 3.1.0
+    Jinja2 2.11.3
+    kitchen 1.2.6
+    lxml 4.8.0
+    pycountry 22.1.10
+    pyflakes 2.4.0
+    PyYAML 6.0
+    requests 2.27.1
+    setuptools 58.1.0
+    six 1.16.0
+-->
 <link href="./open-banking-brasil-financial-api-1_ID3-ptbr.xml" rel="alternate" type="application/rfc+xml">
 <link href="#copyright" rel="license">
 <style type="text/css">/*
@@ -179,6 +196,9 @@
 ul.empty li, .ulEmpty li {
   margin-top: 0.5em;
 }
+ul.ulBare, li.ulBare {
+  margin-left: 0em !important;
+}
 ul.compact, .ulCompact,
 ol.compact, .olCompact {
   line-height: 100%;
@@ -362,6 +382,12 @@
   float: left;
   margin-bottom: 0;
 }
+/* Fix PDF info block run off issue */
+@media print {
+  #identifiers dd {
+    float: none;
+  }
+}
 #identifiers .authors .author {
   display: inline-block;
   margin-right: 1.5em;
@@ -912,12 +938,6 @@
   }
 
 }
-/* Avoid wrapping of URLs in references */
-@media screen {
-  .references a {
-    white-space: nowrap;
-  }
-}
 /* Tweak the bcp14 keyword presentation */
 .bcp14 {
   font-variant: small-caps;
@@ -988,7 +1008,7 @@
 }
 /* Make .olPercent look the same as <ol><li> */
 dl.olPercent > dd {
-  margin: 0 0 0.25em 0;
+  margin-bottom: 0.25em;
   min-height: initial;
 }
 /* Give aside some styling to set it apart */
@@ -1026,14 +1046,6 @@
     margin-bottom: 1em;
   }
 }
-/*
-  The margin-left: 0 on <dd> removes all distinction
-  between levels from nested <dl>s.  Undo that.
-*/
-dl.olPercent > dd,
-dd {
-  margin-left: revert;
-}
 /* Avoid narrow tables forcing too narrow table captions, which may render badly */
 table {
   min-width: 20em;
@@ -1059,6 +1071,108 @@
   #toc nav { display: none; }
   #toc.active nav { display: block; }
 }
+/* Add support for keepWithNext */
+.keepWithNext {
+  break-after: avoid-page;
+  break-after: avoid-page;
+}
+/* Add support for keepWithPrevious */
+.keepWithPrevious {
+  break-before: avoid-page;
+}
+/* Change the approach to avoiding breaks inside artwork etc. */
+figure, pre, table, .artwork, .sourcecode  {
+  break-before: auto;
+  break-after: auto;
+}
+/* Avoid breaks between <dt> and <dd> */
+dl {
+  break-before: auto;
+  break-inside: auto;
+}
+dt {
+  break-before: auto;
+  break-after: avoid-page;
+}
+dd {
+  break-before: avoid-page;
+  break-after: auto;
+  orphans: 3;
+  widows: 3
+}
+span.break, dd.break {
+  margin-bottom: 0;
+  min-height: 0;
+  break-before: auto;
+  break-inside: auto;
+  break-after: auto;
+}
+/* Undo break-before ToC */
+@media print {
+  #toc {
+    break-before: auto;
+  }
+}
+/* Text in compact lists should not get extra bottim margin space,
+   since that would makes the list not compact */
+ul.compact p, .ulCompact p,
+ol.compact p, .olCompact p {
+ margin: 0;
+}
+/* But the list as a whole needs the extra space at the end */
+section ul.compact,
+section .ulCompact,
+section ol.compact,
+section .olCompact {
+  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
+}
+/* The tt and code background above interferes with for instance table cell
+   backgrounds.  Changed to something a bit more selective. */
+tt, code {
+  background-color: transparent;
+}
+p tt, p code, li tt, li code {
+  background-color: #f8f8f8;
+}
+/* Tweak the pre margin -- 0px doesn't come out well */
+pre {
+   margin-top: 0.5px;
+}
+/* Tweak the comact list text */
+ul.compact, .ulCompact,
+ol.compact, .olCompact,
+dl.compact, .dlCompact {
+  line-height: normal;
+}
+/* Don't add top margin for nested lists */
+li > ul, li > ol, li > dl,
+dd > ul, dd > ol, dd > dl,
+dl > dd > dl {
+  margin-top: initial;
+}
+/* Elements that should not be rendered on the same line as a <dt> */
+/* This should match the element list in writer.text.TextWriter.render_dl() */
+dd > div.artwork:first-child,
+dd > aside:first-child,
+dd > figure:first-child,
+dd > ol:first-child,
+dd > div:first-child > pre.sourcecode,
+dd > table:first-child,
+dd > ul:first-child {
+  clear: left;
+}
+/* fix for weird browser behaviour when <dd/> is empty */
+dt+dd:empty::before{
+  content: "\00a0";
+}
+/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
+li > p {
+  margin-bottom: 0.5em
+}
+/* Don't let p margin spill out from inside list items */
+li > p:last-of-type {
+  margin-bottom: 0;
+}
 </style>
 <link href="rfc-local.css" rel="stylesheet" type="text/css">
 </head>
@@ -1068,10 +1182,10 @@
 <thead><tr>
 <td class="left"></td>
 <td class="center">OBB-FAPI-1-ID3</td>
-<td class="right">September 2021</td>
+<td class="right">February 2022</td>
 </tr></thead>
 <tfoot><tr>
-<td class="left">Bragg & Security</td>
+<td class="left">Security</td>
 <td class="center">Standards Track</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
@@ -1081,20 +1195,8 @@
 <dl id="identifiers">
 <dt class="label-workgroup">Workgroup:</dt>
 <dd class="workgroup">Open Banking Brasil GT Security</dd>
-<dt class="label-internet-draft">Internet-Draft:</dt>
-<dd class="internet-draft">open-banking-brasil-financial-api-1_ID3-ptbr</dd>
-<dt class="label-published">Published:</dt>
-<dd class="published">
-<time datetime="2021-09-27" class="published">27 September 2021</time>
-    </dd>
-<dt class="label-intended-status">Intended Status:</dt>
-<dd class="intended-status">Standards Track</dd>
-<dt class="label-authors">Authors:</dt>
+<dt class="label-authors">Author:</dt>
 <dd class="authors">
-<div class="author">
-      <div class="author-name">R. Bragg</div>
-<div class="org">Raidiam</div>
-</div>
 <div class="author">
       <div class="author-name">GT. Security</div>
 <div class="org">OBBIS</div>
@@ -1110,14 +1212,13 @@ <h2 id="name-pref225cio">
 <p id="section-note.1-1">The normative version in <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html">English</a><a href="#section-note.1-1" class="pilcrow">¶</a></p>
 <p id="section-note.1-2">A Estrutura Inicial do Open Banking Brasil (EIOBB) &#233; respons&#225;vel por criar padr&#245;es e especifica&#231;&#245;es necess&#225;rias para atender aos requisitos e obriga&#231;&#245;es da Legisla&#231;&#227;o do Open Banking do Brasil, conforme originalmente delineado pelo <a href="https://www.bcb.gov.br/content/config/Documents/BCB_Open_Banking_Communique-April-2019.pdf">Banco Central do Brasil</a>. &#201; poss&#237;vel que alguns dos elementos deste documento estejam sujeitos a direitos autorais ou patenteados. O EIOBB n&#227;o se responsabiliza pela identifica&#231;&#227;o de qualquer ou todos esses direitos.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
 <p id="section-note.1-3">O Financial-grade API 1.0 do Open Banking Brasil consiste nas seguintes partes:<a href="#section-note.1-3" class="pilcrow">¶</a></p>
-<ul class="note">
-<li class="note" id="section-note.1-4.1">
-          <p id="section-note.1-4.1.1">Open Banking Brasil Financial-grade API Security Profile 1.0<a href="#section-note.1-4.1.1" class="pilcrow">¶</a></p>
+<ul class="compact note">
+<li class="compact note" id="section-note.1-4.1">Open Banking Brasil Financial-grade API Security Profile 1.0<a href="#section-note.1-4.1" class="pilcrow">¶</a>
 </li>
-<li class="note" id="section-note.1-4.2">
-          <p id="section-note.1-4.2.1"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1.html">Open Banking Brasil Dynamic Client Registration Profile 1.0</a><a href="#section-note.1-4.2.1" class="pilcrow">¶</a></p>
+        <li class="compact note" id="section-note.1-4.2">
+          <a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html">Open Banking Brasil Dynamic Client Registration Profile 1.0</a><a href="#section-note.1-4.2" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 <p id="section-note.1-5">Estas partes s&#227;o destinados a serem usados com <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>, <a href="https://tools.ietf.org/html/rfc6750">RFC6750</a>, <a href="https://tools.ietf.org/html/rfc7636">RFC7636</a>, <a href="https://openid.net/specs/openid-connect-core-1_0.html">OIDC</a>, <a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">FAPI-1-Baseline</a> e <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">FAPI-1-Advanced</a><a href="#section-note.1-5" class="pilcrow">¶</a></p>
 </section>
 <section class="note" id="section-note.2">
@@ -1132,20 +1233,16 @@ <h2 id="name-conven231245es-notacionais">
 <a href="#name-conven231245es-notacionais" class="section-name selfRef">Conven&#231;&#245;es Notacionais</a>
       </h2>
 <p id="section-note.3-1">As palavras-chave "<em>deve</em>" (shall), "<em>n&#227;o deve</em>" (shall not), "<em>deveria</em>" (should), "<em>n&#227;o deveria</em>" (should not) e "<em>pode</em>" (may) presentes nesse documento devem ser interpretadas conforme as diretrizes descritas em <a href="https://www.iso.org/sites/directives/current/part2/index.xhtml">ISO Directive Part 2</a> observando  seguinte equival&#234;ncia:<a href="#section-note.3-1" class="pilcrow">¶</a></p>
-<ul class="note">
-<li class="note" id="section-note.3-2.1">
-          <p id="section-note.3-2.1.1">"deve" =&gt; equivalente ao termo "shall" e expressa um requerimento definido no documento (nas tradu&#231;&#245;es &#233; similar ao termo "must", que pode denotar um requerimento externo ao documento);<a href="#section-note.3-2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact note">
+<li class="compact note" id="section-note.3-2.1">"deve" =&gt; equivalente ao termo "shall" e expressa um requerimento definido no documento (nas tradu&#231;&#245;es &#233; similar ao termo "must", que pode denotar um requerimento externo ao documento);<a href="#section-note.3-2.1" class="pilcrow">¶</a>
 </li>
-<li class="note" id="section-note.3-2.2">
-          <p id="section-note.3-2.2.1">"n&#227;o deve" =&gt; equivalente ao termo "shall not" e tamb&#233;m expressa um requerimento definido no documento;<a href="#section-note.3-2.2.1" class="pilcrow">¶</a></p>
+        <li class="compact note" id="section-note.3-2.2">"n&#227;o deve" =&gt; equivalente ao termo "shall not" e tamb&#233;m expressa um requerimento definido no documento;<a href="#section-note.3-2.2" class="pilcrow">¶</a>
 </li>
-<li class="note" id="section-note.3-2.3">
-          <p id="section-note.3-2.3.1">"deveria" e "n&#227;o deveria"=&gt; equivalente ao termo "should" e "should not" e expressa uma recomenda&#231;&#227;o<a href="#section-note.3-2.3.1" class="pilcrow">¶</a></p>
+        <li class="compact note" id="section-note.3-2.3">"deveria" e "n&#227;o deveria"=&gt; equivalente ao termo "should" e "should not" e expressa uma recomenda&#231;&#227;o<a href="#section-note.3-2.3" class="pilcrow">¶</a>
 </li>
-<li class="note" id="section-note.3-2.4">
-          <p id="section-note.3-2.4.1">"pode" =&gt; equivalente ao termo "may" indica uma permiss&#227;o<a href="#section-note.3-2.4.1" class="pilcrow">¶</a></p>
+        <li class="compact note" id="section-note.3-2.4">"pode" =&gt; equivalente ao termo "may" indica uma permiss&#227;o<a href="#section-note.3-2.4" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 <p id="section-note.3-3">Estas palavras-chave n&#227;o s&#227;o usadas como termos de dicion&#225;rio, de modo que qualquer ocorr&#234;ncia deles deve ser interpretada como palavras-chave e n&#227;o devem ser interpretados com seus significados de linguagem natural.<a href="#section-note.3-3" class="pilcrow">¶</a></p>
 </section>
 <div id="toc">
@@ -1153,106 +1250,106 @@ <h2 id="name-conven231245es-notacionais">
         <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
 <a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
         </h2>
-<nav class="toc"><ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.1">
-            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-escopo" class="xref">Escopo</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
+<nav class="toc"><ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
+            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-escopo" class="xref">Escopo</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.2">
-            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-refer234ncias-normativas" class="xref">Refer&#234;ncias normativas</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
+            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-refer234ncias-normativas" class="xref">Refer&#234;ncias normativas</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.3">
-            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-termos-e-defini231245es" class="xref">Termos e defini&#231;&#245;es</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
+            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-termos-e-defini231245es" class="xref">Termos e defini&#231;&#245;es</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.4">
-            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-s237mbolos-e-termos-abrevia" class="xref">S&#237;mbolos e termos abreviados</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
+            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-s237mbolos-e-termos-abrevia" class="xref">S&#237;mbolos e termos abreviados</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.5">
-            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-profile-de-seguran231a-para" class="xref">Profile de Seguran&#231;a para o Open Banking Brasil</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.5.2.1">
-                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-introdu231227o-2" class="xref">Introdu&#231;&#227;o</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
+            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-profile-de-seguran231a-para" class="xref">Profile de Seguran&#231;a para o Open Banking Brasil</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
+                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-introdu231227o-2" class="xref">Introdu&#231;&#227;o</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.5.2.2">
-                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-disposi231245es-de-seguran2" class="xref">Disposi&#231;&#245;es de seguran&#231;a do Open Banking Brasil</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.5.2.2.2.1">
-                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-introdu231227o-3" class="xref">Introdu&#231;&#227;o</a><a href="#section-toc.1-1.5.2.2.2.1.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
+                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-disposi231245es-de-seguran2" class="xref">Disposi&#231;&#245;es de seguran&#231;a do Open Banking Brasil</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.1">
+                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-introdu231227o-3" class="xref">Introdu&#231;&#227;o</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.5.2.2.2.2">
-                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-servidor-de-autoriza231227o" class="xref">Servidor de Autoriza&#231;&#227;o</a><a href="#section-toc.1-1.5.2.2.2.2.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.2">
+                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-servidor-de-autoriza231227o" class="xref">Servidor de Autoriza&#231;&#227;o</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.5.2.2.2.3">
-                    <p id="section-toc.1-1.5.2.2.2.3.1"><a href="#section-5.2.3" class="xref">5.2.3</a>.  <a href="#name-cliente-confidencial" class="xref">Cliente confidencial</a><a href="#section-toc.1-1.5.2.2.2.3.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.3">
+                    <p id="section-toc.1-1.5.2.2.2.3.1"><a href="#section-5.2.3" class="xref">5.2.3</a>.  <a href="#name-cliente-confidencial" class="xref">Cliente confidencial</a></p>
 </li>
-</ul>
+                </ul>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.6">
-            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-considera231245es-de-segura" class="xref">Considera&#231;&#245;es de seguran&#231;a</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.1">
-                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-considera231245es-sobre-ass" class="xref">Considera&#231;&#245;es sobre assinatura do conte&#250;do de mensagens (JWS)</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.1.2.1">
-                    <p id="section-toc.1-1.6.2.1.2.1.1"><a href="#section-6.1.1" class="xref">6.1.1</a>.  <a href="#name-considera231245es-sobre-alg" class="xref">Considera&#231;&#245;es sobre algoritmos de assinatura</a><a href="#section-toc.1-1.6.2.1.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
+            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-considera231245es-de-segura" class="xref">Considera&#231;&#245;es de seguran&#231;a</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
+                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-considera231245es-sobre-ass" class="xref">Considera&#231;&#245;es sobre assinatura do conte&#250;do de mensagens (JWS)</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1.2.1">
+                    <p id="section-toc.1-1.6.2.1.2.1.1"><a href="#section-6.1.1" class="xref">6.1.1</a>.  <a href="#name-considera231245es-sobre-alg" class="xref">Considera&#231;&#245;es sobre algoritmos de assinatura</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.1.2.2">
-                    <p id="section-toc.1-1.6.2.1.2.2.1"><a href="#section-6.1.2" class="xref">6.1.2</a>.  <a href="#name-considera231245es-de-algori" class="xref">Considera&#231;&#245;es de algoritmo de criptografia</a><a href="#section-toc.1-1.6.2.1.2.2.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1.2.2">
+                    <p id="section-toc.1-1.6.2.1.2.2.1"><a href="#section-6.1.2" class="xref">6.1.2</a>.  <a href="#name-considera231245es-de-algori" class="xref">Considera&#231;&#245;es de algoritmo de criptografia</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.6.2.1.2.3">
-                    <p id="section-toc.1-1.6.2.1.2.3.1"><a href="#section-6.1.3" class="xref">6.1.3</a>.  <a href="#name-considera231245es-sobre-o-u" class="xref">Considera&#231;&#245;es sobre o uso seguro do Transport Layer Security</a><a href="#section-toc.1-1.6.2.1.2.3.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1.2.3">
+                    <p id="section-toc.1-1.6.2.1.2.3.1"><a href="#section-6.1.3" class="xref">6.1.3</a>.  <a href="#name-considera231245es-sobre-o-u" class="xref">Considera&#231;&#245;es sobre o uso seguro do Transport Layer Security</a></p>
 </li>
-</ul>
+                </ul>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7">
-            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-considera231245es-sobre-com" class="xref">Considera&#231;&#245;es sobre compartilhamento de dados</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1">
-                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-mecanismo-de-autoriza231227" class="xref">Mecanismo de Autoriza&#231;&#227;o</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1.2.1">
-                    <p id="section-toc.1-1.7.2.1.2.1.1"><a href="#section-7.1.1" class="xref">7.1.1</a>.  <a href="#name-introdu231227o-4" class="xref">Introdu&#231;&#227;o</a><a href="#section-toc.1-1.7.2.1.2.1.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
+            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-considera231245es-sobre-com" class="xref">Considera&#231;&#245;es sobre compartilhamento de dados</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
+                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-mecanismo-de-autoriza231227" class="xref">Mecanismo de Autoriza&#231;&#227;o</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.1">
+                    <p id="section-toc.1-1.7.2.1.2.1.1"><a href="#section-7.1.1" class="xref">7.1.1</a>.  <a href="#name-introdu231227o-4" class="xref">Introdu&#231;&#227;o</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1.2.2">
-                    <p id="section-toc.1-1.7.2.1.2.2.1"><a href="#section-7.1.2" class="xref">7.1.2</a>.  <a href="#name-defini231227o-de-escopo-de-" class="xref">Defini&#231;&#227;o de Escopo de Consentimento Din&#226;mico</a><a href="#section-toc.1-1.7.2.1.2.2.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.2">
+                    <p id="section-toc.1-1.7.2.1.2.2.1"><a href="#section-7.1.2" class="xref">7.1.2</a>.  <a href="#name-defini231227o-de-escopo-de-" class="xref">Defini&#231;&#227;o de Escopo de Consentimento Din&#226;mico</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1.2.3">
-                    <p id="section-toc.1-1.7.2.1.2.3.1"><a href="#section-7.1.3" class="xref">7.1.3</a>.  <a href="#name-dynamic-consent-scope-examp" class="xref">Dynamic Consent Scope Example</a><a href="#section-toc.1-1.7.2.1.2.3.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.3">
+                    <p id="section-toc.1-1.7.2.1.2.3.1"><a href="#section-7.1.3" class="xref">7.1.3</a>.  <a href="#name-dynamic-consent-scope-examp" class="xref">Dynamic Consent Scope Example</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.1.2.4">
-                    <p id="section-toc.1-1.7.2.1.2.4.1"><a href="#section-7.1.4" class="xref">7.1.4</a>.  <a href="#name-exemplo-de-escopo-de-consen" class="xref">Exemplo de escopo de consentimento din&#226;mico</a><a href="#section-toc.1-1.7.2.1.2.4.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.4">
+                    <p id="section-toc.1-1.7.2.1.2.4.1"><a href="#section-7.1.4" class="xref">7.1.4</a>.  <a href="#name-exemplo-de-escopo-de-consen" class="xref">Exemplo de escopo de consentimento din&#226;mico</a></p>
 </li>
-</ul>
+                </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.2">
-                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-ciclo-de-vida-da-autoriza23" class="xref">Ciclo de vida da autoriza&#231;&#227;o</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
-<ul class="toc ulEmpty">
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.1">
-                    <p id="section-toc.1-1.7.2.2.2.1.1"><a href="#section-7.2.1" class="xref">7.2.1</a>.  <a href="#name-introdu231227o-5" class="xref">Introdu&#231;&#227;o</a><a href="#section-toc.1-1.7.2.2.2.1.1" class="pilcrow">¶</a></p>
+              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
+                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-ciclo-de-vida-da-autoriza23" class="xref">Ciclo de vida da autoriza&#231;&#227;o</a></p>
+<ul class="compact toc ulBare ulEmpty">
+<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2.2.1">
+                    <p id="section-toc.1-1.7.2.2.2.1.1"><a href="#section-7.2.1" class="xref">7.2.1</a>.  <a href="#name-introdu231227o-5" class="xref">Introdu&#231;&#227;o</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.2">
-                    <p id="section-toc.1-1.7.2.2.2.2.1"><a href="#section-7.2.2" class="xref">7.2.2</a>.  <a href="#name-servidor-de-autoriza231227o-2" class="xref">Servidor de autoriza&#231;&#227;o</a><a href="#section-toc.1-1.7.2.2.2.2.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2.2.2">
+                    <p id="section-toc.1-1.7.2.2.2.2.1"><a href="#section-7.2.2" class="xref">7.2.2</a>.  <a href="#name-servidor-de-autoriza231227o-2" class="xref">Servidor de autoriza&#231;&#227;o</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.7.2.2.2.3">
-                    <p id="section-toc.1-1.7.2.2.2.3.1"><a href="#section-7.2.3" class="xref">7.2.3</a>.  <a href="#name-cliente-confidencial-2" class="xref">Cliente confidencial</a><a href="#section-toc.1-1.7.2.2.2.3.1" class="pilcrow">¶</a></p>
+                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2.2.3">
+                    <p id="section-toc.1-1.7.2.2.2.3.1"><a href="#section-7.2.3" class="xref">7.2.3</a>.  <a href="#name-cliente-confidencial-2" class="xref">Cliente confidencial</a></p>
 </li>
-</ul>
+                </ul>
 </li>
-</ul>
+            </ul>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.8">
-            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-reconhecimentos" class="xref">Reconhecimentos</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
+            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-reconhecimentos" class="xref">Reconhecimentos</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.9">
-            <p id="section-toc.1-1.9.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-avisos" class="xref">Avisos</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
+            <p id="section-toc.1-1.9.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-avisos" class="xref">Avisos</a></p>
 </li>
-<li class="toc ulEmpty" id="section-toc.1-1.10">
-            <p id="section-toc.1-1.10.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
+          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
+            <p id="section-toc.1-1.10.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a></p>
 </li>
-</ul>
+        </ul>
 </nav>
 </section>
 </div>
@@ -1262,17 +1359,14 @@ <h2 id="name-escopo">
 <a href="#section-1" class="section-number selfRef">1. </a><a href="#name-escopo" class="section-name selfRef">Escopo</a>
       </h2>
 <p id="section-1-1">Este documento especifica o m&#233;todo para os aplicativos<a href="#section-1-1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-1-2.1">
-          <p id="section-1-2.1.1">obterem de maneira segura os tokens OAuth necess&#225;rios para acesso a dados cr&#237;ticos de acordo com os requisitos do <a href="https://www.in.gov.br/en/web/dou/-/resolucao-conjunta-n-1-de-4-de-maio-de-2020-255165055">Open Banking Brasil</a>;<a href="#section-1-2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-1-2.1">obterem de maneira segura os tokens OAuth necess&#225;rios para acesso a dados cr&#237;ticos de acordo com os requisitos do <a href="https://www.in.gov.br/en/web/dou/-/resolucao-conjunta-n-1-de-4-de-maio-de-2020-255165055">Open Banking Brasil</a>;<a href="#section-1-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-1-2.2">
-          <p id="section-1-2.2.1">utilizarem o OpenID Connect para identifica&#231;&#227;o do usu&#225;rio do Open Banking; e<a href="#section-1-2.2.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-1-2.2">utilizarem o OpenID Connect para identifica&#231;&#227;o do usu&#225;rio do Open Banking; e<a href="#section-1-2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-1-2.3">
-          <p id="section-1-2.3.1">utilizarem o OpenID Connect para afirmar a identidade do cliente.<a href="#section-1-2.3.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-1-2.3">utilizarem o OpenID Connect para afirmar a identidade do cliente.<a href="#section-1-2.3" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 <p id="section-1-3">Este documento &#233; aplic&#225;vel a todos os participantes do Open Banking no Brasil.<a href="#section-1-3" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -1304,7 +1398,7 @@ <h2 id="name-refer234ncias-normativas">
 <p id="section-2-21"><a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">FAPI-1-Advanced</a> - Financial-grade API Security Profile 1.0 - Part 2: Advanced<a href="#section-2-21" class="pilcrow">¶</a></p>
 <p id="section-2-22"><a href="https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md">FAPI-2-Baseline</a> - Financial-grade API Security Profile 2.0 - Part 1: Baseline<a href="#section-2-22" class="pilcrow">¶</a></p>
 <p id="section-2-23"><a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md">LIWP</a> - OIDF FAPI WG Lodging Intent Working Paper<a href="#section-2-23" class="pilcrow">¶</a></p>
-<p id="section-2-24"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1.html">OBB-FAPI-DCR</a> - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0<a href="#section-2-24" class="pilcrow">¶</a></p>
+<p id="section-2-24"><a href="https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html">OBB-FAPI-DCR</a> - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0<a href="#section-2-24" class="pilcrow">¶</a></p>
 <p id="section-2-25"><a href="https://tools.ietf.org/html/rfc4648">RFC4648</a> - The Base16, Base32, and Base64 Data Encodings<a href="#section-2-25" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -1321,16 +1415,38 @@ <h2 id="name-termos-e-defini231245es">
       <h2 id="name-s237mbolos-e-termos-abrevia">
 <a href="#section-4" class="section-number selfRef">4. </a><a href="#name-s237mbolos-e-termos-abrevia" class="section-name selfRef">S&#237;mbolos e termos abreviados</a>
       </h2>
-<p id="section-4-1"><strong>API</strong> - Application Programming Interface (Interface de programa&#231;&#227;o de aplicativo)<a href="#section-4-1" class="pilcrow">¶</a></p>
-<p id="section-4-2"><strong>EIOBB</strong> - Estrutura Inicial do Open Banking Brasil<a href="#section-4-2" class="pilcrow">¶</a></p>
-<p id="section-4-3"><strong>CSRF</strong> - Cross Site Request Forgery<a href="#section-4-3" class="pilcrow">¶</a></p>
-<p id="section-4-4"><strong>DCR</strong> - Registro de cliente din&#226;mico<a href="#section-4-4" class="pilcrow">¶</a></p>
-<p id="section-4-5"><strong>FAPI</strong> - Financial-grade API<a href="#section-4-5" class="pilcrow">¶</a></p>
-<p id="section-4-6"><strong>HTTP</strong> - Protocolo de transfer&#234;ncia de hipertexto<a href="#section-4-6" class="pilcrow">¶</a></p>
-<p id="section-4-7"><strong>OIDF</strong> - OpenID Foundation<a href="#section-4-7" class="pilcrow">¶</a></p>
-<p id="section-4-8"><strong>REST</strong> - Representational State Transfer (Transfer&#234;ncia de Estado Representacional)<a href="#section-4-8" class="pilcrow">¶</a></p>
-<p id="section-4-9"><strong>TLS</strong> - Transport Layer Security (Seguran&#231;a da Camada de Transporte)<a href="#section-4-9" class="pilcrow">¶</a></p>
-<p id="section-4-10"><strong>MFA</strong> - Multi-Factor Authentication (Autentica&#231;&#227;o por M&#250;ltiplos Fatores)<a href="#section-4-10" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-4-1.1">
+          <strong>API</strong> - Application Programming Interface (Interface de programa&#231;&#227;o de aplicativo)<a href="#section-4-1.1" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.2">
+          <strong>CSRF</strong> - Cross Site Request Forgery<a href="#section-4-1.2" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.3">
+          <strong>DCR</strong> - Registro de cliente din&#226;mico<a href="#section-4-1.3" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.4">
+          <strong>EIOBB</strong> - Estrutura Inicial do Open Banking Brasil<a href="#section-4-1.4" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.5">
+          <strong>FAPI</strong> - Financial-grade API<a href="#section-4-1.5" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.6">
+          <strong>HTTP</strong> - Protocolo de transfer&#234;ncia de hipertexto<a href="#section-4-1.6" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.7">
+          <strong>MFA</strong> - Multi-Factor Authentication (Autentica&#231;&#227;o por M&#250;ltiplos Fatores)<a href="#section-4-1.7" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.8">
+          <strong>OIDF</strong> - OpenID Foundation<a href="#section-4-1.8" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.9">
+          <strong>REST</strong> - Representational State Transfer (Transfer&#234;ncia de Estado Representacional)<a href="#section-4-1.9" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-4-1.10">
+          <strong>TLS</strong> - Transport Layer Security (Seguran&#231;a da Camada de Transporte)<a href="#section-4-1.10" class="pilcrow">¶</a>
+</li>
+      </ul>
 </section>
 </div>
 <div id="securityprofile">
@@ -1345,20 +1461,16 @@ <h3 id="name-introdu231227o-2">
         </h3>
 <p id="section-5.1-1">O perfil de seguran&#231;a do Open Banking Brasil especifica requisitos adicionais de seguran&#231;a e de  identifica&#231;&#227;o para o acesso a API's com recursos cr&#237;ticos protegidas pelo OAuth 2.0 Authorization Framework, que consiste em <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>, <a href="https://tools.ietf.org/html/rfc6750">RFC6750</a>, <a href="https://tools.ietf.org/html/rfc7636">RFC7636</a>, <a href="https://openid.net/specs/openid-financial-api-part-1-1_0.html">FAPI-1-Baseline</a>, <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">FAPI-1-Advanced</a> e outras especifica&#231;&#245;es.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
 <p id="section-5.1-2">Este perfil descreve as capacidades e os recursos de seguran&#231;a que devem ser oferecidos por servidores e clientes que s&#227;o necess&#225;rios para o Programa do Open Banking Brasil, definindo as medidas para mitigar ou endere&#231;ar:<a href="#section-5.1-2" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-5.1-3.1">
-            <p id="section-5.1-3.1.1">ataques que abordam considera&#231;&#245;es de privacidade identificadas na cl&#225;usula 9.1 de [FAPI-1 Advanced].<a href="#section-5.1-3.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-5.1-3.1">ataques que abordam considera&#231;&#245;es de privacidade identificadas na cl&#225;usula 9.1 de [FAPI-1 Advanced].<a href="#section-5.1-3.1" class="pilcrow">¶</a>
 </li>
-<li id="section-5.1-3.2">
-            <p id="section-5.1-3.2.1">o requisito de concess&#227;o de acesso granular a recursos, com vistas &#224; minimiza&#231;&#227;o de dados;<a href="#section-5.1-3.2.1" class="pilcrow">¶</a></p>
+          <li class="compact" id="section-5.1-3.2">o requisito de concess&#227;o de acesso granular a recursos, com vistas &#224; minimiza&#231;&#227;o de dados;<a href="#section-5.1-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-5.1-3.3">
-            <p id="section-5.1-3.3.1">o requisito de informar sobre o contexto da autentica&#231;&#227;o do usu&#225;rio (claim Authentication Context Request - acr) que foi realizada por um Provedor OpenID, com vistas a favorecer o adequado gerenciamento do risco decorrente do acesso do usu&#225;rio;<a href="#section-5.1-3.3.1" class="pilcrow">¶</a></p>
+          <li class="compact" id="section-5.1-3.3">o requisito de informar sobre o contexto da autentica&#231;&#227;o do usu&#225;rio (claim Authentication Context Request - acr) que foi realizada por um Provedor OpenID, com vistas a favorecer o adequado gerenciamento do risco decorrente do acesso do usu&#225;rio;<a href="#section-5.1-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-5.1-3.4">
-            <p id="section-5.1-3.4.1">o requisito para que os clientes de API declarem um relacionamento pr&#233;vio com o usu&#225;rio, afirmando em uma <code>claim</code> de identifica&#231;&#227;o do usu&#225;rio como parte do fluxo de autoriza&#231;&#227;o.<a href="#section-5.1-3.4.1" class="pilcrow">¶</a></p>
+          <li class="compact" id="section-5.1-3.4">o requisito para que os clientes de API declarem um relacionamento pr&#233;vio com o usu&#225;rio, afirmando em uma <code>claim</code> de identifica&#231;&#227;o do usu&#225;rio como parte do fluxo de autoriza&#231;&#227;o.<a href="#section-5.1-3.4" class="pilcrow">¶</a>
 </li>
-</ul>
+        </ul>
 </section>
 </div>
 <div id="authserver">
@@ -1385,56 +1497,42 @@ <h4 id="name-servidor-de-autoriza231227o">
           </h4>
 <p id="section-5.2.2-1">O Servidor de Autoriza&#231;&#227;o <strong>deve</strong> suportar as disposi&#231;&#245;es especificadas na cl&#225;usula 5.2.2 de <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">Financial-grade API Security Profile 1.0 - Parte 2: Advanced</a>.<a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
 <p id="section-5.2.2-2">Al&#233;m disso, ele deve:<a href="#section-5.2.2-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-5.2.2-3">
-            <li id="section-5.2.2-3.1">
-              <p id="section-5.2.2-3.1.1">deve suportar Request Objects JWE assinados e criptografados passados por valor ou deve exigir requisi&#231;&#245;es do tipo "pushed authorization requests" <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a><a href="#section-5.2.2-3.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-5.2.2-3">
+<li id="section-5.2.2-3.1">deve suportar Request Objects JWE assinados e criptografados passados por valor ou deve exigir requisi&#231;&#245;es do tipo "pushed authorization requests" <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a>;<a href="#section-5.2.2-3.1" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.2">
-              <p id="section-5.2.2-3.2.1">deve publicar metadados de descoberta (incluindo a do endpoint de autoriza&#231;&#227;o) por meio do documento de metadado especificado em <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> e [RFC8414] (".well-known")<a href="#section-5.2.2-3.2.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.2">deve publicar metadados de descoberta (incluindo a do endpoint de autoriza&#231;&#227;o) por meio do documento de metadado especificado em <a href="https://openid.net/specs/openid-connect-discovery-1_0.html">OIDD</a> e [RFC8414] (".well-known");<a href="#section-5.2.2-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.3">
-              <p id="section-5.2.2-3.3.1">deve suportar os par&#226;metros <code>claims</code> como definido no item 5.5 do <a href="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core</a><a href="#section-5.2.2-3.3.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.3">deve suportar os par&#226;metros <code>claims</code> como definido no item 5.5 do <a href="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core</a>;<a href="#section-5.2.2-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.4">
-              <p id="section-5.2.2-3.4.1">deve suportar o atributo <code>claim</code> padr&#227;o oidc "cpf" conforme definido no item 5.2.2.2 deste documento<a href="#section-5.2.2-3.4.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.4">deve suportar o atributo <code>claim</code> padr&#227;o oidc "cpf" conforme definido no item 5.2.2.2 deste documento;<a href="#section-5.2.2-3.4" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.5">
-              <p id="section-5.2.2-3.5.1">deve suportar o atributo <code>claim</code> padr&#227;o oidc "cnpj" conforme definido no item 5.2.2.3 deste documento, se a institui&#231;&#227;o for detentora de conta para pessoas jur&#237;dicas<a href="#section-5.2.2-3.5.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.5">deve suportar o atributo <code>claim</code> padr&#227;o oidc "cnpj" conforme definido no item 5.2.2.3 deste documento, se a institui&#231;&#227;o for detentora de conta para pessoas jur&#237;dicas;<a href="#section-5.2.2-3.5" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.6">
-              <p id="section-5.2.2-3.6.1">deve suportar o atributo <code>acr</code> "urn:brasil:openbanking:loa2" como definido no item 5.2.2.4 deste documento<a href="#section-5.2.2-3.6.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.6">deve suportar o atributo <code>acr</code> "urn:brasil:openbanking:loa2" como definido no item 5.2.2.4 deste documento;<a href="#section-5.2.2-3.6" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.7">
-              <p id="section-5.2.2-3.7.1">deveria suportar o atributo <code>acr</code> "urn:brasil:openbanking:loa3" como definido no item 5.2.2.4 deste documento<a href="#section-5.2.2-3.7.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.7">deveria suportar o atributo <code>acr</code> "urn:brasil:openbanking:loa3" como definido no item 5.2.2.4 deste documento;<a href="#section-5.2.2-3.7" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.8">
-              <p id="section-5.2.2-3.8.1">deve implementar o endpoint "userinfo" como definido no item 5.3 do <a href="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core</a><a href="#section-5.2.2-3.8.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.8">deve implementar o endpoint "userinfo" como definido no item 5.3 do <a href="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core</a>;<a href="#section-5.2.2-3.8" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.9">
-              <p id="section-5.2.2-3.9.1">deve suportar o escopo parametriz&#225;vel ("parameterized OAuth 2.0 resource scope") <em>consent</em> como definido no item 6.3.1 de <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md">OIDF FAPI WG Lodging Intent Pattern</a><a href="#section-5.2.2-3.9.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.9">deve suportar o escopo parametriz&#225;vel ("parameterized OAuth 2.0 resource scope") <em>consent</em> como definido no item 6.3.1 de <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md">OIDF FAPI WG Lodging Intent Pattern</a>;<a href="#section-5.2.2-3.9" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.10">
-              <p id="section-5.2.2-3.10.1">pode suportar <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md">Financial-grade API: Client Initiated Backchannel Authentication Profile</a><a href="#section-5.2.2-3.10.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.10">pode suportar <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md">Financial-grade API: Client Initiated Backchannel Authentication Profile</a>;<a href="#section-5.2.2-3.10" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.11">
-              <p id="section-5.2.2-3.11.1">(requisito temporariamente retirado)<a href="#section-5.2.2-3.11.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.11">(requisito temporariamente retirado);<a href="#section-5.2.2-3.11" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.12">
-              <p id="section-5.2.2-3.12.1">deve suportar <code>refresh tokens</code><a href="#section-5.2.2-3.12.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.12">deve suportar <code>refresh tokens</code>;<a href="#section-5.2.2-3.12" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.13">
-              <p id="section-5.2.2-3.13.1">deve emitir <code>access tokens</code> com o tempo de expira&#231;&#227;o entre 300 (m&#237;nimo) e 900 (m&#225;ximo) segundos<a href="#section-5.2.2-3.13.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.13">deve emitir <code>access tokens</code> com o tempo de expira&#231;&#227;o entre 300 (m&#237;nimo) e 900 (m&#225;ximo) segundos;<a href="#section-5.2.2-3.13" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.14">
-              <p id="section-5.2.2-3.14.1">deve sempre incluir a claim <code>acr</code> no id_token<a href="#section-5.2.2-3.14.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.14">deve sempre incluir a claim <code>acr</code> no id_token;<a href="#section-5.2.2-3.14" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.15">
-              <p id="section-5.2.2-3.15.1">deve suportar os valores <code>code</code> e <code>id_token</code> para o atributo <code>response_type</code><a href="#section-5.2.2-3.15.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.15">deve suportar os valores <code>code</code> e <code>id_token</code> para o atributo <code>response_type</code>;<a href="#section-5.2.2-3.15" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2-3.16">
-              <p id="section-5.2.2-3.16.1">pode suportar o valor <code>code</code> para o atributo <code>response_type</code>em conjunto com o valor <code>jwt</code> para o atributo <code>response_mode</code><a href="#section-5.2.2-3.16.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.2-3.16">pode suportar o valor <code>code</code> para o atributo <code>response_type</code>em conjunto com o valor <code>jwt</code> para o atributo <code>response_mode</code>;<a href="#section-5.2.2-3.16" class="pilcrow">¶</a>
 </li>
-</ol>
+            <li id="section-5.2.2-3.17">n&#227;o deve permitir o recurso de rota&#231;&#227;o de <code>refresh tokens</code>.<a href="#section-5.2.2-3.17" class="pilcrow">¶</a>
+</li>
+          </ol>
 <div id="detached">
 <section id="section-5.2.2.1">
             <h5 id="name-token-de-id-como-assinatura">
@@ -1442,11 +1540,11 @@ <h5 id="name-token-de-id-como-assinatura">
             </h5>
 <p id="section-5.2.2.1-1">O Servidor de Autoriza&#231;&#227;o <em>deve</em> suportar as disposi&#231;&#245;es especificadas na cl&#225;usula 5.2.2.1 de <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">Financial-grade API Security Profile 1.0 - Parte 2: Advanced</a><a href="#section-5.2.2.1-1" class="pilcrow">¶</a></p>
 <p id="section-5.2.2.1-2">Al&#233;m disso, se o valor <code>response_type</code> <code>code id_token</code> for usado, o servidor de autoriza&#231;&#227;o:<a href="#section-5.2.2.1-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-5.2.2.1-3">
-              <li id="section-5.2.2.1-3.1">
-                <p id="section-5.2.2.1-3.1.1"><strong>n&#227;o deveria</strong> retornar Informa&#231;&#227;o de Identifica&#231;&#227;o Pessoal (PII) confidenciais no token de ID na resposta de autoriza&#231;&#227;o, mas se for necess&#225;rio, ent&#227;o ele <strong>deve</strong> criptografar o token de ID.<a href="#section-5.2.2.1-3.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-5.2.2.1-3">
+<li id="section-5.2.2.1-3.1">
+                <strong>n&#227;o deveria</strong> retornar Informa&#231;&#227;o de Identifica&#231;&#227;o Pessoal (PII) confidenciais no token de ID na resposta de autoriza&#231;&#227;o, mas se for necess&#225;rio, ent&#227;o ele <strong>deve</strong> criptografar o token de ID.<a href="#section-5.2.2.1-3.1" class="pilcrow">¶</a>
 </li>
-</ol>
+            </ol>
 </section>
 </div>
 <div id="cpf">
@@ -1481,14 +1579,14 @@ <h5 id="name-solicitando-a-claim-cnpj">
             <h5 id="name-solicitando-o-urnbrasilopen">
 <a href="#section-5.2.2.4" class="section-number selfRef">5.2.2.4. </a><a href="#name-solicitando-o-urnbrasilopen" class="section-name selfRef">Solicitando o "urn:brasil:openbanking:loa2" ou "urn:brasil:openbanking:loa3" Solicita&#231;&#227;o de contexto de autentica&#231;&#227;o</a>
             </h5>
-<ul>
-<li id="section-5.2.2.4-1.1">
-                <p id="section-5.2.2.4-1.1.1"><strong>LoA2</strong>: mecanismo de autentica&#231;&#227;o com a ado&#231;&#227;o de um &#250;nico fator<a href="#section-5.2.2.4-1.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-5.2.2.4-1.1">
+                <strong>LoA2</strong>: mecanismo de autentica&#231;&#227;o com a ado&#231;&#227;o de um &#250;nico fator<a href="#section-5.2.2.4-1.1" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2.4-1.2">
-                <p id="section-5.2.2.4-1.2.1"><strong>LoA3</strong>: mecanismo de autentica&#231;&#227;o com m&#250;ltiplos fatores de autentica&#231;&#227;o<a href="#section-5.2.2.4-1.2.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-5.2.2.4-1.2">
+                <strong>LoA3</strong>: mecanismo de autentica&#231;&#227;o com m&#250;ltiplos fatores de autentica&#231;&#227;o<a href="#section-5.2.2.4-1.2" class="pilcrow">¶</a>
 </li>
-</ul>
+            </ul>
 <p id="section-5.2.2.4-2">A seguinte orienta&#231;&#227;o deve ser observada para o mecanismo de autentica&#231;&#227;o:
 * De acordo com o Art. 17 da Resolu&#231;&#227;o Conjunta n&#186; 01, as institui&#231;&#245;es devem adotar  procedimentos e controles para autentica&#231;&#227;o de cliente <strong>compat&#237;veis com os aplic&#225;veis ao acesso a seus canais de atendimento eletr&#244;nicos</strong>.
 * Em observ&#226;ncia &#224; regula&#231;&#227;o em vigor, sugere-se que:
@@ -1497,17 +1595,14 @@ <h5 id="name-solicitando-o-urnbrasilopen">
 <p id="section-5.2.2.4-3">Em todos os casos, a ado&#231;&#227;o de mecanismo de autentica&#231;&#227;o mais rigoroso (<code>LoA3</code> ou superior) fica a crit&#233;rio da institui&#231;&#227;o transmissora ou detentora de conta, de acordo com sua avalia&#231;&#227;o de riscos e de forma compat&#237;vel com os mecanismos habitualmente utilizados.<a href="#section-5.2.2.4-3" class="pilcrow">¶</a></p>
 <p id="section-5.2.2.4-4"><strong>Esclarecimentos adicionais sobre fatores de autentica&#231;&#227;o</strong><a href="#section-5.2.2.4-4" class="pilcrow">¶</a></p>
 <p id="section-5.2.2.4-5">S&#227;o fatores de autentica&#231;&#227;o:<a href="#section-5.2.2.4-5" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-5.2.2.4-6.1">
-                <p id="section-5.2.2.4-6.1.1">Aquilo que <strong>voc&#234; conhece</strong>, como uma senha ou frase secreta<a href="#section-5.2.2.4-6.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-5.2.2.4-6.1">Aquilo que <strong>voc&#234; conhece</strong>, como uma senha ou frase secreta<a href="#section-5.2.2.4-6.1" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2.4-6.2">
-                <p id="section-5.2.2.4-6.2.1">Aquilo que <strong>voc&#234; tem</strong>, como um token, smartcard ou dispositivo<a href="#section-5.2.2.4-6.2.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-5.2.2.4-6.2">Aquilo que <strong>voc&#234; tem</strong>, como um token, smartcard ou dispositivo<a href="#section-5.2.2.4-6.2" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.2.4-6.3">
-                <p id="section-5.2.2.4-6.3.1">Aquilo que <strong>"voc&#234; &#233;"</strong>, ou seja, autentica&#231;&#227;o condicionada a apresenta&#231;&#227;o de uma caracter&#237;stica f&#237;sica exclusivamente sua, como a valida&#231;&#227;o por biometria<a href="#section-5.2.2.4-6.3.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-5.2.2.4-6.3">Aquilo que <strong>"voc&#234; &#233;"</strong>, ou seja, autentica&#231;&#227;o condicionada a apresenta&#231;&#227;o de uma caracter&#237;stica f&#237;sica exclusivamente sua, como a valida&#231;&#227;o por biometria<a href="#section-5.2.2.4-6.3" class="pilcrow">¶</a>
 </li>
-</ul>
+            </ul>
 <p id="section-5.2.2.4-7">Para realizar autentica&#231;&#227;o por m&#250;ltiplos fatores (MFA) &#233; necess&#225;rio que o usu&#225;rio apresente, ao menos, dois diferentes  fatores dos listados acima. Um mesmo fator usado mais de uma vez - por exemplo, a apresenta&#231;&#227;o de suas senhas que ele conhece - n&#227;o pode ser aceito como MFA.<a href="#section-5.2.2.4-7" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -1521,32 +1616,26 @@ <h4 id="name-cliente-confidencial">
 <p id="section-5.2.3-1">Um cliente confidencial deve apoiar as disposi&#231;&#245;es especificadas na cl&#225;usula 5.2.3 de
 <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">Financial-grade API Security Profile 1.0 - Part 2: Advanced</a>,<a href="#section-5.2.3-1" class="pilcrow">¶</a></p>
 <p id="section-5.2.3-2">Al&#233;m disso, o cliente confidencial<a href="#section-5.2.3-2" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-5.2.3-3">
-            <li id="section-5.2.3-3.1">
-              <p id="section-5.2.3-3.1.1">deve suportar objetos de solicita&#231;&#227;o <em>encrypted</em><a href="#section-5.2.3-3.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-5.2.3-3">
+<li id="section-5.2.3-3.1">deve suportar objetos de solicita&#231;&#227;o <em>encrypted</em>;<a href="#section-5.2.3-3.1" class="pilcrow">¶</a>
+</li>
+            <li id="section-5.2.3-3.2">deve suportar solicita&#231;&#245;es de autoriza&#231;&#227;o push (pushed authorization requests) <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a>;<a href="#section-5.2.3-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.2">
-              <p id="section-5.2.3-3.2.1">deve suportar solicita&#231;&#245;es de autoriza&#231;&#227;o push (pushed authorization requests) <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a><a href="#section-5.2.3-3.2.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.3">deve usar objetos de solicita&#231;&#227;o <em>encrypted</em> se n&#227;o usar <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a>;<a href="#section-5.2.3-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.3">
-              <p id="section-5.2.3-3.3.1">deve usar objetos de solicita&#231;&#227;o <em>encrypted</em> se n&#227;o usar <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a><a href="#section-5.2.3-3.3.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.4">deve suportar o escopo de recurso OAuth 2.0 parametrizado <em>consent</em> conforme definido na cl&#225;usula 6.3.1 <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md">OIDF FAPI WG Lodging Intent Pattern</a>;<a href="#section-5.2.3-3.4" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.4">
-              <p id="section-5.2.3-3.4.1">deve suportar o escopo de recurso OAuth 2.0 parametrizado <em>consent</em> conforme definido na cl&#225;usula 6.3.1 <a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md">OIDF FAPI WG Lodging Intent Pattern</a><a href="#section-5.2.3-3.4.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.5">deve suportar <code>refresh tokens</code>;<a href="#section-5.2.3-3.5" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.5">
-              <p id="section-5.2.3-3.5.1">deve suportar <code>refresh tokens</code><a href="#section-5.2.3-3.5.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.6">n&#227;o deve incluir um valor espec&#237;fico na <em>claim</em> <code>acr</code>;<a href="#section-5.2.3-3.6" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.6">
-              <p id="section-5.2.3-3.6.1">n&#227;o deve incluir um valor espec&#237;fico na <em>claim</em> <code>acr</code><a href="#section-5.2.3-3.6.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.7">deve definir a <em>claim</em> <code>acr</code>como <em>essential</em>;<a href="#section-5.2.3-3.7" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.7">
-              <p id="section-5.2.3-3.7.1">deve definir a <em>claim</em> <code>acr</code>como <em>essential</em><a href="#section-5.2.3-3.7.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.8">deve suportar todos os m&#233;todos de autentica&#231;&#227;o especificados no item 14 da se&#231;&#227;o 5.2.2 da <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">Financial-grade API Security Profile 1.0 - Part 2: Advanced</a> incluindo as diferentes combina&#231;&#245;es de m&#233;todos de encaminhamento dos Requests Objects (usando ou n&#227;o <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a> - item 11);<a href="#section-5.2.3-3.8" class="pilcrow">¶</a>
 </li>
-<li id="section-5.2.3-3.8">
-              <p id="section-5.2.3-3.8.1">deve suportar todos os m&#233;todos de autentica&#231;&#227;o especificados no item 14 da se&#231;&#227;o 5.2.2 da <a href="https://openid.net/specs/openid-financial-api-part-2-1_0.html">Financial-grade API Security Profile 1.0 - Part 2: Advanced</a> incluindo as diferentes combina&#231;&#245;es de m&#233;todos de encaminhamento dos Requests Objects (usando ou n&#227;o <a href="https://tools.ietf.org/html/draft-ietf-oauth-par">PAR</a> - item 11).<a href="#section-5.2.3-3.8.1" class="pilcrow">¶</a></p>
+            <li id="section-5.2.3-3.9">n&#227;o deve permitir o recurso de rota&#231;&#227;o de <code>refresh tokens</code>.<a href="#section-5.2.3-3.9" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 </section>
 </div>
 </section>
@@ -1565,88 +1654,88 @@ <h3 id="name-considera231245es-sobre-ass">
 <a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-considera231245es-sobre-ass" class="section-name selfRef">Considera&#231;&#245;es sobre assinatura do conte&#250;do de mensagens (JWS)</a>
         </h3>
 <ol start="1" type="1" class="normal type-1" id="section-6.1-1">
-          <li id="section-6.1-1.1">
+<li id="section-6.1-1.1">
             <p id="section-6.1-1.1.1">Para garantir a integridade e o n&#227;o-rep&#250;dio das informa&#231;&#245;es tramitadas em <strong>API's sens&#237;veis e que indicam essa necessidade na sua documenta&#231;&#227;o</strong>, deve ser adotado a estrutura no padr&#227;o JWS definida na <a href="https://tools.ietf.org/html/rfc7515">RFC7515</a> e que inclui:<a href="#section-6.1-1.1.1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-6.1-1.1.2.1">
-                <p id="section-6.1-1.1.2.1.1">Cabe&#231;alho (<em>JSON Object Signing and Encryption - JOSE Header</em>), onde se define o algoritmo utilizado e inclui informa&#231;&#245;es sobre a chave p&#250;blica ou certificado que podem ser utilizadas para validar a assinatura;<a href="#section-6.1-1.1.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-6.1-1.1.2.1">Cabe&#231;alho (<em>JSON Object Signing and Encryption - JOSE Header</em>), onde se define o algoritmo utilizado e inclui informa&#231;&#245;es sobre a chave p&#250;blica ou certificado que podem ser utilizadas para validar a assinatura;<a href="#section-6.1-1.1.2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.1.2.2">
-                <p id="section-6.1-1.1.2.2.1">Payload (<em>JWS Payload</em>): conte&#250;do propriamente dito e detalhado na especifica&#231;&#227;o da API;<a href="#section-6.1-1.1.2.2.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.1.2.2">Payload (<em>JWS Payload</em>): conte&#250;do propriamente dito e detalhado na especifica&#231;&#227;o da API;<a href="#section-6.1-1.1.2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.1.2.3">
-                <p id="section-6.1-1.1.2.3.1">Assinatura digital (<em>JWS Signature</em>): assinatura digital, realizada conforme par&#226;metros do cabe&#231;alho.<a href="#section-6.1-1.1.2.3.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.1.2.3">Assinatura digital (<em>JWS Signature</em>): assinatura digital, realizada conforme par&#226;metros do cabe&#231;alho.<a href="#section-6.1-1.1.2.3" class="pilcrow">¶</a>
 </li>
-</ul>
+            </ul>
 </li>
-<li id="section-6.1-1.2">
+          <li id="section-6.1-1.2">
             <p id="section-6.1-1.2.1">Cada elemento acima deve ser codificado utilizando o padr&#227;o Base64url <a href="https://tools.ietf.org/html/rfc4648#section-5">RFC4648</a> e, feito isso, os elementos devem ser concatenados com "." (m&#233;todo JWS Compact Serialization, conforme definido na <a href="https://tools.ietf.org/html/rfc7515">RFC7515</a>).<a href="#section-6.1-1.2.1" class="pilcrow">¶</a></p>
 </li>
-<li id="section-6.1-1.3">
+          <li id="section-6.1-1.3">
             <p id="section-6.1-1.3.1">O payload das mensagens (requisi&#231;&#227;o <em>JWT</em> e resposta <em>JWT</em>) assinadas devem incluir as seguintes <code>claims</code> presentes na <a href="JWT">RFC7519</a>:<a href="#section-6.1-1.3.1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-6.1-1.3.2.1">
-                <p id="section-6.1-1.3.2.1.1"><strong>aud</strong> (na requisi&#231;&#227;o <em>JWT</em>): o Provedor do Recurso (p. ex. a institui&#231;&#227;o detentora da conta) dever&#225; validar se o valor do campo <strong>aud</strong> coincide com o endpoint sendo acionado;<a href="#section-6.1-1.3.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-6.1-1.3.2.1">
+                <strong>aud</strong> (na requisi&#231;&#227;o <em>JWT</em>): o Provedor do Recurso (p. ex. a institui&#231;&#227;o detentora da conta) dever&#225; validar se o valor do campo <strong>aud</strong> coincide com o endpoint sendo acionado;<a href="#section-6.1-1.3.2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.3.2.2">
-                <p id="section-6.1-1.3.2.2.1"><strong>aud</strong> (na resposta <em>JWT</em>): o cliente da API (p. e. institui&#231;&#227;o iniciadora) dever&#225; validar se o valor do campo <strong>aud</strong> coincide com o seu pr&#243;prio <code>organisationId</code> listado no diret&#243;rio;<a href="#section-6.1-1.3.2.2.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.3.2.2">
+                <strong>aud</strong> (na resposta <em>JWT</em>): o cliente da API (p. e. institui&#231;&#227;o iniciadora) dever&#225; validar se o valor do campo <strong>aud</strong> coincide com o seu pr&#243;prio <code>organisationId</code> listado no diret&#243;rio;<a href="#section-6.1-1.3.2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.3.2.3">
-                <p id="section-6.1-1.3.2.3.1"><strong>iss</strong> (na requisi&#231;&#227;o <em>JWT</em> e na resposta <em>JWT</em>): o receptor da mensagem dever&#225; validar se o valor do campo <strong>iss</strong> coincide com o <code>organisationId</code> do emissor;<a href="#section-6.1-1.3.2.3.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.3.2.3">
+                <strong>iss</strong> (na requisi&#231;&#227;o <em>JWT</em> e na resposta <em>JWT</em>): o receptor da mensagem dever&#225; validar se o valor do campo <strong>iss</strong> coincide com o <code>organisationId</code> do emissor;<a href="#section-6.1-1.3.2.3" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.3.2.4">
-                <p id="section-6.1-1.3.2.4.1"><strong>jti</strong> (na requisi&#231;&#227;o <em>JWT</em> e na resposta <em>JWT</em>): o valor do campo <strong>jti</strong> dever&#225; ser preenchido com o UUID definido pela institui&#231;&#227;o de acordo com a [RFC4122] usando o vers&#227;o 4;<a href="#section-6.1-1.3.2.4.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.3.2.4">
+                <strong>jti</strong> (na requisi&#231;&#227;o <em>JWT</em> e na resposta <em>JWT</em>): o valor do campo <strong>jti</strong> dever&#225; ser preenchido com o UUID definido pela institui&#231;&#227;o de acordo com a [RFC4122] usando o vers&#227;o 4;<a href="#section-6.1-1.3.2.4" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.3.2.5">
-                <p id="section-6.1-1.3.2.5.1"><strong>iat</strong> (na requisi&#231;&#227;o <em>JWT</em> e na resposta <em>JWT</em>): o valor do campo <strong>iat</strong> dever&#225; ser preenchido com hor&#225;rio da gera&#231;&#227;o da mensagem e de acordo com o padr&#227;o  estabelecido na <a href="https://datatracker.ietf.org/doc/html/rfc7519#section-2">RFC7519</a> para o formato <em>NumericDate</em>.<a href="#section-6.1-1.3.2.5.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.3.2.5">
+                <strong>iat</strong> (na requisi&#231;&#227;o <em>JWT</em> e na resposta <em>JWT</em>): o valor do campo <strong>iat</strong> dever&#225; ser preenchido com hor&#225;rio da gera&#231;&#227;o da mensagem e de acordo com o padr&#227;o  estabelecido na <a href="https://datatracker.ietf.org/doc/html/rfc7519#section-2">RFC7519</a> para o formato <em>NumericDate</em>.<a href="#section-6.1-1.3.2.5" class="pilcrow">¶</a>
 </li>
-</ul>
+            </ul>
 </li>
-<li id="section-6.1-1.4">
+          <li id="section-6.1-1.4">
             <p id="section-6.1-1.4.1">O content-type HTTP das requisi&#231;&#245;es e respostas com mensagens JWS deve ser definido como: "application/jwt".<a href="#section-6.1-1.4.1" class="pilcrow">¶</a></p>
 </li>
-<li id="section-6.1-1.5">
+          <li id="section-6.1-1.5">
             <p id="section-6.1-1.5.1">No cabe&#231;alho JOSE deve constar os seguintes atributos:<a href="#section-6.1-1.5.1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-6.1-1.5.2.1">
-                <p id="section-6.1-1.5.2.1.1"><strong>alg</strong> - deve ser preenchido com o valor <code>PS256</code>";<a href="#section-6.1-1.5.2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-6.1-1.5.2.1">
+                <strong>alg</strong> - deve ser preenchido com o valor <code>PS256</code>";<a href="#section-6.1-1.5.2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.5.2.2">
-                <p id="section-6.1-1.5.2.2.1"><strong>kid</strong> - deve ser obrigatoriamente preenchido com o valor do identificador da chave utilizado para a assinatura;<a href="#section-6.1-1.5.2.2.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.5.2.2">
+                <strong>kid</strong> - deve ser obrigatoriamente preenchido com o valor do identificador da chave utilizado para a assinatura;<a href="#section-6.1-1.5.2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-1.5.2.3">
-                <p id="section-6.1-1.5.2.3.1"><strong>typ</strong> - deve ser preenchido com o valor <code>JWT</code>.<a href="#section-6.1-1.5.2.3.1" class="pilcrow">¶</a></p>
+              <li class="compact" id="section-6.1-1.5.2.3">
+                <strong>typ</strong> - deve ser preenchido com o valor <code>JWT</code>.<a href="#section-6.1-1.5.2.3" class="pilcrow">¶</a>
 </li>
-</ul>
+            </ul>
 </li>
-</ol>
-<ul>
-<li id="section-6.1-2.1">
-            <p id="section-6.1-2.1.1">Em caso de erro na valida&#231;&#227;o da assinatura pelo <code>Provedor do Recurso</code> a API deve retornar mensagem de erro HTTP com <code>status code</code> <strong>400</strong> e a resposta deve incluir na propriedade <code>code</code> do objeto de resposta de erro especificado na API (<code>ResponseError</code>) a indica&#231;&#227;o da falha com o conte&#250;do <code>BAD_SIGNATURE</code>.<a href="#section-6.1-2.1.1" class="pilcrow">¶</a></p>
+        </ol>
+<ul class="compact">
+<li class="compact" id="section-6.1-2.1">Em caso de erro na valida&#231;&#227;o da assinatura pelo <code>Provedor do Recurso</code> a API deve retornar mensagem de erro HTTP com <code>status code</code> <strong>400</strong> e a resposta deve incluir na propriedade <code>code</code> do objeto de resposta de erro especificado na API (<code>ResponseError</code>) a indica&#231;&#227;o da falha com o conte&#250;do <code>BAD_SIGNATURE</code>.<a href="#section-6.1-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1-2.2">
-            <p id="section-6.1-2.2.1">Erros na valida&#231;&#227;o da mensagem recebida pela aplica&#231;&#227;o cliente (p. ex. iniciador de pagamento) devem ser registrados e o <code>Provedor do Recurso</code> (p. ex. institui&#231;&#227;o detentora de conta) deve ser notificado.<a href="#section-6.1-2.2.1" class="pilcrow">¶</a></p>
+          <li class="compact" id="section-6.1-2.2">Erros na valida&#231;&#227;o da mensagem recebida pela aplica&#231;&#227;o cliente (p. ex. iniciador de pagamento) devem ser registrados e o <code>Provedor do Recurso</code> (p. ex. institui&#231;&#227;o detentora de conta) deve ser notificado.<a href="#section-6.1-2.2" class="pilcrow">¶</a>
 </li>
-</ul>
+        </ul>
 <ol start="6" type="1" class="normal type-1" id="section-6.1-3">
-          <li id="section-6.1-3.1">
+<li id="section-6.1-3.1">
             <p id="section-6.1-3.1.1">O receptor  deve validar a consist&#234;ncia da assinatura digital da mensagem JWS <strong>exclusivamente com base nas informa&#231;&#245;es obtidas do diret&#243;rio</strong>, ou seja, com base nas chaves publicadas no JWKS da institui&#231;&#227;o no diret&#243;rio.<a href="#section-6.1-3.1.1" class="pilcrow">¶</a></p>
 </li>
-<li id="section-6.1-3.2">
-            <p id="section-6.1-3.2.1">As assinaturas devem ser realizadas com uso do certificado digital de assinatura especificado no <a href="https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-certificate-standards-1_ID1-ptbr.md#certificado-de-assinatura-certificadoassinatura">Padr&#227;o de Certificados Open Banking Brasil</a>.<a href="#section-6.1-3.2.1" class="pilcrow">¶</a></p>
+          <li id="section-6.1-3.2">
+            <p id="section-6.1-3.2.1">As assinaturas devem ser realizadas com uso do certificado digital de assinatura especificado no <a href="https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-certificate-standards-1_ID1-ptbr.md#certificado-de-assinatura-certificadoassinatura">Padr&#227;o de Certificados Open Banking Brasil</a>;<a href="#section-6.1-3.2.1" class="pilcrow">¶</a></p>
 </li>
-</ol>
+          <li id="section-6.1-3.3">
+            <p id="section-6.1-3.3.1">A claim <em>iat</em> deve ser num&#233;rica no formato Unix Time GMT+0 com toler&#226;ncia de +/- 60 segundos;<a href="#section-6.1-3.3.1" class="pilcrow">¶</a></p>
+</li>
+          <li id="section-6.1-3.4">
+            <p id="section-6.1-3.4.1">A claim do <em>jti</em> deve ser &#250;nica para um <em>clientId</em> dentro de um intervalo de tempo de 86.400 segundos (24h), n&#227;o podendo ser reutilizada neste per&#237;odo. Em caso de reutiliza&#231;&#227;o, dever&#225; ser retornado o c&#243;digo de erro HTTP 403;<a href="#section-6.1-3.4.1" class="pilcrow">¶</a></p>
+</li>
+        </ol>
 <div id="alg">
 <section id="section-6.1.1">
           <h4 id="name-considera231245es-sobre-alg">
 <a href="#section-6.1.1" class="section-number selfRef">6.1.1. </a><a href="#name-considera231245es-sobre-alg" class="section-name selfRef">Considera&#231;&#245;es sobre algoritmos de assinatura</a>
           </h4>
 <p id="section-6.1.1-1">Para JWS, clientes e servidores de autoriza&#231;&#227;o<a href="#section-6.1.1-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-6.1.1-2">
-            <li id="section-6.1.1-2.1">
-              <p id="section-6.1.1-2.1.1">devem usar o algoritmo PS256;<a href="#section-6.1.1-2.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-6.1.1-2">
+<li id="section-6.1.1-2.1">devem usar o algoritmo PS256;<a href="#section-6.1.1-2.1" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 </section>
 </div>
 <div id="cipher">
@@ -1655,11 +1744,10 @@ <h4 id="name-considera231245es-de-algori">
 <a href="#section-6.1.2" class="section-number selfRef">6.1.2. </a><a href="#name-considera231245es-de-algori" class="section-name selfRef">Considera&#231;&#245;es de algoritmo de criptografia</a>
           </h4>
 <p id="section-6.1.2-1">Para JWE, clientes e servidores de autoriza&#231;&#227;o<a href="#section-6.1.2-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-6.1.2-2">
-            <li id="section-6.1.2-2.1">
-              <p id="section-6.1.2-2.1.1">devem usar RSA-OAEP com A256GCM<a href="#section-6.1.2-2.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-6.1.2-2">
+<li id="section-6.1.2-2.1">devem usar RSA-OAEP com A256GCM<a href="#section-6.1.2-2.1" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 </section>
 </div>
 <div id="tls">
@@ -1668,14 +1756,14 @@ <h4 id="name-considera231245es-sobre-o-u">
 <a href="#section-6.1.3" class="section-number selfRef">6.1.3. </a><a href="#name-considera231245es-sobre-o-u" class="section-name selfRef">Considera&#231;&#245;es sobre o uso seguro do Transport Layer Security</a>
           </h4>
 <p id="section-6.1.3-1">Para TLS, endpoints do Servidor de Autentica&#231;&#227;o e endpoints do Servidor de Recursos usados diretamente pelo cliente:<a href="#section-6.1.3-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-6.1.3-2">
-            <li id="section-6.1.3-2.1">
-              <p id="section-6.1.3-2.1.1">devem suportar <code>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</code><a href="#section-6.1.3-2.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-6.1.3-2">
+<li id="section-6.1.3-2.1">devem suportar <code>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</code><a href="#section-6.1.3-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-6.1.3-2.2">
-              <p id="section-6.1.3-2.2.1">devem suportar <code>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</code><a href="#section-6.1.3-2.2.1" class="pilcrow">¶</a></p>
+            <li id="section-6.1.3-2.2">devem suportar <code>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</code><a href="#section-6.1.3-2.2" class="pilcrow">¶</a>
 </li>
-</ol>
+            <li id="section-6.1.3-2.3">As funcionalidades "TLS Session Resumption" e "TLS Renegotiation" devem ser desabilitadas<a href="#section-6.1.3-2.3" class="pilcrow">¶</a>
+</li>
+          </ol>
 </section>
 </div>
 </section>
@@ -1706,29 +1794,23 @@ <h4 id="name-defini231227o-de-escopo-de-">
 <a href="#section-7.1.2" class="section-number selfRef">7.1.2. </a><a href="#name-defini231227o-de-escopo-de-" class="section-name selfRef">Defini&#231;&#227;o de Escopo de Consentimento Din&#226;mico</a>
           </h4>
 <p id="section-7.1.2-1">Este perfil define o escopo din&#226;mico do OAuth 2.0 "consentimento" da seguinte maneira:<a href="#section-7.1.2-1" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-7.1.2-2.1">
-              <p id="section-7.1.2-2.1.1">string 'consent'; e<a href="#section-7.1.2-2.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-7.1.2-2.1">string 'consent'; e<a href="#section-7.1.2-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.2-2.2">
-              <p id="section-7.1.2-2.2.1">delimitador de dois pontos ":"; e<a href="#section-7.1.2-2.2.1" class="pilcrow">¶</a></p>
+            <li class="compact" id="section-7.1.2-2.2">delimitador de dois pontos ":"; e<a href="#section-7.1.2-2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.2-2.3">
-              <p id="section-7.1.2-2.3.1">Consent API REST Resource Id retornado por uma cria&#231;&#227;o bem-sucedida de <a href="https://openbanking-brasil.github.io/areadesenvolvedor/#fase-2-apis-do-open-banking-brasil-api-consentimento">Open Banking Consent Resource</a>;<a href="#section-7.1.2-2.3.1" class="pilcrow">¶</a></p>
+            <li class="compact" id="section-7.1.2-2.3">Consent API REST Resource Id retornado por uma cria&#231;&#227;o bem-sucedida de <a href="https://openbanking-brasil.github.io/areadesenvolvedor/#fase-2-apis-do-open-banking-brasil-api-consentimento">Open Banking Consent Resource</a>;<a href="#section-7.1.2-2.3" class="pilcrow">¶</a>
 </li>
-</ul>
+          </ul>
 <p id="section-7.1.2-3">Adicionalmente:<a href="#section-7.1.2-3" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-7.1.2-4.1">
-              <p id="section-7.1.2-4.1.1">Consent Resource Id deve incluir caracteres seguros para url;<a href="#section-7.1.2-4.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-7.1.2-4.1">Consent Resource Id deve incluir caracteres seguros para url;<a href="#section-7.1.2-4.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.2-4.2">
-              <p id="section-7.1.2-4.2.1">Consent Resource Id deve ser "namespaced";<a href="#section-7.1.2-4.2.1" class="pilcrow">¶</a></p>
+            <li class="compact" id="section-7.1.2-4.2">Consent Resource Id deve ser "namespaced";<a href="#section-7.1.2-4.2" class="pilcrow">¶</a>
 </li>
-<li id="section-7.1.2-4.3">
-              <p id="section-7.1.2-4.3.1">Consent Resource Id deve ter propriedades de um <code>nonce</code> <a href="https://openid.net/specs/openid-connect-core-1_0.html#NonceNotes">Nonce</a>;<a href="#section-7.1.2-4.3.1" class="pilcrow">¶</a></p>
+            <li class="compact" id="section-7.1.2-4.3">Consent Resource Id deve ter propriedades de um <code>nonce</code> <a href="https://openid.net/specs/openid-connect-core-1_0.html#NonceNotes">Nonce</a>;<a href="#section-7.1.2-4.3" class="pilcrow">¶</a>
 </li>
-</ul>
+          </ul>
 </section>
 </div>
 <div id="consentexample">
@@ -1768,41 +1850,30 @@ <h4 id="name-servidor-de-autoriza231227o-2">
 <a href="#section-7.2.2" class="section-number selfRef">7.2.2. </a><a href="#name-servidor-de-autoriza231227o-2" class="section-name selfRef">Servidor de autoriza&#231;&#227;o</a>
           </h4>
 <p id="section-7.2.2-1">Al&#233;m dos requisitos descritos nas disposi&#231;&#245;es de seguran&#231;a do Open Banking Brasil, o Servidor de Autoriza&#231;&#227;o<a href="#section-7.2.2-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-7.2.2-2">
-            <li id="section-7.2.2-2.1">
-              <p id="section-7.2.2-2.1.1">deve apenas emitir <em>refresh</em>tokens_ quando vinculados a um consentimento ativo e v&#225;lido;<a href="#section-7.2.2-2.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-7.2.2-2">
+<li id="section-7.2.2-2.1">deve apenas emitir _refresh<em>tokens</em> quando vinculados a um consentimento ativo e v&#225;lido;<a href="#section-7.2.2-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.2">
-              <p id="section-7.2.2-2.2.1">s&#243; deve compartilhar o acesso aos recursos quando apresentado <em>access</em>token_ vinculado a um consentimento ativo e v&#225;lido;<a href="#section-7.2.2-2.2.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.2">s&#243; deve compartilhar o acesso aos recursos quando apresentado _access<em>token</em> vinculado a um consentimento ativo e v&#225;lido;<a href="#section-7.2.2-2.2" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.3">
-              <p id="section-7.2.2-2.3.1">deve revogar os <em>refresh tokens</em> e, quando aplic&#225;vel, os <em>access tokens</em> quando o Consentimento (Consent Resource) relacionado for apagado;<a href="#section-7.2.2-2.3.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.3">deve revogar os <em>refresh tokens</em> e, quando aplic&#225;vel, os <em>access tokens</em> quando o Consentimento (Consent Resource) relacionado for apagado;<a href="#section-7.2.2-2.3" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.4">
-              <p id="section-7.2.2-2.4.1">deve garantir que os <em>access tokens</em> s&#227;o emitidos com os <em>scopes</em> necess&#225;rios para permitir acesso aos dados especificados em elemento <em>Permission</em> do Consentimento (Consent Resource Object) relacionado;<a href="#section-7.2.2-2.4.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.4">deve garantir que os <em>access tokens</em> s&#227;o emitidos com os <em>scopes</em> necess&#225;rios para permitir acesso aos dados especificados em elemento <em>Permission</em> do Consentimento (Consent Resource Object) relacionado;<a href="#section-7.2.2-2.4" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.5">
-              <p id="section-7.2.2-2.5.1">n&#227;o deve rejeitar pedido de autoriza&#231;&#227;o com <em>scopes</em> al&#233;m do necess&#225;rio para permitir acesso a dados definidos em elemento <em>Permission</em> do Consentimento (Consent Resource Object) relacionado;<a href="#section-7.2.2-2.5.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.5">n&#227;o deve rejeitar pedido de autoriza&#231;&#227;o com <em>scopes</em> al&#233;m do necess&#225;rio para permitir acesso a dados definidos em elemento <em>Permission</em> do Consentimento (Consent Resource Object) relacionado;<a href="#section-7.2.2-2.5" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.6">
-              <p id="section-7.2.2-2.6.1">pode reduzir o escopo solicitado para um n&#237;vel que seja suficiente para permitir o acesso aos dados definidos em elemento <em>Permission</em> do Consentimento (Consent Resource Object) relacionado;<a href="#section-7.2.2-2.6.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.6">pode reduzir o escopo solicitado para um n&#237;vel que seja suficiente para permitir o acesso aos dados definidos em elemento <em>Permission</em> do Consentimento (Consent Resource Object) relacionado;<a href="#section-7.2.2-2.6" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.7">
-              <p id="section-7.2.2-2.7.1">deve manter registros sobre o hist&#243;rico dos consentimento para permitir a adequada forma&#231;&#227;o de trilhas de auditoria em conformidade com a regula&#231;&#227;o em vigor;<a href="#section-7.2.2-2.7.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.7">deve manter registros sobre o hist&#243;rico dos consentimento para permitir a adequada forma&#231;&#227;o de trilhas de auditoria em conformidade com a regula&#231;&#227;o em vigor;<a href="#section-7.2.2-2.7" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.8">
-              <p id="section-7.2.2-2.8.1">deve retornar falha na autentica&#231;&#227;o e o c&#243;digo de retorno <em>access</em>denied_ no par&#226;metro <em>erro</em> (como especificado na se&#231;&#227;o 4.1.2.1 da <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>) caso o CPF do usu&#225;rio autenticado n&#227;o seja o mesmo indicado no elemento <em>loggedUser</em> do Consentimento (Consent Resource Object);<a href="#section-7.2.2-2.8.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.8">deve retornar falha na autentica&#231;&#227;o e o c&#243;digo de retorno _access<em>denied</em> no par&#226;metro <em>erro</em> (como especificado na se&#231;&#227;o 4.1.2.1 da <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>) caso o CPF do usu&#225;rio autenticado n&#227;o seja o mesmo indicado no elemento <em>loggedUser</em> do Consentimento (Consent Resource Object);<a href="#section-7.2.2-2.8" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.9">
-              <p id="section-7.2.2-2.9.1">deve retornar falha na autentica&#231;&#227;o e o c&#243;digo de retorno <em>access</em>denied_ no par&#226;metro <em>erro</em> (como especificado na se&#231;&#227;o 4.1.2.1 da <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>) caso o elemento <em>businessEntity</em> n&#227;o tenha sido preenchido no Consentimento (Consent Resource Object) relacionado e o usu&#225;rio tenha selecionado ou se autenticado por meio de credencial relacionada &#224; conta do tipo Pessoa Jur&#237;dica (PJ);<a href="#section-7.2.2-2.9.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.9">deve retornar falha na autentica&#231;&#227;o e o c&#243;digo de retorno _access<em>denied</em> no par&#226;metro <em>erro</em> (como especificado na se&#231;&#227;o 4.1.2.1 da <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>) caso o elemento <em>businessEntity</em> n&#227;o tenha sido preenchido no Consentimento (Consent Resource Object) relacionado e o usu&#225;rio tenha selecionado ou se autenticado por meio de credencial relacionada &#224; conta do tipo Pessoa Jur&#237;dica (PJ);<a href="#section-7.2.2-2.9" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.10">
-              <p id="section-7.2.2-2.10.1">deve condicionar a autentica&#231;&#227;o ou sele&#231;&#227;o de contas do tipo PJ &#224; consist&#234;ncia entre o CNPJ relacionado &#224;(s) conta(s) e o valor presente no elemento <em>businessEntity</em> do Consentimento (Consent Resource Object). Em caso de diverg&#234;ncia deve retornar falha na autentica&#231;&#227;o e o c&#243;digo de retorno <em>access</em>denied_ no par&#226;metro <em>erro</em> (como especificado na se&#231;&#227;o 4.1.2.1 da <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>);<a href="#section-7.2.2-2.10.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.10">deve condicionar a autentica&#231;&#227;o ou sele&#231;&#227;o de contas do tipo PJ &#224; consist&#234;ncia entre o CNPJ relacionado &#224;(s) conta(s) e o valor presente no elemento <em>businessEntity</em> do Consentimento (Consent Resource Object). Em caso de diverg&#234;ncia deve retornar falha na autentica&#231;&#227;o e o c&#243;digo de retorno _access<em>denied</em> no par&#226;metro <em>erro</em> (como especificado na se&#231;&#227;o 4.1.2.1 da <a href="https://tools.ietf.org/html/rfc6749">RFC6749</a>);<a href="#section-7.2.2-2.10" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.2-2.11">
-              <p id="section-7.2.2-2.11.1">deve emitir <em>refresh</em>token_ com validade n&#227;o inferior &#224; validade do consentimento ao qual est&#225; relacionado, respeitado os demais crit&#233;rios acima.<a href="#section-7.2.2-2.11.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.2-2.11">deve emitir _refresh<em>token</em> com validade n&#227;o inferior &#224; validade do consentimento ao qual est&#225; relacionado, respeitado os demais crit&#233;rios acima.<a href="#section-7.2.2-2.11" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 </section>
 </div>
 <div id="clientconfidential">
@@ -1811,14 +1882,12 @@ <h4 id="name-cliente-confidencial-2">
 <a href="#section-7.2.3" class="section-number selfRef">7.2.3. </a><a href="#name-cliente-confidencial-2" class="section-name selfRef">Cliente confidencial</a>
           </h4>
 <p id="section-7.2.3-1">Al&#233;m dos requisitos descritos nas disposi&#231;&#245;es de seguran&#231;a do Open Banking Brasil, o Cliente Confidencial<a href="#section-7.2.3-1" class="pilcrow">¶</a></p>
-<ol start="1" type="1" class="normal type-1" id="section-7.2.3-2">
-            <li id="section-7.2.3-2.1">
-              <p id="section-7.2.3-2.1.1">deve, sempre que poss&#237;vel, revogar e cessar o uso de <em>refresh</em> e de <em>access tokens</em>  vinculados a um consentimento (Consent Resource Object) que foi exclu&#237;do;<a href="#section-7.2.3-2.1.1" class="pilcrow">¶</a></p>
+<ol start="1" type="1" class="compact type-1" id="section-7.2.3-2">
+<li id="section-7.2.3-2.1">deve, sempre que poss&#237;vel, revogar e cessar o uso de <em>refresh</em> e de <em>access tokens</em>  vinculados a um consentimento (Consent Resource Object) que foi exclu&#237;do;<a href="#section-7.2.3-2.1" class="pilcrow">¶</a>
 </li>
-<li id="section-7.2.3-2.2">
-              <p id="section-7.2.3-2.2.1">deve excluir consentimentos (Consent Resource Objects) que est&#227;o expirados;<a href="#section-7.2.3-2.2.1" class="pilcrow">¶</a></p>
+            <li id="section-7.2.3-2.2">deve excluir consentimentos (Consent Resource Objects) que est&#227;o expirados;<a href="#section-7.2.3-2.2" class="pilcrow">¶</a>
 </li>
-</ol>
+          </ol>
 </section>
 </div>
 </section>
@@ -1832,52 +1901,37 @@ <h2 id="name-reconhecimentos">
       </h2>
 <p id="section-8-1">Agradecemos a todos que estabeleceram as bases para o compartilhamento seguro e seguro de dados por meio da forma&#231;&#227;o do Grupo de Trabalho FAPI da OpenID Foundation, o GT de Seguran&#231;a do Open Banking Brasil e aos pioneiros que ficar&#227;o em seus ombros.<a href="#section-8-1" class="pilcrow">¶</a></p>
 <p id="section-8-2">As seguintes pessoas contribu&#237;ram para este documento:<a href="#section-8-2" class="pilcrow">¶</a></p>
-<ul>
-<li id="section-8-3.1">
-          <p id="section-8-3.1.1">Ralph Bragg (Raidiam)<a href="#section-8-3.1.1" class="pilcrow">¶</a></p>
+<ul class="compact">
+<li class="compact" id="section-8-3.1">Alexandre Siqueira (Mercado Pago)<a href="#section-8-3.1" class="pilcrow">¶</a>
+</li>
+        <li class="compact" id="section-8-3.2">Joseph Heenan (Authlete)<a href="#section-8-3.2" class="pilcrow">¶</a>
 </li>
-<li id="section-8-3.2">
-          <p id="section-8-3.2.1">Joseph Heenan (Authlete)<a href="#section-8-3.2.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-8-3.3">Marcos Rodrigues (Ita&#250;)<a href="#section-8-3.3" class="pilcrow">¶</a>
 </li>
-<li id="section-8-3.3">
-          <p id="section-8-3.3.1">Alexandre Siqueira (Mercado Pago)<a href="#section-8-3.3.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-8-3.4">M&#225;rio Ginglass (BNDES)<a href="#section-8-3.4" class="pilcrow">¶</a>
 </li>
-<li id="section-8-3.4">
-          <p id="section-8-3.4.1">Marcos Rodrigues (Ita&#250;)<a href="#section-8-3.4.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-8-3.5">Nic Marcondes (Quanto)<a href="#section-8-3.5" class="pilcrow">¶</a>
 </li>
-<li id="section-8-3.5">
-          <p id="section-8-3.5.1">M&#225;rio Ginglass (BNDES)<a href="#section-8-3.5.1" class="pilcrow">¶</a></p>
+        <li class="compact" id="section-8-3.6">Ralph Bragg (Raidiam)<a href="#section-8-3.6" class="pilcrow">¶</a>
 </li>
-</ul>
+      </ul>
 </section>
 </div>
 <div id="disclaimer">
-<section id="section-appendix.a">
+<section id="appendix-A">
       <h2 id="name-avisos">
-<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-avisos" class="section-name selfRef">Avisos</a>
+<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-avisos" class="section-name selfRef">Avisos</a>
       </h2>
-<p id="section-appendix.a-1">Copyright (c) 2021 Estrutura Inicial do Open Banking Brasil<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
-<p id="section-appendix.a-2">A Estrutura Inicial do Open Banking Brasil (EIOBB) concede a qualquer Colaborador, desenvolvedor, implementador ou outra parte interessada uma licen&#231;a de direitos autorais mundial n&#227;o exclusiva, livre de royalties para reproduzir, preparar trabalhos derivados, distribuir, executar e exibir, estes Implementadores Rascunho ou Especifica&#231;&#227;o Final exclusivamente para fins de (i) desenvolver especifica&#231;&#245;es e (ii) implementar Rascunhos de Implementadores e Especifica&#231;&#245;es Finais com base em tais documentos, desde que a atribui&#231;&#227;o seja feita ao EIOBB como a fonte do material, mas que tal atribui&#231;&#227;o o fa&#231;a n&#227;o indica endosso do EIOBB.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
-<p id="section-appendix.a-3">A tecnologia descrita nesta especifica&#231;&#227;o foi disponibilizada a partir de contribui&#231;&#245;es de v&#225;rias fontes, incluindo membros da OpenID Foundation, do Grupo de Trabalho de Seguran&#231;a do Open Banking Brasil e outros. Embora a Estrutura Inicial do Open Banking Brasil tenha tomado medidas para ajudar a garantir que a tecnologia esteja dispon&#237;vel para distribui&#231;&#227;o, ela n&#227;o toma posi&#231;&#227;o quanto &#224; validade ou escopo de qualquer propriedade intelectual ou outros direitos que possam ser reivindicados como pertencentes &#224; implementa&#231;&#227;o ou uso do tecnologia descrita nesta especifica&#231;&#227;o ou at&#233; que ponto qualquer licen&#231;a sob tais direitos pode ou n&#227;o estar dispon&#237;vel; nem representa que fez qualquer esfor&#231;o independente para identificar tais direitos. A Estrutura Inicial do Open Banking Brasil e os contribuidores desta especifica&#231;&#227;o n&#227;o oferecem (e por meio deste expressamente se isentam de quaisquer) garantias (expressas, impl&#237;citas ou de outra forma), incluindo garantias impl&#237;citas de comercializa&#231;&#227;o, n&#227;o viola&#231;&#227;o, adequa&#231;&#227;o a uma finalidade espec&#237;fica ou t&#237;tulo, relacionados a esta especifica&#231;&#227;o, e todo o risco quanto &#224; implementa&#231;&#227;o desta especifica&#231;&#227;o &#233; assumido pelo implementador. A pol&#237;tica de Direitos de Propriedade Intelectual do Open Banking Brasil exige que os contribuidores ofere&#231;am uma promessa de patente de n&#227;o fazer valer certas reivindica&#231;&#245;es de patentes contra outros contribuidores e implementadores. A Estrutura Inicial do Open Banking Brasil convida qualquer parte interessada a trazer &#224; sua aten&#231;&#227;o quaisquer direitos autorais, patentes, pedidos de patentes ou outros direitos de propriedade que possam abranger a tecnologia que possa ser necess&#225;ria para praticar esta especifica&#231;&#227;o.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
+<p id="appendix-A-1">Copyright (c) 2022 Estrutura Inicial do Open Banking Brasil<a href="#appendix-A-1" class="pilcrow">¶</a></p>
+<p id="appendix-A-2">A Estrutura Inicial do Open Banking Brasil (EIOBB) concede a qualquer Colaborador, desenvolvedor, implementador ou outra parte interessada uma licen&#231;a de direitos autorais mundial n&#227;o exclusiva, livre de royalties para reproduzir, preparar trabalhos derivados, distribuir, executar e exibir, estes Implementadores Rascunho ou Especifica&#231;&#227;o Final exclusivamente para fins de (i) desenvolver especifica&#231;&#245;es e (ii) implementar Rascunhos de Implementadores e Especifica&#231;&#245;es Finais com base em tais documentos, desde que a atribui&#231;&#227;o seja feita ao EIOBB como a fonte do material, mas que tal atribui&#231;&#227;o o fa&#231;a n&#227;o indica endosso do EIOBB.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
+<p id="appendix-A-3">A tecnologia descrita nesta especifica&#231;&#227;o foi disponibilizada a partir de contribui&#231;&#245;es de v&#225;rias fontes, incluindo membros da OpenID Foundation, do Grupo de Trabalho de Seguran&#231;a do Open Banking Brasil e outros. Embora a Estrutura Inicial do Open Banking Brasil tenha tomado medidas para ajudar a garantir que a tecnologia esteja dispon&#237;vel para distribui&#231;&#227;o, ela n&#227;o toma posi&#231;&#227;o quanto &#224; validade ou escopo de qualquer propriedade intelectual ou outros direitos que possam ser reivindicados como pertencentes &#224; implementa&#231;&#227;o ou uso do tecnologia descrita nesta especifica&#231;&#227;o ou at&#233; que ponto qualquer licen&#231;a sob tais direitos pode ou n&#227;o estar dispon&#237;vel; nem representa que fez qualquer esfor&#231;o independente para identificar tais direitos. A Estrutura Inicial do Open Banking Brasil e os contribuidores desta especifica&#231;&#227;o n&#227;o oferecem (e por meio deste expressamente se isentam de quaisquer) garantias (expressas, impl&#237;citas ou de outra forma), incluindo garantias impl&#237;citas de comercializa&#231;&#227;o, n&#227;o viola&#231;&#227;o, adequa&#231;&#227;o a uma finalidade espec&#237;fica ou t&#237;tulo, relacionados a esta especifica&#231;&#227;o, e todo o risco quanto &#224; implementa&#231;&#227;o desta especifica&#231;&#227;o &#233; assumido pelo implementador. A pol&#237;tica de Direitos de Propriedade Intelectual do Open Banking Brasil exige que os contribuidores ofere&#231;am uma promessa de patente de n&#227;o fazer valer certas reivindica&#231;&#245;es de patentes contra outros contribuidores e implementadores. A Estrutura Inicial do Open Banking Brasil convida qualquer parte interessada a trazer &#224; sua aten&#231;&#227;o quaisquer direitos autorais, patentes, pedidos de patentes ou outros direitos de propriedade que possam abranger a tecnologia que possa ser necess&#225;ria para praticar esta especifica&#231;&#227;o.<a href="#appendix-A-3" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="authors-addresses">
-<section id="section-appendix.b">
-      <h2 id="name-authors-addresses">
-<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
+<section id="appendix-B">
+      <h2 id="name-authors-address">
+<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
       </h2>
-<address class="vcard">
-        <div dir="auto" class="left"><span class="fn nameRole">Ralph Bragg</span></div>
-<div dir="auto" class="left"><span class="org">Raidiam</span></div>
-<div class="email">
-<span>Email:</span>
-<a href="mailto:ralph.bragg@raidiam.com" class="email">ralph.bragg@raidiam.com</a>
-</div>
-<div class="url">
-<span>URI:</span>
-<a href="https://www.raidiam.com/" class="url">https://www.raidiam.com/</a>
-</div>
-</address>
 <address class="vcard">
         <div dir="auto" class="left"><span class="fn nameRole">OBBIS GT Security</span></div>
 <div dir="auto" class="left"><span class="org">Open Banking Brasil Initial Structure</span></div>
diff --git a/open-banking-brasil-financial-api-1_ID3-ptbr.md b/open-banking-brasil-financial-api-1_ID3-ptbr.md
index 6a8f80b..304cdac 100644
--- a/open-banking-brasil-financial-api-1_ID3-ptbr.md
+++ b/open-banking-brasil-financial-api-1_ID3-ptbr.md
@@ -17,16 +17,6 @@
     status = "standard"
     value = "open-banking-brasil-financial-api-1_ID3-ptbr"
 
-    [[author]]
-    initials = "R."
-    surname = "Bragg"
-    fullname = "Ralph Bragg"
-    organization = "Raidiam"
-    abbrev = "Raidiam"
-      [author.address]
-      email = "ralph.bragg@raidiam.com"
-      uri = "https://www.raidiam.com/"
-
     [[author]]
     initials = "GT"
     surname = "Security"
@@ -162,25 +152,16 @@ Para efeitos deste documento, os termos definidos em [RFC6749], [RFC6750], [RFC7
 
 # Símbolos e termos abreviados  {#terms}
 
-**API** - Application Programming Interface (Interface de programação de aplicativo)
-
-**EIOBB** - Estrutura Inicial do Open Banking Brasil
-
-**CSRF** - Cross Site Request Forgery
-
-**DCR** - Registro de cliente dinâmico
-
-**FAPI** - Financial-grade API
-
-**HTTP** - Protocolo de transferência de hipertexto
-
-**OIDF** - OpenID Foundation
-
-**REST** - Representational State Transfer (Transferência de Estado Representacional)
-
-**TLS** - Transport Layer Security (Segurança da Camada de Transporte)
-
-**MFA** - Multi-Factor Authentication (Autenticação por Múltiplos Fatores)
+* **API** - Application Programming Interface (Interface de programação de aplicativo)
+* **CSRF** - Cross Site Request Forgery
+* **DCR** - Registro de cliente dinâmico
+* **EIOBB** - Estrutura Inicial do Open Banking Brasil
+* **FAPI** - Financial-grade API
+* **HTTP** - Protocolo de transferência de hipertexto
+* **MFA** - Multi-Factor Authentication (Autenticação por Múltiplos Fatores)
+* **OIDF** - OpenID Foundation
+* **REST** - Representational State Transfer (Transferência de Estado Representacional)
+* **TLS** - Transport Layer Security (Segurança da Camada de Transporte)
 
 # Profile de Segurança para o Open Banking Brasil {#securityprofile}
 
@@ -433,17 +414,18 @@ Agradecemos a todos que estabeleceram as bases para o compartilhamento seguro e
 
 As seguintes pessoas contribuíram para este documento:
 
-* Ralph Bragg (Raidiam)
-* Joseph Heenan (Authlete)
 * Alexandre Siqueira (Mercado Pago)
+* Joseph Heenan (Authlete)
 * Marcos Rodrigues (Itaú)
 * Mário Ginglass (BNDES)
+* Nic Marcondes (Quanto)
+* Ralph Bragg (Raidiam)
 
 {backmatter}
 
 # Avisos  {#disclaimer}
 
-Copyright (c) 2021 Estrutura Inicial do Open Banking Brasil
+Copyright (c) 2022 Estrutura Inicial do Open Banking Brasil
 
 A Estrutura Inicial do Open Banking Brasil (EIOBB) concede a qualquer Colaborador, desenvolvedor, implementador ou outra parte interessada uma licença de direitos autorais mundial não exclusiva, livre de royalties para reproduzir, preparar trabalhos derivados, distribuir, executar e exibir, estes Implementadores Rascunho ou Especificação Final exclusivamente para fins de (i) desenvolver especificações e (ii) implementar Rascunhos de Implementadores e Especificações Finais com base em tais documentos, desde que a atribuição seja feita ao EIOBB como a fonte do material, mas que tal atribuição o faça não indica endosso do EIOBB.
 

From 9b5c7509389eddb4fd6ee98b211a5377a9bd95d2 Mon Sep 17 00:00:00 2001
From: Nic <qbitnic@gmail.com>
Date: Thu, 17 Feb 2022 22:17:16 -0300
Subject: [PATCH 56/59] chore(export): fix the guide of .md to .html export

---
 README.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/README.md b/README.md
index 5201f7c..27f3a9f 100644
--- a/README.md
+++ b/README.md
@@ -36,13 +36,13 @@ Sempre que for publicado um novo ID de documentação, deve-se atentar a atualiz
 |Perfil de Segurança do OpenBanking Brasil|<ul><li>Registro e Cadastramento Dinâmico do Cliente de APIs</li><li>Padrão de Certificados Open Banking Brasil</li><li>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)</li><li>Áerea do Desenvolvedor do Portal do Open Banking Brasil</li></ul>|
 |Padrão de Certificados Open Banking Brasil|<ul><li>Perfil de Segurança do OpenBanking Brasil</li><li>Registro e Cadastramento Dinâmico do Cliente de APIs</li><li>Guia do usuário - ponto de vista da instituição receptora de dados ou iniciadora de pagamentos (TTP)</li><li>Áerea do Desenvolvedor do Portal do Open Banking Brasil</li></ul>|
 
-## Documentation Generation for Maintainers
+## Geração de documentação para manutenção
 
-The formal specifications are created using guidelines, processes and tools created by the IETF and the OIDF which ensures consistency and familiarity for implementers. All references to the specifications should be to the normative version of the published specification published in HTML version. Linking to actively developed versions of MarkDown files directly should be avoided.
+As especificações formais são criadas usando diretrizes, processos e ferramentas criadas pela IETF e pela OIDF, o que garante consistência e familiaridade para os implementadores. Todas as referências às especificações devem ser para a versão normativa da especificação publicada publicada na versão HTML. A vinculação direta a versões de arquivos MarkDown desenvolvidas ativamente deve ser evitada.
 
-The following steps can be used to generate the html version of the markdown files
+Siga os seguintes passos para gerar a versão HTML à partir dos arquivos markdown
+```shell
+makerfc='docker run -v `pwd`:/data upnic/makerfc'
 
-1. docker run -v `pwd`:/data danielfett/markdown2rfc open-banking-brasil-dynamic-client-registration-1_ID1.md
-2. find and replace '&amp;' with '&' in all html files
-3. find and replace '&lt;' with '<' in all html files
-4. find and replace '&gt;' with '>' in all html files
+makerfc open-banking-brasil-dynamic-client-registration-1_ID1.md
+```

From 2e02f5c30fb407c48454c0cdec8d4d10772e3745 Mon Sep 17 00:00:00 2001
From: Nic <qbitnic@gmail.com>
Date: Fri, 18 Feb 2022 09:49:40 -0300
Subject: [PATCH 57/59] chore(md): Fix and export
 open-banking-brasil-certificate-standards-1_ID1.md

---
 open-banking-brasil-certificate-standards-1_ID1.html | 8 ++++----
 open-banking-brasil-certificate-standards-1_ID1.md   | 8 ++++----
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/open-banking-brasil-certificate-standards-1_ID1.html b/open-banking-brasil-certificate-standards-1_ID1.html
index 5ddb384..c1ac606 100644
--- a/open-banking-brasil-certificate-standards-1_ID1.html
+++ b/open-banking-brasil-certificate-standards-1_ID1.html
@@ -1659,10 +1659,10 @@ <h3 id="name-configuration-template-for-s">
 keyUsage = critical,digitalSignature,nonRepudiation
 
 [ alt_name ]
-otherName.0 = 2.16.76.1.3.2;UTF8:&lt;Name of the person responsible for the organization&gt;
-otherName.1 = 2.16.76.1.3.3;UTF8:&lt;CNPJ&gt;
-otherName.2 = 2.16.76.1.3.4;UTF8:&lt;CPF/PIS/RF of responsible person&gt;
-otherName.3 = 2.16.76.1.3.7;UTF8:&lt;INSS Number&gt;
+otherName.0 = 2.16.76.1.3.2;PRINTABLESTRING:&lt;Name of the person responsible for the organization&gt;
+otherName.1 = 2.16.76.1.3.3;PRINTABLESTRING:&lt;CNPJ&gt;
+otherName.2 = 2.16.76.1.3.4;PRINTABLESTRING:&lt;CPF/PIS/RF of responsible person&gt;
+otherName.3 = 2.16.76.1.3.7;PRINTABLESTRING:&lt;INSS Number&gt;
 </pre><a href="#section-8.2-1" class="pilcrow">¶</a>
 </div>
 </section>
diff --git a/open-banking-brasil-certificate-standards-1_ID1.md b/open-banking-brasil-certificate-standards-1_ID1.md
index 9db4b1d..3534df9 100644
--- a/open-banking-brasil-certificate-standards-1_ID1.md
+++ b/open-banking-brasil-certificate-standards-1_ID1.md
@@ -301,10 +301,10 @@ subjectAltName = @alt_name
 keyUsage = critical,digitalSignature,nonRepudiation
 
 [ alt_name ]
-otherName.0 = 2.16.76.1.3.2;UTF8:<Name of the person responsible for the organization>
-otherName.1 = 2.16.76.1.3.3;UTF8:<CNPJ>
-otherName.2 = 2.16.76.1.3.4;UTF8:<CPF/PIS/RF of responsible person>
-otherName.3 = 2.16.76.1.3.7;UTF8:<INSS Number>
+otherName.0 = 2.16.76.1.3.2;PRINTABLESTRING:<Name of the person responsible for the organization>
+otherName.1 = 2.16.76.1.3.3;PRINTABLESTRING:<CNPJ>
+otherName.2 = 2.16.76.1.3.4;PRINTABLESTRING:<CPF/PIS/RF of responsible person>
+otherName.3 = 2.16.76.1.3.7;PRINTABLESTRING:<INSS Number>
 ```
 
 ## Endpoints vs Certificate type and mTLS requirements

From 5c08e4eb1cd5ab0583eb895f30f2835c27454727 Mon Sep 17 00:00:00 2001
From: llfreitas <104649601+llfreitas@users.noreply.github.com>
Date: Mon, 25 Jul 2022 09:30:47 -0300
Subject: [PATCH 58/59] Update
 open-banking-brasil-certificate-standards-1_ID1-ptbr.md

---
 open-banking-brasil-certificate-standards-1_ID1-ptbr.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/open-banking-brasil-certificate-standards-1_ID1-ptbr.md b/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
index e8c3b1d..7c6b84d 100644
--- a/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
+++ b/open-banking-brasil-certificate-standards-1_ID1-ptbr.md
@@ -73,7 +73,7 @@ Os seguintes documentos referenciados são indispensáveis para a aplicação de
 * [BCP195] - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]: <https://tools.ietf.org/html/bcp195>
 * [RFC8705] - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens [RFC8705]: <https://tools.ietf.org/html/rfc8705>
 * [OBB-FAPI] - Open Banking Brasil Financial-grade API Security Profile 1.0 [OBB-FAPI]: <https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html>
-* [OBB-FAPI-DCR] - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0 [OBB-FAPI-DCR]: <https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html
+* [OBB-FAPI-DCR] - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0 [OBB-FAPI-DCR]: <https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html>
 * [DOC-ICP-01] - DECLARAÇÃO DE PRÁTICAS DE CERTIFICAÇÃO DA AUTORIDADE CERTIFICADORA RAIZ DA ICP-BRASIL: <https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf>
 * [RFC6749] - The OAuth 2.0 Authorization Framework [RFC6749]: <https://tools.ietf.org/html/rfc6749>
 * [BCB-IN134] - Manual de Segurança do Open Banking: <https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364>

From abe817ad2d57ee9c32b988769d85c6a0af0c3341 Mon Sep 17 00:00:00 2001
From: llfreitas <104649601+llfreitas@users.noreply.github.com>
Date: Mon, 25 Jul 2022 09:31:16 -0300
Subject: [PATCH 59/59] Update
 open-banking-brasil-certificate-standards-1_ID1.md

---
 open-banking-brasil-certificate-standards-1_ID1.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/open-banking-brasil-certificate-standards-1_ID1.md b/open-banking-brasil-certificate-standards-1_ID1.md
index 3534df9..10f06ba 100644
--- a/open-banking-brasil-certificate-standards-1_ID1.md
+++ b/open-banking-brasil-certificate-standards-1_ID1.md
@@ -75,7 +75,7 @@ The following referenced documents are indispensable for the application of this
 * [BCP195] - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]: <https://tools.ietf.org/html/bcp195>
 * [RFC8705] - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens [RFC8705]: <https://tools.ietf.org/html/rfc8705>
 * [OBB-FAPI] - Open Banking Brasil Financial-grade API Security Profile 1.0 [OBB-FAPI]: <https://github.com/OpenBanking-Brasil/specs-seguranca/open-banking-brasil-financial-api-1_ID3.html>
-* [OBB-FAPI-DCR] - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0 [OBB-FAPI-DCR]: <https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html
+* [OBB-FAPI-DCR] - Open Banking Brasil Financial-grade API Dynamic Client Registration Profile 1.0 [OBB-FAPI-DCR]: <https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html>
 * [DOC-ICP-01] - DECLARAÇÃO DE PRÁTICAS DE CERTIFICAÇÃO DA AUTORIDADE CERTIFICADORA RAIZ DA ICP-BRASIL: <https://www.gov.br/iti/pt-br/centrais-de-conteudo/doc-icp-01-v-5-2-dpc-da-ac-raiz-da-icp-brasil-pdf>
 * [RFC6749] - The OAuth 2.0 Authorization Framework [RFC6749]: <https://tools.ietf.org/html/rfc6749>
 * [BCB-IN134] - Manual de Segurança do Open Banking: <https://www.in.gov.br/web/dou/-/instrucao-normativa-bcb-n-134-de-22-de-julho-de-2021-3345585364>