v1.6

1. Introdução

Informações de contato e URIs.

1.1. Contato

Em caso de dúvidas ou dificuldades na integração você pode entrar em contato conosco abrindo um chamado em: https://valid-sa.atlassian.net/servicedesk/customer/portal/4/group/115/create/51 ou pelo email produtos.certificadora@valid.com.

Inclua em seu email os dados abaixo:

1.1. URIs base do Valid PSC

Produção: https://certificado.vidaas.com.br

Homologação: https://hml-certificado.vidaas.com.br

2. Cadastro de Aplicação

Para utilizar os serviços de autorização e assinatura é obrigatório cadastrar sua aplicação junto ao Valid PSC, este serviço para cadastro é realizado uma única vez. Abaixo a descrição do serviço para cadastro de aplicação. Para obtenção de autorização e assinatura é obrigatório cadastrar sua aplicação junto ao Valid PSC, este serviço para cadastro é realizado uma única vez. Abaixo a descrição do serviço para cadastro de aplicação.

Solicitação de cadastro:

• Path : <URI-base>/v0/oauth/application

• Verbo HTTP: POST

• Cabeçalho:

  • Content-type: application/json

  • Accept: application/json

• Corpo da requisição no formato "application/json;charset=UTF-8"

  • name: obrigatório, nome/descrição da aplicação;

  • comments: obrigatório, observações gerais de uso da aplicação;

  • redirect_uris: obrigatório, URI’s autorizadas para redirecionamento (para serviços de código de autorização);

  • email: obrigatório, e-mail para suporte em caso de indisponibilidade, mudança de versão, entre outros.

Exemplo de requisição:

{    
    "name": "App Demo",    
    "comments": "App Demo Observação",    
    "redirect_uris": ["https://valid.com.br"],    
    "email": "demo@valid.com"
}

Exemplo de resposta:

{    
   "status": "success",    
   "message": "New Client Application registered with Sucess",    
   "client_id": "4c9fb552-0387-4e5f-8727-6676fa88dce1",    
   "client_secret": "Ny2n3hq67gQEFvH7"
}

Observação:

Os parâmetros de retorno “client_id” e “client_secret” devem ser armazenadas na sua aplicação que serão parâmetros nas chamadas de outros serviços para autorização e assinatura.

O parâmetro “redirect_uris“ é utilizado para armazenar todas as URIs que poderão ser utilizadas posteriormente pela aplicação no redirecionamento do usuário após a assinatura ser realizada.

3. Uso da API

Os próximos tópicos descrevem como utilizar a API para realizar autenticações e assinaturas digitais.

3.1. Autorização e Autenticação

Serviço para obter do titular a autorização de uso da sua chave privada, com solicitação de fatores de autenticação através de QR Code ou notificação enviada para o celular do titular (Push).

Em ambos os casos, o usuário digitará a senha de seu certificado e se a senha for digitada corretamente, a sua aplicação receberá a autorização de acordo com o escopo solicitado.

Recomendamos que implemente os dois médotos (QR Code e Notificação) na sua aplicação, permitindo que o próprio usuário escolha o método de autenticação. Isso melhora a experiência do usuário e aumenta a disponibilidade do serviço.

3.1.1. Solicitação de autorização por QR Code

Através de um link, uma página com QR Code é disponibilizada para que o usuário faça a autorização. Após realizada essa autorização, a página redireciona para a uri pré-definida.

A página com o QR Code ficará aguardando por 2 minutos o titular da chave privada autenticar com o aplicativo ViDaas.

a) Jornada do usuário autorizando o uso da chave privada via leitura de QR Code no app Vidaas

b) Resposta da Requisição de Código de Autorização (Receive Code)

Ao autorizar o uso pelo titular, o Valid PSC emite um código de autorização com tempo de validade curto e retorna para aplicação cliente com uma URI de redirecionamento contendo parâmetros no componente http query, usando o formato "application/x-www- form-urlencoded":

Caso o titular não autorize o uso, o Valid PSC aguardará o tempo de expiração do QRCODE e irá exibir a mensagem conforme imagem abaixo:

c) Endpoint

Abaixo os parâmetros necessários para utilização deste método:

Path : <URI-base>/v0/oauth/authorize

• Verbo HTTP: GET

• Parâmetros da requisição no formato "Query Params"

  • client_id: obrigatório, deve conter a identificação da aplicação;

  • code_challenge: obrigatório, ver RFC 7636. Utilizado para assegurar integridade com a solicitação da autorização e com a geração do access_token que será visto adiante. Utiliza OAuth com PKCE para geração do par code challenge e code verifier. Caso precise, fazendo uma busca na internet, pode-se encontrar geradores online dessas chaves;

  • code_challenge_method: obrigatório, valor “S256” (ver RFC 7636);

  • response_type: obrigatório, valor "code".

  • scope: opcional, se não informado será considerado "single_signature" (preferencialmente deve ser informado o tipo do escopo desejado porque o valor padrão pode mudar). Possíveis valores para o parâmetro:

    • single_signature: token que permite a assinatura de apenas um conteúdo (hash), sendo invalidado após a sua utilização;

    • multi_signature: token que permite a assinatura de multiplos hashes em uma única requisição, sendo invalidado após a sua utilização;

    • signature_session: token de sessão OAuth que permite várias assinaturas em várias chamadas a API, desde que o token esteja dentro do prazo de validade ou que não tenha sido revogado pela aplicação ou pelo usuário.

    • authentication_session: token de sessão oAuth apenas para autenticação e que não permite uso da chave privada do usuário.

  • login_hint: deixar em branco.

  • lifetime: opcional, indica o tempo de vida desejado para o token a ser gerado. Inteiro, em segundos. O valor máximo varia com o tipo de certificado:

    • Pessoa Física: até 7 dias;

    • Pessoa Jurídica: até 30 dias;

      • Nota: Neste caso é importante conhecer a rotina do seu usuário. Alguns parceiros utilizam esse parâmetro de forma em que o usuário final escolhe por quanto tempo poderá ficar sem precisar inserir a senha novamente.

      • Sugestão: A duração da sessão pode ser implementada de acordo com a rotina do usuário, por exemplo, um médico que realiza um plantão de doze horas deveria ter uma sessão de 43200 s.

  • redirect_uri: obrigatório, deve conter uma uri informada anteriormente na criação da aplicação.

  • state: opcional.

Exemplo de requisição:

PATH_BASE/oauth/authorize?client_id=4c9fb552-0387-4e5f-8727-6676fa88dce1&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256&response_type=code&scope=signature_session&login_hint=12345678901&lifetime=900&redirect_uri=http://valid.com.br

Exemplo de resposta:

<REDIRECT_URI>?code=eyJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiYWxnIjoiZGlyIn0..eELj_2mmWoulp2GebJcc0g.dHvIy9cz0k8ytJbE-vC4gv0ZI-R8CaB_-KlEUj-u-yt3IMNoGJDSpGPaxz0SPjICK_MMm72B06uQvQlJijBbMzSrWA0XM7YLpdCazwP7SWxhCQdQzRiuLXawdv8guFqA9iwYtOqhNNDzHvcxNSvds3mskERHaUEl2hyZkMdZH31o29gWmHRzi7AFsTgDXMjJ.c6kHZoweiW_Zz9cKfIO4DA&state=NONE

3.1.2. Solicitação por notificação no celular (Push)

Nesse método, o signatário receberá uma notificação em seu celular, solicitando a assinatura pelo aplicativo VIDaaS:

a) Jornada do usuário: Usuário fornecendo a autorização através da notificação

b) Endpoint

• Path : <URI-base>/v0/oauth/authorize

• Verbo HTTP: GET

• Parâmetros da requisição no formato "Query Params"

  • client_id: obrigatório, deve conter a identificação da aplicação;

  • code_challenge: obrigatório, ver RFC 7636. Utilizado para assegurar integridade com a solicitação da autorização e com a geração do access_token que será visto adiante. Utiliza OAuth com PKCE para geração do par code challenge e code verifier. Caso precise, fazendo uma busca na internet, pode-se encontrar geradores online dessas chaves;

  • code_challenge_method: obrigatório, valor “S256” (ver RFC 7636);

  • response_type: obrigatório, valor "code".

  • scope: opcional, se não informado, será considerado "single_signature" (preferencialmente deve ser informado o tipo do escopo desejado porque o valor padrão pode mudar). Possíveis valores para o parâmetro:

    • single_signature: token que permite a assinatura de apenas um conteúdo (hash), sendo invalidado após a sua utilização;

    • multi_signature: token que permite a assinatura de multiplos hashes em uma única requisição, sendo invalidado após a sua utilização;

    • signature_session: token de sessão OAuth que permite várias assinaturas em várias chamadas a API, desde que o token esteja dentro do prazo de validade ou que não tenha sido revogado pela aplicação ou pelo usuário;

    • authentication_session: token de sessão oAuth apenas para autenticação e que não permite uso da chave privada do usuário.

  • login_hint: obrigatório, informar CPF ou CNPJ do titular a que se destina a requisição.

  • lifetime: opcional, indica o tempo de vida desejado para o token a ser gerado. Inteiro, em segundos;

  • redirect_uri: informar apenas o valor “push://” no parâmetro.

Exemplo de requisição:

PATH_BASE/oauth/authorize?client_id=4c9fb552-0387-4e5f-8727-6676fa88dce1&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256&response_type=code&scope=signature_session&login_hint=12345678901&lifetime=900&redirect_uri=push://             

Exemplo de resposta com PUSH:

code=d402d71c-0918-43ca-a07d-62597f559497

c) Importante! Realizando uma autenticação através do “authentications” ao solicitar autorização por push

Esse método deve ser utilizado somente para casos de solicitação por notificação (Push) e permite saber se o titular realizou a “assinatura” que lhe foi solicitada.

Por se tratar de uma operação assíncrona, esse método deve ser chamado recorrentemente até que retorne o conteúdo com o “autorizationToken”.

Importante informar que a “recorrência“ deve ocorrer “com intervalo de tempo de no mínimo 1 segundo“. Chamadas menores do que esse intervalo estarão sujeitas ao bloqueio da aplicação.

• Path : <URI-base>/valid/api/v1/trusted-services/authentications

• Verbo HTTP: GET

• Parâmetros da requisição no formato "Query Params"
  ◦  code: obrigatório, deve conter código retornado pelo método authorize

Exemplo de solicitação de status da autenticação:

<URI-base>/valid/api/v1/trusted-services/authentications?code=d402d71c-0918-43ca-a07d-62597f559497

Exemplo de resposta:

{
    "authorizationToken": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiYWxnIjoiZGlyIn0..nYWhIcwNUH_22Upe1BSUTQ.oXT7UF2Mvtm5C6CjpdEGxcL_9XM86oNh4w0iGgUkQVGBla0CNnNW0_QbGx73Ldnu81kydOuztSj3wfWUQf3t7IftvVMuyfdi-gW4_lz1LcC2q3p9N32iSEGb5VPzzSKqiZGa3asfMgEPjr3xYo7Lo3biTtbVPrChPLHslMi--b7DXXOIZ23N2R5bCT2_h6pj6PyBnXsEWl5uaF9v5PSXsQ.ZuLdlRZkfGBoqrxbj5tgTg",
    "redirectUrl": "push://<URI gerada no cadastro de aplicação>?code=8b1bde77-3647-4d76-1289-a2ec97c75a4d&state=NONE"
}

3.1.3 Obter a chave para autenticação de documentos com o “token”

Retorna o “access_token”.

• Path : <URI-base>/v0/oauth/token

• Verbo HTTP: POST

• Parâmetros da requisição no formato "application/x-www-form-urlencoded"

  • grant_type: obrigatório, valor "authorization_code";

  • client_id: obrigatório, deve conter a identificação da aplicação;

  • client_secret: obrigatório, deve conter o segredo associado à aplicação;

  • code_verifier: obrigatório, informar a chave que corresponde ao code_challenge enviado na Requisição de Código de Autorização (ver RFC 7636).

  • code: obrigatório, deve conter código de autorização retornado do Serviço Código de Autorização;

Observações:

1. Para o método Authorize QR Code deve-se alterar o campo "code" pelo "code" retornado.

2. Para o método Authorize PUSH deve-se alterar o campo "code" pelo "authorizationToken" retornado no Authentications.

Exemplo de requisição:

{
    "grant_type": "authorization_code",
    "client_id": "4c9fb552-0387-4e5f-8727-6676fa88dce1",
    "client_secret": Ny2n3hq67gQEFvH7,
    "code": "<authorization code>",
    "code_verifier": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
}

Exemplo de resposta:

{
    "access_token": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiYWxnIjoiZGlyIn0..2tk9rh8yisesxBm1tNNcUg.z6VZu-HZJk-a9EDBSAgDrtZWgYn5je__nCc6uOOrl3wsCrzWT5G0SMUHpuX3McdBk0uIJ85cMOe3MFn75Pe5mfhlmdLtRUtnX_tJmg8rW6dU7mg4nR4XlyMmWYy-Yep_2dIM2xni0sWUplPxUCLg9dl7_aeVTB_U9TmsXOYCJNMYSJfjPErsthUNHWJHzUIOg-2Otj9gkq_EBLr0jYVWCw.IPOs5b_o6yKmz2Q24zYYvA",
    "token_type": "Bearer",
    "expires_in": 900,
    "scope": "signature_session",
    "authorized_identification": "12345678901",
    "authorized_identification_type": "CPF"
}

3.2. Assinaturas digitais em documentos com o “Signature”

Utilizado para realizar assinaturas digitais em documentos de no máximo 7 MB.

• Path: <URI-base>/v0/oauth/signature

• Verbo HTTP: POST

• Parâmetros da requisição no formato "raw"

  • Content-type: application/json;

  • Accept : application/json;

  • Authorization: Bearer access_token (obtido anteriormente);

    • Parâmetros: formato "application/json;charset=UTF-8" :

      • certificate_alias: opcional, identificador do certificado correspondente à chave utilizada na assinatura.

      • hashes: conjunto com valores referentes a documentos a serem assinados. Cada elemento do conjunto conterá:

        • id: identificador do conteúdo a ser assinado;

        • alias: forma legível do identificador do conteúdo;

        • hash: conteúdo a ser assinado, deve ser convertido inicialmente em SHA256 e posteriormente em base64;

        • hash_algorithm: Object Identifier (OID) do algoritimo de hash. Por exemplo, para SHA256 utilize o OID 2.16.840.1.101.3.4.2.1;;

        • signature_format: formato da assinatura, por exemplo:

          • RAW: resultado direto (em base64) da operação RSA sobre o hash informado na requisição.

          • CMS: PKCS#7 detached contendo os seguintes atributos assinados:
            - contentType
            - signingTime (hora do PSC)
            - messageDigest (hash informado pela aplicação na requisição)
            - signingCertificateV2 (certificado do assinante);

        • padding_method: opcional,

        • pdf_signature_page: opcional, acrescenta página no PDF mostrando a assinatura digital, podendo ter o valor "true" ou "false", por padrão é definido o valor "false",

        • base64_content: opcional, conteúdo em base64 a ser assinado. Por exemplo Texto ou PDF a ser assinado em base64.

Observações:

1. A aplicação suporta os seguintes “signature_format”: RAW_DATA, CMS, CAdES_AD_RT, CAdES_AD_RB, PAdES_AD_RT, PAdES_AD_RB, RAW_DIGESTED_DATA.

2. A aplicação suporta os seguintes “padding_method”: NONE, PKCS1V1_5, PSS. Método usado para complementar o tamanho de 256 bytes do dado a ser assinado. O mais utilizado é o PKCS1V1_5.

Exemplo de requisição:

{	
    "hashes": [
          {
              "id": "dummy assinatura",
              "alias": "dummy.pdf",
              "hash": "FqulOTrXLABB9WAK08LFLsQ3ovDH/Aj638PA/pZB16M=",
              "hash_algorithm": "2.16.840.1.101.3.4.2.1",
              "signature_format": "RAW"
          }
    ]
}

Exemplo de resposta:

{
    "signatures": [
         {
             "id": "dummy assinatura",
             "raw_signature": "my signature base64"
         }
    ],
    "certificate_alias": "CERTIFICADO TESTE"
}

3.3 Serviço para encontrar um titular mediante informação de CPF ou CNPJ (“user-discovery”).

Antes de chamar a aplicação para autenticação, você pode verificar se um CPF ou CNPJ existe no Valid PSC e listar os certificados disponíveis para ele.

Solicitação do serviço:

• Path: <URI-base>/v0/oauth/user-discovery

• Verbo HTTP: POST

• Corpo da requisição no formato "application/json;charset=UTF-8"

  • client_id: obrigatório, deve conter a identificação da aplicação;

  • client_secret: obrigatório, deve conter o segredo associado à aplicação;

  • user_cpf_cnpj: obrigatório, deve conter “CPF” para pessoa física ou “CNPJ” pessoa jurídica;

  • val_cpf_cnpj: obrigatório, deve conter o valor do cpf ou cnpj.

Exemplo de requisição:

{    
    "client_id": "4c9fb552-0387-4e5f-8727-6676fa88dce1",    
    "client_secret": "Ny2n3hq67gQEFvH7",    
    "user_cpf_cnpj": "CPF",    
    "val_cpf_cnpj": "12345678901"
}

Exemplos de respostas:

2.1 - Status S

{
   "status": "S",  
   "slots": [      
       {         
            "slot_alias": "a4c2b5bc-ee20-492a-9908-45d892f2e808",         
            "label": "e-CPF A3 em nuvem gold"      
       },      
       {         
            "slot_alias": "8e8353d5-e786-4822-9666-603bd966ee58",         
            "label": "e-CPF A3 em nuvem gold"      
       }  
    ]
}

2.2 - Status N

{    
   "status": "N"
}

3.4 Extração da chave pública com o “Public Certificate”

Utilizado para extração da chave pública em base64 do signatário de um documento.

Para utilização dessa função deve-se utilizar o “certificate_alias” gerado no Sinature e do “access_token” gerado no endpoit Token.

• Path : <URI-base>/v0/oauth/certificate-discovery

• Verbo HTTP: GET

• Parâmetros da requisição no formato "Query Params"

◦  token (authorizathion bearer): obrigatório, deve conter código retornado do Serviço de Token.

◦  certificate_alias: obrigatório, deve conter código retornado do Serviço de Assinatura (Signature).

Exemplo de resposta:

{
    "status": "S",
    "certificates": [
        {
            "alias": "28938fd0-954d-4cff-8f69-a159b70e3d1f",
            "certificate": "-----BEGIN CERTIFICATE-----\r\nMIIHuzCCBaOgAwIBAgIINVGKh7BTogEwDQYJKoZIhvcNAQELBQAwdDELMAkGA1UE\r\nBhMCQlIxEzARBgNVBAoTCklDUC1CcmFzaWwxNjA0BgNVBAsTLVNlY3JldGFyaWEg\r\nZGEgUmVjZWl0YSBGZWRlcmFsIGRvIEJyYXNpbCAtIFJGQjEYMBYGA1UEAxMPQUMg\r\nVkFMSUQgUkZCIHY1MB4XDTIyMDcxMzE4MTI1MFoXDTI3MDcxMjE4MTI1MFowgfsx\r\nCzAJBgNVBAYTAkJSMRMwEQYDVQQKEwpJQ1AtQnJhc2lsMTYwNAYDVQQLEy1TZWNy\r\nZXRhcmlhIGRhIFJlY2VpdGEgRmVkZXJhbCBkbyBCcmFzaWwgLSBSRkIxFTATBgNV\r\nBAsTDFJGQiBlLUNQRiBBMzEOMAwGA1UECxMFVkFMSUQxFDASBgNVBAsTC0FSIFZB\r\nTElEIENEMRkwFwYDVQQLExBWaWRlb2NvbmZlcmVuY2lhMRcwFQYDVQQLEw4xNDEy\r\nMTk1NzAwMDEwOTEuMCwGA1UEAxMlTUFSQ0VMTyBERU5JUyBERSBPTElWRUlSQTox\r\nMTI3MDQ2ODg4MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALHYwp/K\r\nmYRMnOueizCFtLfeT2uiBjBXnRlIe5PNpMSQy2cfSs+6qwYP+Xg2Jis8T/UY8jZp\r\nVdMrjlkm/s9tYAbhuLA8bIwlOlq9quMFp2IR2P5C3zyJN3uH+Nq0ZXlxUVfwz0wC\r\nvLt94BnnmOIImpf7Tdwr1y3bmh9Hz86BKUElUEh9esVXMAqc4HAUVa3NjOlsiBr5\r\nmh8uUwaGO3c+5RduTKvFDMjS4YB6m1oVej7yKmGa8/mcdgk4xrMhgiwULcKquDnO\r\nzba80WSKq4UMns0JSI1tvWatvhdjWhcH5z7dDVgYexDTed/eEYEhcqyS+SwKsi2f\r\ndPc2u2kXRUmrBh8CAwEAAaOCAscwggLDMIGcBggrBgEFBQcBAQSBjzCBjDBVBggr\r\nBgEFBQcwAoZJaHR0cDovL2ljcC1icmFzaWwudmFsaWRjZXJ0aWZpY2Fkb3JhLmNv\r\nbS5ici9hYy12YWxpZHJmYi9hYy12YWxpZHJmYnY1LnA3YjAzBggrBgEFBQcwAYYn\r\naHR0cDovL29jc3B2NS52YWxpZGNlcnRpZmljYWRvcmEuY29tLmJyMAkGA1UdEwQC\r\nMAAwHwYDVR0jBBgwFoAUU8ul5HVQmUAsvlsVRcm+yzCqicUwcAYDVR0gBGkwZzBl\r\nBgZgTAECAyQwWzBZBggrBgEFBQcCARZNaHR0cDovL2ljcC1icmFzaWwudmFsaWRj\r\nZXJ0aWZpY2Fkb3JhLmNvbS5ici9hYy12YWxpZHJmYi9kcGMtYWMtdmFsaWRyZmJ2\r\nNS5wZGYwgbYGA1UdHwSBrjCBqzBToFGgT4ZNaHR0cDovL2ljcC1icmFzaWwudmFs\r\naWRjZXJ0aWZpY2Fkb3JhLmNvbS5ici9hYy12YWxpZHJmYi9sY3ItYWMtdmFsaWRy\r\nZmJ2NS5jcmwwVKBSoFCGTmh0dHA6Ly9pY3AtYnJhc2lsMi52YWxpZGNlcnRpZmlj\r\nYWRvcmEuY29tLmJyL2FjLXZhbGlkcmZiL2xjci1hYy12YWxpZHJmYnY1LmNybDAO\r\nBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIGb\r\nBgNVHREEgZMwgZCBG21hcmNlbG8uZG9saXZlaXJhQHZhbGlkLmNvbaA4BgVgTAED\r\nAaAvBC0yMDEwMTk2ODExMjcwNDY4ODgwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw\r\nMDCgFwYFYEwBAwagDgQMMDAwMDAwMDAwMDAwoB4GBWBMAQMFoBUEEzAwMDAwMDAw\r\nMDAwMDAwMDAwMDAwDQYJKoZIhvcNAQELBQADggIBAEBck43Df/MN2LI1B/HF7qlx\r\noP4p8s4fr2+hm1BIyh2O+eEvhGUSKj1YkILQrrcBtjRCbtzdJuPvj0QPh87WN/BS\r\nBvVulla8vpK/W+RsVqurjX06wF/jtR5CL8gLvG0boX716de16j+Bacu3w0TeWego\r\n1wegR9R3caUaxnIvy22N05U86xYi+Ppep32wuLepoC+VE4hBPPAARMb4Vs3eqavB\r\nUsdaoYJR8ODLZYTLds9NGEYrWrH7XCB3hgq536xX0nBdqekmfirmbRfGx44bk3Sx\r\nFycoiAoZwfXISKFxbfV6im8dZK5+vf8L8Z9MSJVwZsWU+WZ6sWY43Rj/adL5eAg0\r\npoo24Br4aBY2CZIjT8raNl35WH+8VhYcnCgQSF+Zj7Gz9PMiAKje3i4rxpQXzh3L\r\nVDmuSXMKrKRSUJEWEGknpdKi9gYO6EVR9l70qFyIrafBS/4aH4hEchpFQkgjkGrc\r\n71gSGXoirDcvX3cdQTAkuLZG4gxG8EOg4Fmu2zxUFuTcKXoA78LdRGrQ2HQ6EtYh\r\nlB8KTVkJeri1+Kx6q9OXbq7RWmuIu48h89+3t1o+pdznBq1Q5g9Etlg0PN/wmxBY\r\nMoCZ1LxmiH4G7akTOp1Roc7R/tCIowV5YYLCkzetAYD5dZdUfx3fGOxanmVgJjBX\r\nSwfACcDYtG3cz7yeP/Qs\r\n-----END CERTIFICATE-----\r\n"
        }
    ]
}

4. Observações sobre o modelo de negócios

a) O que é a licença comercial ou “Direito de uso”?

Quando um certificado A3 em nuvem é emitido, ele é criado com validade normativa de 5 anos. No entanto, comercialmente o usuário terá adquirido um período menor, de 1 ano em geral. Quando este prazo de licença comercial, ou, “Direito de uso” tiver acabado, ele poderá adquirir licenças adicionais, ampliando o direito de utilização, sem que precise realizar o processo e validação.

b) Todos os usuários podem ser bloqueados?

Não! Não são todos os usuários que podem ser bloqueados. Existe possibilidade de implementação de solução corporativa para que a renovação seja transparente ao usuário final.

c) Como o usuário saberá que não possui direito de uso ao certificado.?

Desde que seja um usuário proveniente do varejo. O usuário terá alterações visuais na interface do aplicativo, receberá notificações e email para comunicar a proximidade do vencimento do direito de uso.

Imagem 7: Fluxo de telas para a Renovação do direito de uso

5. Postman: Exemplos de chamadas aos Endpoints

Projeto Postman com as chamadas aos endpoints.