PRESIDÊNCIA DA REPÚBLICA - CASA CIVIL
SCN QUADRA 02 BLOCO E - CEP 70712-905 - Brasília/DF
Telefone: (61) 3424-3945 - hps://www.i.gov.br
INSTRUÇÃO NORMATIVA N
o
02, DE 12 DE MARÇO DE 2019
Atualiza requisitos para serviços de confiança de uso de chaves
criptográficas e inclui a definição da Lista de Prestadores de Serviço de
Confiança – LPSC no âmbito da ICP-Brasil.
O DIRETOR-PRESIDENTE DO INSTITUTO NACIONAL DE TECNOLOGIA DA INFORMAÇÃO, no uso das atribuições que lhe foram conferidas pelo inciso VI do art. 9º do
anexo I do Decreto nº 8.985, de 8 de fevereiro de 2017, e pelo art. 1º da Resolução nº 33 do Comitê Gestor da ICP-Brasil, de 21 de outubro de 2004,
RESOLVE:
Art. 1º O item 6.4 do DOC-ICP-17.01, versão 1.1, passa a vigorar com a seguinte redação:
".................................................................
6.4. Requisitos para serviços de confiança de uso de chaves privadas
6.4.1. Definições para Interface de Serviços de Confiança
Deverá ser ulizado o protocolo TLS, definido pela RFC 5246 ou a versão atualizada, para comunicação com serviços de confiança.
Deverá ser ulizado o framework OAuth 2.0 (RFC 6749 e RFC 7636) para implementação da interface aos serviços de confiança dos PSC.
Adicionalmente, poderá ser implementada outra interface para os serviços de confiança, desde que o PSC proveja o soware necessário para possibilitar ao tular o uso das suas chaves
privadas de forma segura.
6.4.2. Definições para URI de base para Serviços de Confiança
A URI de base – URI-base – definirá o eslo e formato dos endereços HTTPS de serviços de confiança.
A URI de base conterá número correspondendo à versão de API definida pela ICP-Brasil.
Este documento trata da versão “v0” de API para PSC.
Exemplo de URI-base:
hps://servico.provedor_de_servico.com.br/v0/
Obs.: O endereço servico.provedor_de_servico.com.br representa neste exemplo a porção authority da URI em domínio ulizado pelo PSC.
As demais porções de URI presentes neste documento devem ser concatenadas à URI-base.
6.4.3. Autorização e Autencação para Requisição de Serviços
6.4.3.1. Fluxo básico para Uso de Serviços de Confiança
Seguindo o fluxo de autorização estabelecido pela RFC 6749, o uso de chaves privadas em PSC deverá ser precedido de solicitação bem-sucedida, por parte de aplicações, dos seguintes
serviços:
Requisição de Código de Autorizaçãoi.
Requisição de Token de Acessoii.
Serviço de assinatura ulizando chave de usuários:iii.
6.4.3.2. Trânsito de Fatores de Autencação
As aplicações não deverão coletar fatores de autencação do usuário. Para este fim, os PSC deverão se comunicar diretamente com equipamento do usuário, previamente idenficado e
cadastrado junto ao PSC de forma segura.
Excetua-se desta regra o Serviço “Autorização com Credenciais do Titular”.
6.4.3.3. Autencação de Aplicações de Assinatura
Para obter acesso aos serviços de confiança, os PSC deverão implementar obrigatoriamente o Serviço de Cadastro de Aplicação com Cerficado ICP-Brasil para SSL.
O PSC poderá também implementar Serviços de Confiança Opcionais para Cadastro de Aplicação sem Cerficado, Token de Acesso para Aplicações e Manutenção de Aplicações.
Os PSC poderão implementar, para as aplicações, outros métodos de acesso aos seus serviços, desde que os riscos associados sejam avaliados e possibilitem rastreabilidade.
6.4.4. Relação de Serviços de Confiança Disponibilizados por PSC
a) Serviços de Confiança Obrigatórios
Código de Autorizaçãoi.
Token de Acessoii.
Assinaturaiii.
Cadastro de Aplicação com Cerficadoiv.
Listagem de Cerficados do Titularv.
Localização de Titularvi.
b) Serviços de Confiança Opcionais
Cadastro de Aplicação sem Cerficadoi.
Token de Acesso para Aplicaçãoii.
Manutenção de Aplicaçãoiii.
Autorização com Credenciais do Titulariv.
SEI/ITI - 0314558 - Instrução Normativa https://sei.iti.gov.br/sei/controlador.php?acao=documento_imprimir_...
1 of 9
10/04/2019 14:31
REVOGADA
6.4.5. Detalhamento de Serviços de Confiança Obrigatórios
6.4.5.1. Serviços de Autorização
6.4.5.1.1. Código de Autorização (Authorizaon Code Request)
Serviço para obter do tular a autorização de uso da sua chave privada.
Caso o tular possua mais de um cerficado, o PSC deverá apresentá-los para que o tular faça a escolha no mesmo contexto de aplicação em que transitarem os fatores de
autencação.
a) Solicitação
Path : <URI-base>/oauth/authorize;
Método HTTPS: GET;
Parâmetros da requisição: concatenados após o Path como parâmetros hp query, usando o formato "applicaon/x-www-form-urlencoded":
response_type: obrigatório, valor "code";
client_id: obrigatório, deve conter a identificação da aplicação;
redirect_uri: opcional, deve ter a URI para redirecionar o usuário de volta para a aplicação de origem. A URI deve estar na lista de URI's autorizadas para a aplicação. Deve ser
URL ENCODED. Se não informado, será considerada a primeira URI cadastrada para a aplicação;
state: opcional, é retornado sem modificações para aplicação de origem;
Recomendado. Um valor opaco usado pela aplicação para manter o estado entre a requisição e a resposta. O serviço de autorização incluirá este valor ao redirecionar o módulo
do usuário de volta ao endereço da aplicação. Este parâmetro deverá ser usado para prevenir ataques de falsificação de requisições entre sites (cross-site request forgery).
lifetime: opcional, indica o tempo de vida desejado para o token a ser gerado. Inteiro, em segundos;
scope: opcional, se não informado, será considerado "single_signature".
(ver lista de escopos abaixo). Possíveis valores para o parâmetro:
single_signature: token que permite a assinatura de apenas um conteúdo (hash), sendo invalidado apos a sua utilização;
multi_signature: token que permite a assinatura de multiplos hashes em uma única requisicao, sendo invalidado apos 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.
code_challenge: obrigatório, ver RFC 7636
code_challenge_method: obrigatório, valor “S256” (ver RFC 7636).
login_hint: opcional, valor de CPF ou CNPJ a ser informado como filtro para seleção do certificado a ser utilizado.
b) Resposta da Requisição de Código de Autorização:
Se o usuário autorizar a solicitação, o 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 hp query, usando o formato "applicaon/x-www-form-urlencoded":
code: obrigatório, código de autorização gerado pelo PSC, a ser usado na solicitação do token de acesso;
state: obrigatório caso tenha sido informado na requisição, deverá conter o que foi enviado na requisição.
Se o usuário não autorizar a solicitação, o PSC retorna para aplicação cliente através de sua redirect_uri os seguintes parâmetros via hp query, usando o formato "applicaon/x-www-
form-urlencoded":
error: obrigatório, com o valor “user_denied”;
state: obrigatório caso tenha sido informado na requisição, deverá conter o que foi enviado na requisição.
6.4.5.1.2. Token de Acesso
Após a obtenção de código de autorização, o token de acesso deve ser solicitado com parâmetros no formato "applicaon/x-www-form-urlencoded".
a) Solicitação
Path : <URI-base>/oauth/token;
Método HTTPS: POST;
Parâmetros da requisição: formato "applicaon/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: obrigatório, deve conter código de autorização retornado do Serviço Código de Autorização;
redirect_uri: opcional, deve ser igual ao informado no Serviço Código de Autorização;
code_verifier: obrigatório, correspondendo a code_challenge enviado na Requisição de Código de Autorização, ver RFC 7636.
Exemplo:
POST {.../oauth/token} HTTP/1.1
Host: {servidor do PSC}
Content-Type: applicaon/x-www-form-urlencoded
grant_type=authorizaon_code
&client_id=MyApplicaonId
&client_secret=123qwe
&code=09b30f74d40a7fece1a26cccc97746c364e61022
&redirect_uri=hps://idg.receita.fazenda.gov.br
&code_verifier={Verifier}
b) Resposta da Requisição de Token de Acesso:
Se a requisição é valida e autorizada o PSC emite um token de acesso e retorna a requisição com sucesso, via HTTP Status Code 200.
Parâmetros de retorno: formato "applicaon/json;charset=UTF-8"
access_token: obrigatório, valor do token de acesso;
token_type: obrigatório, valor "Bearer";
expires_in: obrigatório, valor inteiro com validade do token em segundos.Para acesso a objeto de pessoas sicas não deve ultrapassar (7 dias), sendo que para pessoas
jurídicas este limite será de (30 dias);
scope: opcional, deve ser informado se o escopo retornado for diferente do solicitado pela aplicação;
authorized_ideficaon_type: obrigatório, deverá conter “CPF” ou “CNPJ”
authorized_ideficaon: obrigatório, valor correspondendo ao CPF ou CNPJ associado ao tular do cerficado.
Exemplo:
HTTP/1.1 200 OK
SEI/ITI - 0314558 - Instrução Normativa https://sei.iti.gov.br/sei/controlador.php?acao=documento_imprimir_...
2 of 9
10/04/2019 14:31
Content-Type: applicaon/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "b923575f1ced0ee732ee274b2e02784040bd9606",
"expires_in": 300,
"token_type": "Bearer
"authorized_idenficaon_type": "CPF
"authorized_idenficaon": 00000000001
}
OBS: Não será permido o refresh_token.
Se a requisição não for válida, houver falha na autencação da aplicação cliente ou alguma outra falha, o PSC retorna a requisição com erro, via HTTP Status Code de erro
correspondente à situação ocorrida via JSON com os seguintes parâmetros:
Parâmetros de retorno: formato "applicaon/json;charset=UTF-8":
error: obrigatório, representa o código do erro. Possíveis valores para o parâmetro e HTTP Status Code de erro:
invalid_request: HTTP Status Code 400, ocorre quando algum parâmetro obrigatório não ver sido informado ou inclui um valor de parâmetro não suportado ou algum
parâmetro com valor duplicado informado ou a requisição é mal formada;
invalid_grant: HTTP Status Code 400, ocorre quando o código de autorização apresentado esver inválido ou expirado ou ver sido emido para uma outra aplicação cliente
diferente da informada ou já esver sido ulizado em um cenário de uso único(scope single_signature e mul_signature). Ocorre também na validação da redirect_uri e na
validação do code_verifier(ver RFC 7636);
invalid_client: HTTP Status Code 401, ocorre quando houver falha na autencação da aplicação cliente, desde aplicação não idenficada até credenciais inválidas;
unsupported_grant_type: HTTP Status Code 400, ocorre quando o valor informado no parâmetro grant_type não for suportado.
server_error: HTTP Status Code 500, ocorre quando houver algum erro interno não tratado pelo PSC.
error_descripon: opcional, texto com informações adicionais descrevendo o erro a fim de assisr o entendimento do ocorrido;
error_uri: opcional, URI de uma página WEB que contém informações sobre o erro ocorrido.
Exemplo:
HTTP/1.1 400 Bad Request
Content-Type: applicaon/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
“error”: “invalid_request”,
“error_descripon”: “Parâmetro obrigatório não informado: code”,
“error_uri”:“hps://psc.exemplo.com.br/docs/oauth2-error#invalid_request”
}
6.4.5.2. Assinatura
Os parâmetros com conteúdo a ser assinado e assinaturas deverão conter valores em Base64.
Se o escopo do token permir apenas uma assinatura (single_signature) e for informado mais de um conteúdo, uma mensagem de erro deve ser retornada.
a) Solicitação
Path: <URI-base>/oauth/signature
Método HTTPS: POST
Cabeçalho: Re: Nova Versão da IN PSC
Content-type: applicaon/json;
Accept : applicaon/json;
Authorizaon: Bearer access_token;
Parâmetros: formato "applicaon/json;charset=UTF-8" :
hashes: conjunto com valores 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;
certificate_alias: opcional, identificador do certificado correspondente à chave utilizada na assinatura;
signature_format: obrigatório:
RAW: resultado direto (em base64) da operação RSA/DSA sobre o hash informado na requisição.
CMS detached (PKCS#7), contendo os seguintes atributos assinados:
- contentType
- signingTime (hora do PSC)
- messageDigest (hash informado pela aplicação na requisição)
- signingCerficateV2 (cerficado do assinante)
Exemplo
"hashes": [{
"id": "Signature request ID 1",
"alias": "Contrato de aluguel XPTO",
"hash": "hash to sign",
“signature_format”: “RAW”
},
{
SEI/ITI - 0314558 - Instrução Normativa https://sei.iti.gov.br/sei/controlador.php?acao=documento_imprimir_...
3 of 9
10/04/2019 14:31
"id": "Signature request ID 2",
"alias": "Documento do Word",
"hash": "hash to sign",
“signature_format”: “CMS”
}
{
"id": "Signature request ID n",
"alias": "Firefox",
"hash": "hash to sign",
“signature_format” : “RAW”
}
]}
b) Resposta da Requisição de Assinatura:
O PSC retornará a requisição com sucesso, via HTTP Status Code 200.
Parâmetros: formato "applicaon/json;charset=UTF-8":
cerficate_alias: obrigatório, idenficador do cerficado correspondente à chave ulizada na assinatura;
signatures: obrigatório, conjunto com idenficadores dos conteúdos a serem assinados e valores assinados. Cada elemento do conjunto conterá:
id: idenficador do conteúdo assinado;
raw_signature: valor numérico em base64 da assinatura produzida.
(de acordo com a suíte de assinatura, se esta for informada)
Exemplo
{
"cerficate_alias": "CERTIFICADO TESTE 1:1234567889",
"signatures": [{
"id": "Signature request ID 1",
"raw_signature": "my raw signature base64"
},
{
"id": "Signature request ID 2",
"raw_signature": "my raw signature base64"
},
{
"id": "Signature request ID n",
"raw_signature": "my raw signature base64"
}]}
6.4.5.4. Cadastro de Aplicação com Cerficado
Serviço para cadastro de uma aplicação junto ao PSC, sendo que a aplicação ulizará um cerficado SSL ICP-Brasil para assinar os dados enviados, substuindo neste caso o Serviço de
Cadastro de Aplicação.
A assinatura dos dados necessários para o cadastro será realizada ulizando o formato JWT with RSA Signature, conhecido como JWS – Json Web Signature (ver RFC 7515), ulizando o
algoritmo de hash SHA-256.
O header do JWS deverá conter os seguintes parâmetros:
alg: obrigatório, valor “RS256” representando RSA With SHA-256;
x5c: obrigatório, valor mulvalorado contendo o cerficado SSL ICP-Brasil no formato PEM.
Exemplo do Header do JWS desserializado:
{
“alg”: “RS256”,
"x5c": [“-----BEGIN CERTIFICATE-----ADFAASDFASDFAS. . . -----END CERTIFICATE-----”]
}
O conjunto de dados JWS deverá conter os seguintes parâmetros:
name: obrigatório, nome da aplicação;
comments: obrigatório, descrição da aplicação;
redirect_uris: obrigatório, valor mulvalorado contendo URI’s autorizadas para redirecionamento (para serviços de requisição de autorização). Devem ser oriundas do host do
cerficado de equipamento apresentado, sendo vedada a ulização de fragments;
host: obrigatório, valor contendo o host único da aplicação;
aud: obrigatório, valor contendo o nome único do PSC a qual a assinatura é direcionada.
E-mail: obrigatório, e-mail para suporte em caso de indisponibilidade, mudança de versão, entre outros.
Exemplo do Payload do JWS deserializado:
{
"name": "Nome da Aplicação",
"comments": "Descrição da Aplicação",
"host": "www.aplicacao-exemplo.com",
"redirect_uris": ["hps://www.aplicacao-exemplo.com/callback/cerficado_nuvem"],
SEI/ITI - 0314558 - Instrução Normativa https://sei.iti.gov.br/sei/controlador.php?acao=documento_imprimir_...
4 of 9
10/04/2019 14:31
"aud": "nome-unico-psc"
"email": "psc@psc.com.br"
}
a) Solicitação
Path: <URI-base>/oauth/applicaon_cert
Método HTTPS: POST
Cabeçalho:
Accept: applicaon/octet-stream;
Body: string contendo o JWS serializado.
b) Resposta do Serviço de Cadastro de Aplicação com Cerficado
Parâmetros: formato "applicaon/json;charset=UTF-8" :
client_id: obrigatório, idenficador único da aplicação gerado pelo PSC;
client_secret: obrigatório, credencial da aplicação gerada de forma aleatória pelo PSC;
6.4.5.5. Recuperação de Cerficado
Serviço para recuperar cerficado armazenado no PSC.
A aplicação deverá ter um Access Token válido.
a) Solicitação
Path : <URI-base>/cerficate-discovery;
Método HTTPS: GET
Cabeçalho:
Content-type: applicaon/json;
Accept: applicaon/json;
Authorizaon: Bearer access_token;
cerficate_alias: opcional, é o idenficador do cerficado a ser recuperado.
b) Resposta
Parâmetros
status: obrigatório, indicando “S” para resultado posivo ou “N” caso contrário;
cerficates: cerficado em BASE64 recuperado;
Exemplo
{
"status": "S"
"cerficates": [
{
"alias": "CERTIFICADO TESTE 1:123456789
"cerficate": "-----BEGIN CERTIFICATE-----\n{CERTIFICADO}\n-----END CERTIFICATE-----”,
}
{
"alias": "CERTIFICADO TESTE 2:123456789
"cerficate": "-----BEGIN CERTIFICATE-----\n{CERTIFICADO}\n-----END CERTIFICATE-----”,
}
]
}
6.4.5.6. Localização de Titular
Serviço para encontrar um tular mediante informação de CPF ou CNPJ.
a) Solicitação
Path: <URI-base>/oauth/user-discovery;
Método HTTPS: POST;
Parâmetros da requisição: formato "applicaon/x-www-form-urlencoded" :
client_id: obrigatório, deve conter a idenficaçã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 sica ou “CNPJ” pessoa jurídica;
val_cpf_cnpj: obrigatório, deve conter o valor do cpf ou cnpj ;
b) Resposta
Parâmetros
slots: opcional, matriz com os alias de slots encontrados, composto pelos pares ordenados slot_alias e label;
status: obrigatório, indicando “S” para resultado posivo ou “N” caso contrário;
SEI/ITI - 0314558 - Instrução Normativa https://sei.iti.gov.br/sei/controlador.php?acao=documento_imprimir_...
5 of 9
10/04/2019 14:31
Exemplo
{
"slots": [
{
"slot_alias": "12345678899-1",
"label": "A3 PESSOAL"
}
{
"slot_alias": "12345678899-2",
"label": "A3 TRABALHO"
}
],
"status": "S”
}
6.4.6. Detalhamento de Serviços de Confiança Opcionais
6.4.6.1. Cadastro de Aplicação sem Cerficado
Serviço para cadastro de uma aplicação junto ao PSC. É obrigatório para todas as aplicações que ulizarem serviços de autorização sem cerficados ICP-Brasil.
a) Solicitação
Path : <URI-base>/oauth/application
Método HTTPS: POST
Cabeçalho:
Content-type: applicaon/json ;
Accept: applicaon/json ;
Parâmetros: formato "applicaon/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).
e-mail: obrigatório, e-mail para suporte em caso de indisponibilidade, mudança de versão, entre outros.
Exemplo:
{
"name": "(Nome/Descricao da aplicacao)",
"comments": "(Observacoes gerais de uso da aplicacao)",
"redirect_uris": [
"URI 1 pre cadastrada para redirecionamento",
"URI 2 pre cadastrada para redirecionamento",
"URI N pre cadastrada para redirecionamento"
]
"email": "psc@psc.com.br"
}
b) Resposta da Requisição de Cadastro de Aplicação
Parâmetros : formato "applicaon/json;charset=UTF-8" :
client_id: idenficador da aplicação;
client_secret: segredo associado à aplicação;
status: obrigatório, “success" para sucesso;
message: obrigatório, mensagem com informações adicionais.
Exemplo:
{
"client_id": "(idenficador da aplicacao)",
"client_secret": "(segredo da aplicacao)",
"status": "success",
"message": "Aplicacao cadastrada com sucesso"
}
6.4.6.2. Serviços de Manutenção de Cadastro de Aplicação
Serviço para manutenção das informações armazenadas de uma aplicação no PSC. É obrigatório para todas as aplicações que ulizarem serviços de autorização não idenficadas por
cerficados ICP-Brasil para SSL.
6.4.6.2.1. Token de Acesso para Aplicação
Requisição para que uma aplicação obtenha token de acesso para manutenção de seu cadastro junto ao PSC.
a) Solicitação
Método HTTPS : POST;
Path: <URI-base>/oauth/client_token;
Parâmetros da requisição: concatenados após o Path como parâmetros hp query, usando o formato "applicaon/x-www-form-urlencoded":
grant_type, obrigatório, valor "client_credentials";
client_id, obrigatório, deve conter a identificação da aplicação;
SEI/ITI - 0314558 - Instrução Normativa https://sei.iti.gov.br/sei/controlador.php?acao=documento_imprimir_...
6 of 9
10/04/2019 14:31
client_secret, obrigatório para aplicações que possuem certificado digital;
Exemplo:
POST {.../oauth/client_token} HTTP/1.1
Host: {servidor do PSC}
Content-Type: applicaon/x-www-form-urlencoded
client_id=Idenficacao_aplicacao
&client_secret=123qwe
&grant_type=client_credenals
b) Resposta da Requisição de Token de Acesso para Aplicações:
Parâmetros de retorno: formato "applicaon/json;charset=UTF-8" :
access_token, obrigatório, valor do token de acesso;
token_type, obrigatório, valor "Bearer";
expires_in, opcional, validade do token em segundos.
Exemplo:
{
"access_token": "b923575f1ced0ee732ee274b2e02784040bd9606",
"expires_in": 7200,
"token_type": "Bearer"
}
6.4.6.2.2. Manutenção de Aplicação
Serviço para atualização de informações de uma aplicação. Requer um token de acesso para aplicações, enviado no parâmetro de cabeçalho “Authorizaon” .
a) Solicitação
Path: <URI-base>/oauth/client_maintenance ;
Método HTTPS: PUT;
Cabeçalho:
Content-type: applicaon/json ;
Accept: applicaon/json;
Authorizaon: Bearer access_token (“Bearer” concatenado com espaço e access_token);
Parâmetros: formato "applicaon/json;charset=UTF-8" :
client_id, obrigatório, deve conter a identificação da aplicação;
client_secret, opcional, nova senha da aplicação;
name, opcional, nome da aplicação;
comments, opcional, descrição da aplicação;
redirect_uris, opcional, URI’s autorizadas para redirecionamento (para requisição de código de autorização).
e-mail: obrigatório, e-mail para suporte em caso de indisponibilidade, mudança de versão, entre outros.
Exemplo:
{
"client_id": "idenficador da aplicacao",
"client_secret": "(Senha/Segredo da aplicacao)",
"name": "(Nome da aplicacao)",
"comments": "(Descrição da aplicação)",
"redirect_uris": [
"URI 1 pre cadastrada para redirecionamento",
"URI 2 pre cadastrada para redirecionamento",
"URI N pre cadastrada para redirecionamento"
]
"email": "psc@psc.com.br"
}
b) Resposta da Requisição de Manutenção de Aplicações
Parâmetros de retorno: formato "applicaon/json;charset=UTF-8" :
client_id: obrigatório, deve conter a idenficação da aplicação;
Exemplo :
{
“client_id”: “(idenficador da aplicação)”,
}
6.4.6.3. Autorização com Credenciais do Titular
Serviço para obter do tular autorização de uso da sua chave privada, com solicitação de fatores de autencação.
No mínimo um fator de autencação obdo deve ser válido para uma única solicitação de autorização (OTP- one-me password).
Os fatores de autencação deverão ter seus valores concatenados e enviados no parâmetro “password”.
a) Solicitação
Path: <URI-base>/oauth/pwd_authorize ;
SEI/ITI - 0314558 - Instrução Normativa https://sei.iti.gov.br/sei/controlador.php?acao=documento_imprimir_...
7 of 9
10/04/2019 14:31
Método HTTPS: POST;
Cabeçalho:
Content-type: applicaon/json;
Accept: applicaon/json;
Parâmetros: formato "applicaon/json;charset=UTF-8" :
grant_type, obrigatório, valor "password”;
client_id, obrigatório, idenficação da aplicação;
client_secret, opcional, sendo obrigatório apenas quando a aplicação não ulizar cerficado ICP-Brasil;
username, obrigatório, idenficação do usuário por meio de CPF ou CNPJ;
password, obrigatório, valor da concatenação de fatores de autencação informadas pelo usuário;
lifeme, opcional, valor inteiro, indica o tempo de vida desejado para o token a ser gerado em segundos. Para acesso a objeto de pessoas sicas não deve ultrapassar (7
dias), sendo que para pessoas jurídicas este limite será de (30 dias);
scope, opcional, se não informado será considerado "single_signature". (ver lista de escopos para Serviço de Código de Autorização ).
slot_alias: opcional, indica o slot do usuário no qual a autencação deve ser feita. Se não informado, o PSC decidirá em qual slot tentar a autencação.
Exemplo:
{
“client_id": "MyApplicaonId",
"client_secret": "123qwe",
"username": "0660457192",
"password": "123456SENHA",
"grant_type": "password",
"scope": "single_signature",
"lifeme": 900,
"slot_alias": "12345678899"
}
b) Resposta da Requisição de Autorização com Credenciais do Titular
Parâmetros de retorno: formato "applicaon/json;charset=UTF-8":
access_token, obrigatório, valor do token de acesso;
token_type, obrigatório, valor "Bearer";
expires_in, obrigatório, validade do token em segundos. Não deve ultrapassar o valor 300 (5 minutos);
scope, opcional, informado apenas se o escopo retornado for diferente do solicitado pela aplicação.
slot_alias: obrigatório, indica o slot do usuário no qual a autenticação foi feita (sem middleware).
Exemplo:
{
"access_token":
"b923575f1ced0ee732ee274b2e02784040bd9606",
"expires_in": 300,
"token_type": "Bearer",
"slot_alias": "12345678899"
}
................................................................." (NR)
Art. 2º O DOC-ICP-17.01, versão 1.1, passa a vigorar acrescido do item 6.5 com a seguinte redação:
".................................................................
6.5 Lista de Prestador de Serviço de Confiança – LPSC
6.5.1 A Lista de Prestadores de Serviço de Confiança – LPSC contem as endades credenciadas no âmbito da ICP-Brasil como Prestadores de Serviço de Confiança - PSC. A LPSC será
publicada pela AC Raiz e atualizada no prazo máximo de 180 dias.
6.5.2 A LPSC será publicada no repositório da AC Raiz em versão textual, para leitura humana, e em XML, para processamento por máquina.
6.5.3 A autencidade e a integridade da versão processável por máquina da lista compilada é assegurada por meio de uma assinatura digital XMLDSig suportada por um cerficado
digital do ITI.
6.5.4 As versões da LPSC e o cerficado que assina a LPSC serão publicados no repositório da AC Raiz, disponível em:
http://www.iti.gov.br/repositorio
6.5.5 A autencidade e integridade da lista compilada devem ser verificadas pelas partes confiáveis antes de qualquer uso.
6.5.6 A LPSC é codificada em XML, em conformidade com a estrutura proposta pelo padrão ETSI TS 102 231, e contem os seguintes dados:
a) a informação do esquema (SchemeInformaon), onde são apresentados os dados de idenficação do emissor, o ITI, e a data da próxima atualização (NextUpdate) da lista;
b) a lista de prestadores de serviço (TrustServiceProviderList), que contem uma entrada (TrustServiceProvider) para cada PSC credenciado junto à ICP-Brasil; e
c) assinatura digital no formato XMLdSIG.
................................................................." (NR)
Art. 3º Aprovar a versão 2.0 do documento DOC-ICP-17.01 – PROCEDIMENTOS OPERACIONAIS MÍNIMOS PARA OS PRESTADORES DE SERVIÇO DE CONFIANÇA DA ICP-BRASIL.
§ 1º As demais cláusulas do referido documento, na sua versão imediatamente anterior, integram a presente versão e mantêm-se válidas.
§ 2º O documento referido no caput encontra-se disponibilizado, em sua totalidade, no sío hp://www.i.gov.br.
SEI/ITI - 0314558 - Instrução Normativa https://sei.iti.gov.br/sei/controlador.php?acao=documento_imprimir_...
8 of 9
10/04/2019 14:31
Art. 4º Esta Instrução Normava entra em vigor na data de sua publicação.
MARCELO AMARO BUZ
Documento assinado eletronicamente por Marcelo Amaro Buz, Presidente, em 13/03/2019, às 20:19, conforme horário oficial de Brasília, com o emprego de cerficado digital emido no
âmbito da ICP-Brasil, com fundamento no art. 6º, caput, do Decreto nº 8.539, de 8 de outubro de 2015.
Nº de Série do Cerficado: 112893769072490543061877721310325213903
A autencidade deste documento pode ser conferida no site hps://sei.i.gov.br/sei/controlador_externo.php?acao=documento_conferir&id_orgao_acesso_externo=0, informando o
código verificador 0314558 e o código CRC F7AE0230.
SEI/ITI - 0314558 - Instrução Normativa https://sei.iti.gov.br/sei/controlador.php?acao=documento_imprimir_...
9 of 9
10/04/2019 14:31