Guia do Usuário para Entidades Transmissoras de Dados

1.0 Registrando um Participante

1.1 Visão Geral do Diretório

Os serviços do framework de confiança providos pelo Open Insurance Brasil fornecem todos os serviços de descoberta necessários para que instituiçoes transmissores e receptoras interajam entre si, sem que seja preciso validar individualmente a autenticidade de cada participante.

Um Authorization Server ou AS, conforme definido por RFC 6749 - The OAuth 2.0 Authorization Framework, executa várias funções em um ecossistema de compartilhamento de dados como o Open Insurance Brasil. Antes de prosseguir, certifique-se de que os conceitos de funções e responsabilidades definidos na RFC original sejam bem compreendidos. Além disso, certifique-se de que os conceitos, funções e responsabilidades definidos no OpenID Connect Core e como eles estendem os conceitos definidos no RFC 6749 são igualmente bem compreendidos.

1.2 Registrando um Authorization Server e OpenID Provider

As seguradoras, geralmente grandes seguradoras, não serão uma entidade única do ponto de vista das operações de tecnologia. Eles podem ter marcas, segurança e infraestrutura de TI diferentes para diferentes segmentos de clientes, ou podem ter alguma infraestrutura de TI que ofereça suporte a várias marcas ou segmentos de clientes. Isso significa que o ecossistema técnico precisa ser flexível o suficiente para suportar uma ampla variedade de implantações de infraestrutura de seguradoras, garantindo que os serviços necessários possam ser descobertos por clientes de instituições receptoras que precisam interagir com ele.

Um modelo flexível para anunciar serviços de autenticação / autorização e os recursos protegidos pelo AuthN e AuthZ é suportado pelo Diretório.

• Customer Friendly Name - Será exibido aos clientes pelas instituições receptoras, e já deve ser reconhecido pelos clientes da seguradora.

• Customer Friendly Logo - Será exibido aos clientes pelos instituições receptoras para auxiliar no reconhecimento da marca.

• Description - Isso pode ser exibido aos clientes pelas instituições receptoras para auxiliar no reconhecimento da marca.

• Terms of Service - Este é um link para os Termos de Serviço da seguradora, que podem ser incluídos pelas instituições receptoras.

• Notification WebHook - Authorization Servers podem registrar um WebHook que receberá atualizações por push sobre as alterações dos participantes, seus softwares ou certificados.

• OpenID Well Known Document Uri - Link para o documento de descoberta do Authorization Server.

Uma seguradora pode optar por ter um Authorization Server ou muitos, desde que satisfaça os seguintes requisitos:

• Um cliente pode reconhecer o Authorization Server como um local com o qual normalmente faria interação com a sua seguradora.

• 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

Depois que uma seguradora registra um Authorization Server, ela precisa anunciar para quais recursos, APIs ou serviços ele pode fornecer autorização.

No exemplo acima, a Seguros Incríveis está anunciando dois serviços que devem ser reconhecidos pelos clientes. “Seguros Incríveis - Empresas" e “Seguros Incríveis". Estes podem ou não estar diretamente relacionados a “Marcas”, pois seguradoras diferentes podem precisar anunciar serviços de autenticação diferentes, mesmo dentro de uma submarca.

Além disso, a seguradora anuncia quais recursos cada um dos servidores de autorização está protegendo ou oferecendo. No exemplo acima, a Seguros Incríveis é compatível com a versão 1 e a versão 2 da API de seguros de automóveis, e o “Amazing Insurances” tem dois sistemas separados de consentimento e informações dos clientes de seguros.

Anunciar corretamente quais recursos são oferecidos por cada servidor é importante para atingir a escala prevista pelo Open Insurance Brasil, além de ser fundamental para garantir que os clientes possam identificar sua seguradora facilmente e que as instituições receptoras possam encaminhar os clientes para o Authorization Server correto com base nos recursos protegidos por cada serviço.

2.0 Validando uma Solicitação de Registro de Cliente

Usando o OpenID Connect Discovery e a especificação de Dynamic Client Registration (DCR) do Open Insurance Brasil. Uma instituição receptora pode registrar seu aplicativo em cada um dos Authorization Servers disponíveis no ecossistema.

2.1 Registro OpenID Connect e OAuth 2.0 Dynamic Client Registration

Consulte a Cláusula 7 da Especificação de Dynamic Client Registration (DCR) do Open Insurance Brasil para obter detalhes.

2.2 Processamento de declaração de software (Software Statement Assertion)

Consulte a Cláusula 8 da Especificação de Dynamic Client Registration (DCR) do Open Insurance Brasil para obter detalhes.

3.0 Validando um Pedido de Autorização

Consulte a Cláusula 5 do Perfil de Segurança do Open Finance Brasil (Financial-grade API Security Profile) para obter detalhes.