CIBA: Request expiration time

README.md

@@ -26,13 +26,23 @@ 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)
 
-## Documentation Generation for Maintainers
+## Manutenção dos links
 
-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.
+Sempre que for publicado um novo ID de documentação, deve-se atentar a atualização dos links nos seguintes locais:
 
-The following steps can be used to generate the html version of the markdown files
+|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><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>|
 
-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
+## Geração de documentação para manutenção
+
+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.
+
+Siga os seguintes passos para gerar a versão HTML à partir dos arquivos markdown
+```shell
+makerfc='docker run -v `pwd`:/data upnic/makerfc'
+
+makerfc open-banking-brasil-dynamic-client-registration-1_ID1.md
+```

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}
 

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
 

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)