INSTRUÇÃO NORMATIVA Nº 2, 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 utilizado o protocolo TLS, definido pela RFC 5246 ou a versão

atualizada, para comunicação com serviços de confiança.

Deverá ser utilizado 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 software necessário para possibilitar ao

titular 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 estilo 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:

https://servico.provedor_de_servico.com.br/v0/

Obs.: O endereçoservico.provedor_de_servico.com.brrepresenta neste exemplo

a porção authority da URI em domínio utilizado pelo PSC.

As demais porções de URI presentes neste documento devem ser concatenadas

à URI-base.

6.4.3. Autorização e Autenticaçã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:

i. Requisição de Código de Autorização

ii. Requisição de Token de Acesso

iii. Serviço de assinatura utilizando chave de usuários:

6.4.3.2. Trânsito de Fatores de Autenticação

As aplicações não deverão coletar fatores de autenticação do usuário. Para este

fim, os PSC deverão se comunicar diretamente com equipamento do usuário,

previamente identificado 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. Autenticaçã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 Certificado ICP-Brasil

para SSL.

O PSC poderá também implementar Serviços de Confiança Opcionais para

Cadastro de Aplicação sem Certificado, 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

i. Código de Autorização

ii. Token de Acesso

iii. Assinatura

iv. Cadastro de Aplicação com Certificado

v. Listagem de Certificados do Titular

vi. Localização de Titular

b) Serviços de Confiança Opcionais

i. Cadastro de Aplicação sem Certificado

ii. Token de Acesso para Aplicação

iii. Manutenção de Aplicação

iv. Autorização com Credenciais do Titular

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 (Authorization Code Request)

Serviço para obter do titular a autorização de uso da sua chave privada.

Caso o titular possua mais de um certificado, o PSC deverá apresentá-los para

que o titular faça a escolha no mesmo contexto de aplicação em que

transitarem os fatores de autenticaçã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 http

query, usando o formato "application/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 http query, usando o

formato "application/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 http query, usando o

formato "application/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 "application/x-www-form-urlencoded".

a) Solicitação

Path : <URI-base>/oauth/token;

Método HTTPS: POST;

Parâmetros da requisição: 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: 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: application/x-www-form-urlencoded

grant_type=authorization_code

&client_id=MyApplicationId

&client_secret=123qwe

&code=09b30f74d40a7fece1a26cccc97746c364e61022

&redirect_uri=https://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 "application/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 fí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_idetification_type: obrigatório, deverá conter "CPF" ou

"CNPJ"

authorized_idetification: obrigatório, valor correspondendo ao CPF ou

CNPJ associado ao titular do certificado.

Exemplo:

HTTP/1.1 200

OK

Content-Type: application/json;charset=UTF-8

Cache-Control: no-store

Pragma: no-cache

{ "

access_token": "

b923575f1ced0ee732ee274b2e02784040bd9606",

"expires_in": 300,

"token_type": "Bearer

"authorized_identification_type": "CPF

"authorized_identification": 00000000001

}

OBS: Não será permitido o refresh_token.

Se a requisição não for válida, houver falha na autenticaçã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 "application/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 tiver 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 estiver inválido ou expirado ou tiver sido

emitido para uma outra aplicação cliente diferente da informada ou já

estiver sido utilizado em um cenário de uso único(scope

single_signature e multi_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

autenticação da aplicação cliente, desde aplicação não identificada 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_description: opcional, texto com informações adicionais descrevendo

o erro a fim de assistir 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: application/json;charset=UTF-8

Cache-Control: no-store

Pragma: no-cache

{

"error": "invalid_request",

"error_description": "Parâmetro obrigatório não informado: code",

"error_uri":"https://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 permitir 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: application/json;

Accept : application/json;

Authorization: Beareraccess_token;

Parâmetros: formato "application/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)

- signingCertificateV2 (certificado do assinante)

Exemplo

"hashes": [{

"id": "Signature request ID 1",

"alias": "Contrato de aluguel XPTO",

"hash": "hash to sign",

"signature_format": "RAW"

},

{

"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 "application/json;charset=UTF-8":

certificate_alias: obrigatório, identificador do certificado

correspondente à chave utilizada na assinatura;

signatures: obrigatório, conjunto com identificadores dos conteúdos a

serem assinados e valores assinados. Cada elemento do conjunto

conterá:

id: identificador 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

{

"certificate_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 Certificado

Serviço para cadastro de uma aplicação junto ao PSC, sendo que a aplicação

utilizará um certificado SSL ICP-Brasil para assinar os dados enviados,

substituindo neste caso o Serviço de Cadastro de Aplicação.

A assinatura dos dados necessários para o cadastro será realizada utilizando o

formato JWT with RSA Signature, conhecido como JWS - Json Web Signature

(ver RFC 7515), utilizando 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 multivalorado contendo o certificado SSL ICPBrasil

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 multivalorado contendo URI's autorizadas

para redirecionamento (para serviços de requisição de autorização). Devem

ser oriundas do host do certificado de equipamento apresentado, sendo

vedada a utilizaçã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": ["https://www.aplicacaoexemplo.

com/callback/certificado_nuvem"],

"aud": "nome-unico-psc"

"email": "[email protected]"

}

a) Solicitação

Path: <URI-base>/oauth/application_cert

Método HTTPS: POST

Cabeçalho:

Accept: application/octet-stream;

Body: string contendo o JWS serializado.

b) Resposta do Serviço de Cadastro de Aplicação com Certificado

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

client_id: obrigatório, identificador ú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 Certificado

Serviço para recuperar certificado armazenado no PSC.

A aplicação deverá ter um Access Token válido.

a) Solicitação

Path : <URI-base>/certificate-discovery;

Método HTTPS: GET

Cabeçalho:

Content-type: application/json;

Accept: application/json;

Authorization: Bearer access_token;

certificate_alias: opcional, é o identificador do certificado a ser

recuperado.

b) Resposta

Parâmetros

status: obrigatório, indicando "S" para resultado positivo ou "N" caso

contrário;

certificates: certificado em BASE64 recuperado;

Exemplo

{

"status": "S"

"certificates": [

{

"alias": "CERTIFICADO TESTE 1:123456789

"certificate": "-----BEGIN CERTIFICATE-----\n{CERTIFICADO}\n-----END

CERTIFICATE-----",

}

{

"alias": "CERTIFICADO TESTE 2:123456789

"certificate": "-----BEGIN CERTIFICATE-----\n{CERTIFICADO}\n-----END

CERTIFICATE-----",

}

]

}

6.4.5.6. Localização de Titular

Serviço para encontrar um titular 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 "application/x-www-form-urlencoded" :

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 ;

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 positivo ou "N" caso

contrário;

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 Certificado

Serviço para cadastro de uma aplicação junto ao PSC. É obrigatório para todas

as aplicações que utilizarem serviços de autorização sem certificados ICP-Brasil.

a) Solicitação

Path : <URI-base>/oauth/application

Método HTTPS: POST

Cabeçalho:

Content-type: application/json ;

Accept: application/json ;

Parâmetros: 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).

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": "[email protected]"

}

b) Resposta da Requisição de Cadastro de Aplicação

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

client_id: identificador 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": "(identificador 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 utilizarem serviços de

autorização não identificadas por certificados 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 http

query, usando o formato "application/x-www-form-urlencoded":

grant_type, obrigatório, valor "client_credentials";

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

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: application/x-www-form-urlencoded

client_id=Identificacao_aplicacao

&client_secret=123qwe

&grant_type=client_credentials

b) Resposta da Requisição de Token de Acesso para Aplicações:

Parâmetros de retorno: formato "application/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 "Authorization" .

a) Solicitação

Path: <URI-base>/oauth/client_maintenance ;

Método HTTPS: PUT;

Cabeçalho:

Content-type: application/json ;

Accept: application/json;

Authorization: Beareraccess_token ("Bearer" concatenado com espaço

e access_token);

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

Instrução Normativa 2 (0314558) SEI 00100.002293/2019-50 / pg. 5

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": "identificador 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": "[email protected]"

}

b) Resposta da Requisição de Manutenção de Aplicações

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

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

Exemplo :

{

"client_id": "(identificador da aplicação)",

}

6.4.6.3. Autorização com Credenciais do Titular

Serviço para obter do titular autorização de uso da sua chave privada, com

solicitação de fatores de autenticação.

No mínimo um fator de autenticação obtido deve ser válido para uma única

solicitação de autorização (OTP- one-time password).

Os fatores de autenticação deverão ter seus valores concatenados e enviados

no parâmetro "password".

a) Solicitação

Path: <URI-base>/oauth/pwd_authorize ;

Método HTTPS: POST;

Cabeçalho:

Content-type: application/json;

Accept: application/json;

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

grant_type, obrigatório, valor "password";

client_id, obrigatório, identificação da aplicação;

client_secret, opcional, sendo obrigatório apenas quando a aplicação

não utilizar certificado ICP-Brasil;

username, obrigatório, identificação do usuário por meio de CPF ou

CNPJ;

password, obrigatório, valor da concatenação de fatores de

autenticação informadas pelo usuário;

lifetime, opcional, valor inteiro, indica o tempo de vida desejado para

o token a ser gerado em segundos. Para acesso a objeto de pessoas

fí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 autenticação

deve ser feita. Se não informado, o PSC decidirá em qual slot tentar a

autenticação.

Exemplo:

{

"client_id": "MyApplicationId",

"client_secret": "123qwe",

"username": "0660457192",

"password": "123456SENHA",

"grant_type": "password",

"scope": "single_signature",

"lifetime": 900,

"slot_alias": "12345678899"

}

b) Resposta da Requisição de Autorização com Credenciais do Titular

Parâmetros de retorno: formato "application/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

entidades 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 autenticidade 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 certificado digital do ITI.

6.5.4 As versões da LPSC e o certificado 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 autenticidade 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 (SchemeInformation), onde são apresentados

os dados de identificaçã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 à ICPBrasil;

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ítio http://www.iti.gov.br.

Art. 4º Esta Instrução Normativa entra em vigor na data de sua publicação.