Primeiramente, seria necessário a instituição definir quem serão os responsáveis por assinar o Diploma e a Documentação Acadêmica. No mínimo serão 2 pessoas responsáveis e cada um precisa ter um certificado e- CPF do Tipo A3 em Token USB. Adicionalmente, a instituição precisará ter um e -CNPJ também do Tipo A3 em Token USB. Todos os certificados precisam ser do padrão ICP-Brasil.
É um serviço gratuito disponibilizado pelo ITI, onde você pode aferir se um arquivo assinado com certificado ICP-Brasil está em conformidade com o DOC-ICP-15.
Atualmente o sistema verifica os padrões CAdES, XAdES e PAdES.
Link: https://verificador.iti.gov.br/verifier-2.8.1/
A Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil é uma cadeia hierárquica de confiança que viabiliza a emissão de certificados digitais para identificação virtual do cidadão.
Observa-se que o modelo adotado pelo Brasil foi o de certificação com raiz única, sendo que o ITI, além de desempenhar o papel de Autoridade Certificadora Raiz – AC-Raiz, também tem o papel de credenciar e descredenciar os demais participantes da cadeia, supervisionar e fazer auditoria dos processos.
Não há limite para os assinantes e-CPF.
Sim. Através do link: https://validadordiplomadigital.mec.gov.br/diploma
A composição do código de validação do diploma será constituída de três grupos de dados:
Código e-MEC da IES emissora;
Código e-MEC da IES registradora;
Código de localização do diploma, devendo ser respeitada a estrutura apresentada na norma técnica item 7.6.1.5
Pela Nota Técnica divulgada pelo MEC, o mínimo para a emissão do Diploma são duas pessoas (e-CPF) (reitor e decano) para os dados do Diplomado, uma pessoa (e-CPF) para os dados de registro, além mais alguém responsável por assinar pela instituição (e-CNPJ). A nota técnica permite que mais pessoas possam assinar os dados do Diplomado e os Dados de Registro. Essa decisão fica a critério da instituição.
Não terá validade, visto que qualquer documento assinado digitalmente impresso, não consegue manter sua validade jurídica, uma vez que a certificação digital foi desenvolvida para o meio eletrônico.
A assinatura digital é um conjunto de dados criptográficos incorporados a um documento.
Por essa razão, precisa de estar no ambiente digital, uma vez que há necessidade de softwares e sistemas específicos ler e compreender estes dados criptografados.
O papel não é capaz de guardar a criptografia que garante a autenticidade da certificação digital.
O Diploma Digital é um XML com assinatura digital e carimbo de tempo ICP-Brasil. Ao imprimir, estes dispositivos deixam de existir e passam ser apenas uma cópia não assinada e sem validade jurídica.
O código de curso e-MEC é único. É possível verificar no portal do e-MEC qual o correto para cada curso de sua IES. Segue abaixo o link do e-MEC: https://emec.mec.gov.br/
Primeiramente é gerado a documentação acadêmica com o dados específicos para tal.
Após essa documentação acadêmica for gerada e assinada pelos responsáveis, o diploma pode ser gerado e posteriormente assinado.
Esse fluxo é necessário porque informações da documentação acadêmica são referenciadas no arquivo do diploma digital.
Por fim, a instituição pode inserir a representação visual.
Conforme À INSTRUÇÃO NORMATIVA SESu Nº , DE 15 DE DEZEMBRO DE 2020, segue o trecho que informa sobre a Documentação Comprobatória: http://portal.mec.gov.br/diplomadigital/arquivos/in-02-versao-completa-anexos-i-ii-e-iii-v1.04.1.pdf 2.3.3.3.1 O documento comprobatório deve ser armazenado como Base64 dos bytes do arquivo PDF/A.
A data do diploma pode ser igual ou superior a da nova versão vigente para que o processo siga de forma correta.
As IES emissoras e registradoras, devem seguir as datas de vigência de cada versão do XSD (http://portal.mec.gov.br/diplomadigital/index.php?pagina=pacote-instituicoes).
A data utilizada para essa conferência é a DataEmissaoHistorico e DataExpedicaoDiploma (datas referentes a versão digital do documento).
Sim, Diploma Digital é um arquivo nato-digital.
Por essa razão que na Portaria MEC nº 554/2019 está estabelecido no § 1º do art.2º que o Diploma Digital é aquele que tem sua existência, sua emissão e seu armazenamento inteiramente no meio digital, e cuja validade jurídica é presumida mediante a assinatura com certificação digital e carimbo de tempo na Infraestrutura de Chaves Públicas Brasileira - ICP-Brasil, conforme os parâmetros do Padrão Brasileiro de Assinaturas Digitais - PBAD e o uso dos demais dispositivos fixados na Portaria.
O Portal de Conformidade avalia a composição do código de validação conforme especificado na nota técnica e nos schemas disponibilizados pelo MEC, mesmo que existam dados fictícios.
É importante ressaltar que os elementos do XML devem possuir os mesmos valores informados para compor tal código (Ex.: Se no elemento CodigoCursoEMEC foi informado o valor 1234, este mesmo valor deverá compor o código de validação).
Conforme as normas, não identificamos restrições quanto ser igual ou diferente as assinaturas dos documentos.
É recomendado que as instituições realizem o backup do banco de dados do Conector antes da realização de qualquer processo de atualização.
É possível recuperar o arquivo, mas o histórico do banco não.
Para recuperar o arquivo é necessário o envio do yourNumber dos documentos.
Sim, um grupo nesse caso é um lote de documentos.
Todos os dados obrigatórios e opcionais, tipos e estruturas podem ser visualizados no JSON Schema. Existe um JSON Schema para cada tipo de documento (Diploma, Documentação Acadêmica e Representação Visual). Os JSONs Schemas são uma cópia fidedigna dos XSDs divulgado pelo MEC em anexo a Nota Técnica. Todos os dados exigidos pelos esquemas JSON para geração dos XMLs foram baseados nos XSDs disponibilizados pelo MEC.
A instituição que estiver migrando para o ambiente de produção irá receber um arquivo docker-compose específico para levantar a imagem do Conector.
Nesse docker-compose estará configurado o servidor de assinatura oficial e o ambiente de produção do servidor de preservação da RNP.
Caso a instituição vá usar a mesma infraestrutura local atual para executar o Conector, é importante “zerar” o banco de dados de integração que é acoplado ao Conector.
No campo de carga horaria () no XSD do MEC, tem que ser um número positivo, sendo assim, o mesmo não aceita 0 ou valor nulo.
O MEC disponibiliza o XSD de validação e seguimos as normativas para validar.
Nos casos em que isso acontece será necessário fazer um mapeamento entre os valores dados do Sistema Acadêmico e os dados do JSON Schema.
Não, ele somente emite/registra diplomas de graduação.
O Diploma Digital é uma ação de inovação tecnológica para o ensino que busca modernizar o fluxo processual para a emissão e/ou registro de diploma de graduação, garantindo a integridade e interoperabilidade dos dados de forma totalmente digital.
Com a publicação da Nota Técnica e do XSD, as IES terão 2 anos para realizarem as adaptações necessárias para implementação do diploma em formato digital.
Não. Uma vez que existe uma assinatura em um documento, o seu conteúdo não pode ser mais alterado sob pena de se gerar um documento inválido.
Cada instituição tem um layout próprio e por isso ficam responsável por gerar sua representação visual. Vale lembrar que, no CONTEXTO DO RAP, o processamento da Representação Visual junto com os demais documentos é opcional no processo de emissão do Diploma Digital ficando a cargo de cada instituição decidir se vai fazê-la. O Serviço de Diploma apenas se encarrega de converter as representações visuais geradas para o formato de preservação PDF/A e preservá-las no RAP.
A RVDD é a Representação Visual do Diploma Digital, ou seja, é a interface entre o meio digital e o meio físico para o Diploma Digital, preservando as características dos diplomas emitidos pela Instituição de Ensino. Esta RVDD, apesar de não ser o diploma, permite que, com auxílio do QR Code ou do código de validação, possibilite a autenticidade do documento de forma rápida, prática e segura.
ATENÇÃO: Somente de posse do seu QR Code ou do código de validação do seu diploma será possível ter acesso ao seu XML do Diploma Digital.
A representação visual é de única responsabilidade da IES, e podem seguir gerando as representações visuais mesmo dos documentos enviados na versão anterior.
De acordo com o Art. 2º da Instrução Normativa nº 1/2020 do Diploma Digital:
§ 1º Para fins do disposto nesta Instrução Normativa, entende-se como:
I – IES emissora – Emissora é aquela que tem autorização para executar um curso e pode atestar a conclusão do currículo aprovado.
II – IES registradora – aquela que possui prerrogativa de registro de acordo com o Art. 48 da LDB e demais normas vigentes.
O Portal de Conformidade do Diploma valida somente o arquivos XML de diploma digital.
Documentação acadêmica e histórico não são validados pelo Portal.
A IES deve orientar aos alunos os mecanismos que ele terá para ter acesso aos arquivos XML e da Representação Visual do Diploma Digital (RVDD) se mesmo assim o aluno precisar, ele poderá ter direito a uma cópia simples de sua RVDD.
De acordo com a Portaria MEC nº 554/2019, é passível a cobrança de taxa quando o discente solicitar da IES a impressão de sua RVDD com a utilização de papel ou tratamento gráfico especiais desde que, não prejudique os mecanismos de acesso ao Diploma Digital.
Mas a IES deve alertar sobre a função de que este não é o seu diploma e sim uma interface para onde está armazenado seu Diploma Digital.
É preciso salientar também que a emissão e o registro do diploma digital estão incluídos nos serviços educacionais prestados pelas IES, não ensejando a cobrança de qualquer taxa aos graduados.
Sim.
Conforme previsto na Portaria MEC nº 554/2019, o Diploma Digital passa a compor o acervo acadêmico, estando submetido a legislação pertinente a esse tema.
A representação visual é de única responsabilidade da IES, e podem seguir gerando as representações visuais mesmo dos documentos enviados na versão anterior.
O processo continua o mesmo que vinha sendo realizado anteriormente ao Diploma Digital. Vale lembrar que as normas do processo de Registro passou por atualização recente.
Não, os documentos precisam estar na mesma versão.
Caso a equipe de integração possua certificados ICP-Brasil A1 ou A3 é possível utiliza-los para os testes, bastando apenas enviar os certificados para que a equipe de suporte da RNP os cadastre. O indicado são dois certificados, de preferência um pessoa física e um pessoa jurídica. Caso a instituição não possua certificados, durante o processo de implantação, podem solicitar certificados de teste junto a RNP. Embora esses certificados sejam baseados nos certificados ICP-Brasil, eles não possuem validade e servem apenas para testes.
Nesse caso, é preciso primeiro emitir a documentação acadêmica novamente e depois emitir o diploma (quando a documentação acadêmica estiver no status 10).
Os nós de segunda via, são utilizados geralmente para emitir uma via digital de um documento que foi emitido em papel.
Para a correção de dados em documentos revogados, os mesmos nós (sem ser segunda via) pode ser utilizados.
A solução atualmente não suporta múltiplos CNPJs.
Para garantir a integridade das informações prestadas e a correta formação dos arquivos XML, o Ministério da Educação irá disponibilizar o XML Schema Definition (XSD), com a estrutura do código e sua respectiva nota técnica, com orientações à IES para execução do diploma digital.
Considera-se XSD e nota técnica como normativos complementares a Portaria MEC nº 554/2019, cabe ao MEC manter em seu endereço eletrônico oficial um local para download dos referidos arquivos.
O XSD do MEC (e portanto o JSON Schema) prevê o reconhecimento com ou sem código EMEC, mas o preenchimento das informações restantes são obrigatórias.
O arquivo possui 2 planilhas (Lista de Assinantes e Grupo de Cursos). São planilhas de modelo e de exemplo que devem ser preenchidas com as informações dos assinantes. As planilhas devem ser enviadas para o atendimento da RNP junto das chaves públicas dos certificados.
Para cada Grupo de Cursos deve ser adicionado uma nova página ao arquivo;
Para assinantes que assinam todos os cursos da instituição, não é necessário associar o assinante a um conjunto de cursos. Nesse caso, a coluna “Grupo de Cursos que Assina” pode ser preenchida com o valor “Todos os cursos”;
As assinaturas realizadas no nó DadosDiploma são copiadas do XML da Documentação Acadêmica para o XML do Diploma Digital. Tecnicamente, isso indica que, quem assina o nó DadosDiploma, assina (mesmo que indiretamente) os dois documentos (Diploma e Documentação Acadêmica).
É recomendado que se utilize o RAP Sign Web (sempre na versão mais atual) para a extração das chaves públicas dos certificados, evitando que se tenha problemas durante esse processo.
Se os certificados PJ tiverem o mesmo CNPJ não é possível.
Se for necessário mais de um certificado institucional, eles precisam ter CNPJ's diferentes.
Nesse serviço, não é possível que o mesmo CNPJ seja vinculado a mais de um certificado institucional.
São necessários: Nome, CPF, RG ou OutroDocumentoIdentificacao. Para os demais elementos, que são obrigatórios em TDadosDiplomado, caso a IES Emissora não possua a informação, eles podem ser declarados como indisponíveis, aplicando-se o sufixo **"_Indisponivel"** a tag. Por exemplo, caso a IES não tenha conhecimento da DataNascimento do Diplomado, ela pode declarar este fato usando a tag DataNascimento_Indisponivel onde usualmente seria usada a tag DataNascimento.
De acordo com à Instrução normativa SESU Nº DE 15 DE DEZEMBRO DE 2020, a criação da Lista de Diplomas Anulados atende a organização do elemento estabelecido no Art. 8º, par § 4º inciso III da PORTARIA Nº 554, DE 11 DE MARÇO DE 2019:
2.5.2 A Lista de Diplomas anulados é um documento a ser criado pela IES Registradora a fim de expor a anulação de diplomas digitais em seus livros de registro e permitir a validação automática de tal fato através dos verificadores de conformidade de diplomas e dos sítios únicos de cada diploma.
2.5.3 A Lista de Diplomas Anulados deve ser utilizada para a determinação do estado do diploma no sítio único de cada diploma para a exibição de mensagens quanto a validade do diploma em questão.
De acordo com a instrução normativa de 15 de dezembro de 2020, segue o trecho:
2.5.5.5.1A data máxima de validade de uma lista de diplomas anulados será calculada primeiramente com a data declarada em DataMaximaProximaAtualizacao ou até no máximo 180 dias da data constante no carimbo do tempo da assinatura da lista.
De acordo com à instrução normativa de 15 de dezembro de 2020, segue trecho:
2.6.1 A especificação do Arquivo de Fiscalização do Diploma Digital atende ao Art. 9º par 5º da PORTARIA Nº 554, DE 11 DE MARÇO DE 2019.
2.6.2 Este arquivo somente deverá ser gerado por solicitação expressa do MEC e em atendimento aos procedimentos necessários ao MEC para o cumprimento de suas prerrogativas.
A Fiscalização por parte do MEC pode se dar em dois contextos diferentes. Uma no contexto da uma IES Emissora que pode ter seu acervo relativo ao diploma digital sendo averiguado. Outro contexto é o contexto de fiscalização de livros de registro o que acontece no âmbito de uma IES Registradora.
A nossa solução não contempla essa demanda da URL Institucional, a IES deve ser responsável por disponibilizar essa URL para o MEC.
O código curso e-MEC é único por curso, você pode validar o código curso no próprio site do e-MEC (https://emec.mec.gov.br/).
De acordo com a norma técnica, segue as informações: 2.5.2.3 O elemento CodigoCurriculo é um elemento de inclusão obrigatória que remete ao código único usado pela IES para referenciar o currículo internamente. Este código será usado para associar um Currículo Escolar a um Histórico Escolar.
2.5.2.3.1Considera-se para todos os efeitos, que uma vez publicado um Currículo Escolar, o mesmo não pode mais sofrer alterações, com exceção da inclusão de novas Equivalências em Unidades Curriculares. Quaisquer outras alterações exigem a criação de um novo Currículo Escolar, com um novo CodigoCurriculo único, a ser publicado pela IES.
Mais informações em: http://portal.mec.gov.br/diplomadigital/arquivos/in-05-versao-completa-anexos-i-ii-e-iii-v1.05.pdf
De acordo com a normativa : O Elemento TRegistroReqNSF deve ser usado única e exclusivamente para emissão de primeiras vias de Diplomas Digitais por Instituições de Ensino Superior que não pertencem ao Sistema Federal de Regulação e possui algumas flexibilizações em obrigatoriedades.
Uma possível solução para encontrar o id equivalente entre os documentos de ambientes diferentes seria utilizar a rota GET /documents filtrando pelo CPF no aluno.
Neste processo irá retornar apenas os dados da documentação acadêmica do aluno referenciado.
Em posse do groupId do aluno, é possível encontrar o id do diploma digital (que é o tipo de documento que é enviado para a geração do arquivo de fiscalização).
As titulações que possuem Pós-Doutorado devem ser preenchidos apenas com a Titulação de Doutorado. O pós-doutorado não é um título acadêmico, sendo a maior titulação existente é o doutorado ou o seu equivalente Ph.D. Segue esse link para uma melhor explicação sobre o título de Pós-Doutorado: https://www.gov.br/inpi/pt-br/servicos/a-academia/processo-seletivo/pos-doutorado#:~:text=Ao%20contr%C3%A1rio%20do%20que%20acredita,ou%20o%20seu%20equivalente%20Ph
A listagem ocorre aplicando o filtro no JSON dos documentos e os JSONs do histórico e diploma não possuem CPF (apenas o XML). De posse da documentação acadêmica do aluno é possível buscar pelos outros documentos utilizando o groupId pela rota GET /groups/{group_id}.
Sim era pra ser um preenchimento.
De acordo com as reformas que estamos realizando no histórico, irá permitir que o preenchimento seja mais de uma veza partir da 1.04.
O XSD do MEC não permite múltiplas ocorrências desse campo então a instituição tem autonomia para decidir enviar apenas a última informação.
O ideal é lançar tudo quando isso for permitido e por enquanto lança-se o último, ou conforme a autonomia das IES.
Este campo só vai ser obrigatório na situação quando ele estiver regular ou dispensado.
Os estudantes que tiveram seu diploma emitido em meio físico, a IES deve emitir um histórico escolar de simples conferência (Histórico emitido a qualquer tempo da relação do discente com a IES para acompanhamento do nível de integralização curricular). Obs.: Estes históricos não são alvo do normativo e podem ter padrão próprio de cada IES.
Alternativamente, é possível preencher o campo '"OutraSituacao' que não tem restrição de situações específicas.
Essas informações constam no JSON Schema da Documentação Acadêmica enviada junto com a documentação do serviço.
São necessários: Nome, CPF, RG ou OutroDocumentoIdentificacao. Para os demais elementos, que são obrigatórios em TDadosDiplomado, caso a IES Emissora não possua a informação, eles podem ser declarados como indisponíveis, aplicando-se o sufixo **"_Indisponivel"** a tag. Por exemplo, caso a IES não tenha conhecimento da DataNascimento do Diplomado, ela pode declarar este fato usando a tag DataNascimento_Indisponivel onde usualmente seria usada a tag DataNascimento.
Para a geração de uma segunda via, onde haja necessidade de alterar informações, é necessário revogar o documento original e depois reinserir os dados alterados novamente no Conector. A partir daí o processo é tratado como a geração de um novo documento, inclusive com a realização das assinaturas novamente. Para a segunda via de diploma físico, a partir da versão 1.02 dos XSDs, o MEC define a estrutura de dados da seguinte forma, em sua instrução normativa: "2.3.1.2. O Elemento RegistroSegundaViaReq deve ser usado única e exclusivamente para emissão de segundas vias Digitais de Diplomas emitidos em Suporte Físico. Este elemento possui estrutura idêntica à RegistroReq, entretanto flexibiliza a obrigatoriedade de alguns elementos de RegistroReq, como o histórico escolar em XML."
As instituições tem autonomia no preenchimento dos dados, podendo padronizar um docente para essas disciplinas.
Caso opte por contatar o MEC e solicitar revisão desse elemento no schema, pode fazê-lo através do e-mail:
suporteDiplomaDigital@mec.gov.br.
De acordo com a documentação do MEC, segue a seguinte explicação: 2.6.3.5 Os elementos obrigatórios DataInicioFiscalizacao e DataFimFiscalizacao devem trazer as datas de início e fim dos dados representados em DiplomasFiscalizados a fim de determinar o escopo temporal da resposta ao pedido de fiscalização. (http://portal.mec.gov.br/diplomadigital/arquivos/in-02-versao-completa-anexos-i-ii-e-iii-v1.04.1.pdf)
Para mais informações sobre duvidas de normativos, ou ajustes de conceitos entrar em contato com o MEC:
suporteDiplomaDigital@mec.gov.br
Os arquivos XML são e armazenados no volume do container ao decorrer das etapas de processamento do documento até estar valido, sendo esses arquivos dos tipos: generated, signed e registered.
Segundo a Portaria 1.095/2018 do MEC, é o "termo de responsabilidade da autoridade competente para o registro/expedição do diploma atestando a regularidade dos procedimentos realizados para o registro".
Dentro das possibilidades previstas nos XSDs do MEC (http://portal.mec.gov.br/diplomadigital/index.php?pagina=pacote-instituicoes), a instituição tem autonomia para preencher os dados como achar melhor. Não temos como adicionar valores que não estejam previstos no normativo do MEC. Caso o usuário tenha dúvidas sobre normativos ou ajustes de conceitos referentes ao Diploma Digital, devemos orientá-lo a entrar em contato com o MEC, no endereço abaixo:
MEC: suporteDiplomaDigital@mec.gov.br
O Conector é uma imagem docker que será instalado na infraestrutura da instituição. Esse componente é responsável por executar o processamento dos documentos relacionados a emissão do diploma digital. O Sistema de Gestão (ERP - Enterprise Resource Planning) da instituição cliente fornece os dados necessários para geração do Diploma Digital. O Conector é composto por um gateway na camada de persistência responsável pela comunicação com a base de integração da instituição cliente, um conjunto de daemons para processamento dos documentos e um API para comunicação.
Segue a ordem de assinatura: 1. Gerar/Assinar Documentação Acadêmica 2. Gerar/Assinar Histórico Escolar Final 3. Gerar/Assinar Diploma Digital 4. (opcional) Processar Representação Visual
Serão executados, nesse ambiente, um par de imagens Docker (uma com o conector e outra com o banco de dados) além de um volume para armazenar o banco. Uma Máquina virtual básica com uma CPU e 2Gb de RAM é suficiente. É recomendado 2 vCPU e 4 Gb de RAM para um processamento mais fluido.
Não é possível levantar mais de uma instância do Conector para o mesmo ambiente. Use somente 1 instância.
Os limites atuais são 25MB por documento (JSON completo), 50 MB por requisição (para envio de documentos em lote) e documento PDF anexo da documentação acadêmica 7MB cada.
Este processo não é indicado, pois além da restauração do banco, seria necessário fazer a restauração do volume do Conector onde os arquivos dos documentos ficam armazenados.
E, contudo, não seria possível utilizar algumas funcionalidades que dependem do serviço centralizado da RNP.
Não. Apesar do Docker virtualizar também para Windows é fortemente recomendado que a imagem seja utilizada no Sistema Operacional Linux. Isso é necessário para evitar problemas de configurações que diferem de um sistema para outro, principalmente, configurações de rede.
Sim. Para excluir um documento utilize a rota abaixo:
DELETE - /documents/{docId}
Para excluir um grupo de documento você pode usar a rota abaixo:
DELETE | /groups/{groupId}
Ela excluir um grupo de documentos da base de dados do Conector, incluindo todos os documentos nele contidos. A IES pode deletar o documento para casos em que deu algum erro no documento. Seja por preenchimento incorreto de dados ou mesmo de código. Pode deletar qualquer documento, mas é fortemente recomendado que o documento já esteja revogado. Quando for enviar novamente o documento, ele vai precisar gerar um novo yourNumber e um novo groupId para os documentos em questão. 🛑ATENÇÃO: essa operação apaga apenas os documentos do registro local, de forma que não deleta os documentos preservados no registro do Serviço RAP. Para a remoção dos documentos do registro do RAP é necessário revogá-los antes deletar os dados no Conector. A documentação da API de Comunicação pode ser acessada e testada em tempo real via swagger no próprio Conector Local na URL: http://<IP-DO-CONECTOR>:<PORTA>/docs. A porta padrão para a API de comunicação e para acesso a documentação é a 80. Ela pode ser alterada no arquivo de configuração do docker-compose.
ATENÇÃO: essa operação apaga apenas o documento do registro local, de forma que não deleta o documento preservado no registro do Serviço RAP. Para a remoção do documento do registro do RAP é necessário revogá-lo antes deletar os dados no Conector. Não é possível deletar um documento no status 10, caso esteja em outros status e necessário revogar.
Para revogar um documento ele deve está com o status válido(10) ou suspenso(11).
A revogação é uma operação irreversível e pode ser aplicada em documentos nos estados válido ou suspenso.
Sim, é possível.
Visto que na versão mais atual contempla o módulo de registro de diplomas para IES terceiras e para homologações internas.
O limite de envio de arquivo é do conector independente do local que ele está instalado em produção ou em homologação.
Existe um limite também dos tamanhos dos JSON e Documentos em lotes, sendo que os limites atuais são 25MB por documento (JSON completo) e 50 MB por requisição (para envio de documentos em lote).
É possível configurar individualmente (no arquivo docker-compose) a porta da API do Conector e do RAPSign WEB.
Uma vez que os documentos referentes ao diploma são gerados e assinados. Os dados são enviados para registro e preservação na nossa infraestrutura. O Diploma Digital fica armazenado no storage de preservação da RNP e uma cópia fica na instituição. A instituição pode optar por guardar a sua cópia local para consulta quando necessário por parte da comunidade e também, sempre que for necessário acessar via RNP sua cópia preservada. Vale lembrar que ao longo do tempo o Diploma digital precisará ser revalidado para manter suas assinaturas válidas. A ideia é que o próprio serviço de preservação da RNP facilite essa revalidação das assinaturas de forma automatizada quando do início dos processos futuros de re-notorização.
Para integração com API do Conector é recomendado usar uma biblioteca para Delphi que permita fazer requisições REST do tipo form-data para conseguir integrar com a API.
A IES é responsável por manter esse banco que fica sua infraestrutura. Esse banco possui informações de todo o histórico de cada documento, uma cópia local dos documentos, identificadores de cada documento, e etc. Caso a IES deseje limpar esse banco ou caso aconteça algum problema com ele, é necessário possuir as informações básicas de indexação dos documentos para acesso das informações e downloads desses documentos no Serviço da RNP.
Existe um componente do sistema, o Conector, responsável pela integração que é instalado na infraestrutura da instituição. Esse componente faz a integração entre o Sistema Acadêmico e o Serviço de Diplomas Digitais. O Conector é uma imagem docker de fácil instalação. Fora isso é necessário uso de uma aplicação (atualmente desktop) pelos responsáveis por assinar os documentos na instituição.
Sim. É possível que existam assinadores com certificados A3 em token e outros assinadores que tenham certificados A3 em nuvem.
Vale ressaltar que os certificados em nuvem também precisam ser do tipo A3.
O que NÃO é possível é que o mesmo assinador tenha mais de um certificado cadastrado no sistema.
Sim. Existe a gestão do documento do âmbito do registro de Diplomas Digitais. É feito validação da estrutura das informações fornecidas pela instituição, a gestão do fluxo de assinatura, armazenado o histórico dos documentos e fornecidas informações sobre a preservação dos mesmos.
Não. Mas o Conector fornece rotas que podem ser consumidas pela instituição para repassar as informações necessárias aos alunos.
É recomendado o uso de HTTPS em produção, mas o Conector é passivo em relação a isso.
A configuração de DNS e de certificados SSL são feitas normalmente no servidor HTTP (NGINX, Apache, etc) da instituição, geralmente via proxy reverso.
Também é recomendado a ativação (via docker-compose) da obrigação de autenticação JWT para uso das rotas do Conector.
A integração com o serviço é feita através de uma API Rest, bastando o sistema consumir as rotas disponibilizadas por essa API.
A integração com o serviço é feita através de uma API Rest, bastando o sistema consumir as rotas disponibilizadas por essa API.
As únicas TAGs que podem ser preenchidas são as especificadas no XSD divulgado pelo MEC e reproduzido no JSON Schema do serviço.
O serviço valida apenas a sintaxe dos dados.
A semântica das informações fica a critério de cada instituição que tem autonomia para preencher os dados da forma que melhor lhe atenda.
Atualmente o token tem duração de 15 minutos, mas é recomendado fazer o gerenciamento da expiração através da variável "exp" do token JWT decodificado (https://jwt.io/).
O Simulador de Integração apenas demonstra como a integração com o Conector pode ser feita, não é fornecido suporte para customização. Entretanto, segue as etapas que são realizadas para montagem da URL única do Diploma:
É capturado o securityCode do diploma digital que está na URL única
É feita uma requisição para o Conector na rota GET /documents/{securityCode} para se obter o groupId do documento
É feita uma requisição na rota GET /groups/{groupId} para se obter o docId dos 3 tipos de documento do grupo
Com o docId da documentação acadêmica e do diploma digital é feita uma requisição GET /documents/{documentId}/files/generatedDocument
É feito o parse do XML que é retornado dessa rotas e capturado os dados para preencher a tabela
Quando o usuário clicar para baixar representação visual é feito uma chamada para rota GET /documents/{documentId}/files/generatedDocument e o PDF é retornado para o usuário
Sim. Durante o processo de assinaturas dos documentos, o sistema segue todas as diretrizes requisitadas pelo MEC. Isso inclui a assinatura no padrão do ICP-Brasil e o uso de carimbo de tempo.
O carimbo de tempo destina-se a associar a um determinado hash de um documento assinado eletronicamente ou não, a uma determinada hora e data de existência.
Ressalta-se que o carimbo de tempo oferece a informação de data e hora de registro deste documento quando este chegou à entidade emissora, e não a data de criação deste documento.
No âmbito do diploma digital, é o carimbo de tempo que permite a preservação da segurança do diploma por prazo indeterminado desde que procedimento de guarda sejam observados.
Os dados que devem ser vinculado ao diploma digital e documentação acadêmica estão descrito no XSD dos respectivos documentos e podem ser consultados na Nota Técnica disponível em http://portal.mec.gov.br/diplomadigital na seção Instituições.
O Coletor de Assinaturas é uma aplicação Desktop e será instalado nas máquinas dos responsáveis na instituição por assinar os Diplomas e Documentação Acadêmica. É enviado, juntamente com a Documentação do Serviço de Diploma Digital, os links para downloads dos instaladores do Coletor de Assinaturas para o sistemas operacionais Linux, Windows e MacOS.
Reinicie sua aplicação e depois envie um documento para o Conector e quando ele estiver no status 4 tentar acessar novamente o RAPSign.
Esse processo forçará o Conector a acessar os assinadores cadastrados no serviço (caso tenha havido algum problema de acesso anteriormente).
Se já existir um documento no status 4, basta realizar um restart-processing para esse documento e tentar realizar o acesso novamente pelo RAPSign.
RAPSign WEB é uma aplicação WEB disponível para os sistemas operacionais:
Windows 10,
MacOS (versão Catalina ou superior) e
Linux (Ubuntu 18.04 e 20.04) em navegadores Google Chrome e Mozilla Firefox.
O Conector só finaliza o processamento do documento quando detecta que todas as assinaturas foram realizadas, de forma automática.
Sendo assim, o arquivamento só ocorrerá após a assinatura de todos os responsáveis.
No Simulador de Integração é possível verificar se o Conector está ativo e ter acesso a exemplos de uso das rotas da API do Conector. Outra função disponível é uma simulação da Gestão de Documentos de um aluno que vai ser diplomado, sendo possível gerar e inserir dados fictícios para geração da Documentação Acadêmica e Diploma Digital, além de enviar uma Representação Visual, por exemplo. Os documentos de cada aluno estão separados na interface para facilitar a gestão. As etapas de geração, assinatura e preservação dos documentos são as mesmas do processo manual descrito na documentação do serviço. O Rap Conector e o simulador acessam a mesma base de integração. Para mais informações você pode acessar a página de ajuda, segue abaixo o link:
Sim. O serviço já está preparado para que mais de um documento seja assinado conjuntamente. Para isso basta selecionar mais de um documento no Coletor de Assinatura no momento de assinar os documentos.
Para garantir que não ocorram erros é preciso revogar e depois deletar todos os documentos individualmente.
Revogação de um documento caso seja necessário cancelá-lo para nova re-emissão.
a. Geralmente um diploma revogado deve ter todos os seus arquivos revogados (XML da Documentação Acadêmica, XML do Diploma e Representação Visual);
b. Rota POST /documents/{docId}/revoke
Para cada documento relacionado ao diploma digital, é necessário configurar o processo de assinatura.
Cada documento possui um conjunto de regras relacionadas ao formato das assinaturas e responsáveis.
A ordem com que as assinaturas são realizadas é de responsabilidade da instituição.
As assinaturas, com certificados e-CNPJ, previstas na Instrução Normativa referente a emissão de diplomas digitais devem ser as últimas a serem realizadas em cada documento.
Os formatos de assinatura para os documentos relacionados do diploma digital já são previamente especificados dentro do Serviço Diploma Digital.
As instituições que aderiram ao serviço devem indicar no momento da adesão as informações para cadastro dos responsáveis pela assinatura de cada documento.
O RapSign WEB, a partir da versão 0.3.2, possui a funcionalidade de certificados em nuvem. Para configurar na sua instância, siga o Guia de Configuração de Certificados em Nuvem - RAPSign WEB.
A versão do Java requerida é o Java (versao jdk1.6.0_45).
Os certificados .pfx enviados para a IES são certificados digitais para utilização nos testes de assinatura de documentos, não são certificados SSLs.
A configuração dos certificados SSL (e conexões HTTPS) são realizadas pela IES diretamente no servidor HTTP da infraestrutura.
Sim. Pode ser configurado o grupos de cursos, para que cada assinante só assine os cursos do campus dele. Exemplo grupo de curso: Campus XPTO - dentro dele serão cadastrados os cursos e-mec do campus e no momento do cadastro do assinador será selecionado o campus que ele deve assinar.
O Histórico Escolar é o documento oficial que comprova a situação acadêmica do aluno referente ao seu rendimento escolar, no qual estão descritas as disciplinas do curso, local onde está matriculado/a ou esteve, e qual a nota e a situação referente a cada disciplina.
O Histórico Escolar Digital deve ser emitido a qualquer tempo para fins de comprovação da integralização curricular corrente, substituindo os históricos escolares tradicionais para todos os efeitos.
O Histórico Integral (Final) - é o histórico emitido quando é finalizada a relação do discente com a IES com validade jurídica, seja para emissão de diploma ou para transferência externa.
Este histórico pode ter padrão próprio de cada IES.
Já o Histórico Parcial - é o histórico emitido a qualquer tempo da relação do discente com a IES com fins de comprovação jurídica do nível de integralização curricular.
Este histórico pode ter padrão próprio de cada IES.
O histórico de Simples Conferência - é o histórico emitido a qualquer tempo da relação do discente com a IES para acompanhamento do nível de integralização curricular.
Este histórico pode ter padrão próprio de cada IES.
Sim.
O Histórico Parcial (não precisa estar atrelado a um diploma), porém essa etapa ainda está em desenvolvimento.
Sim, apenas históricos escolares sem o atributo ambiente, ou aqueles cujo atributo ambiente seja produção possuem validade jurídica.
O histórico que é gerado na Documentação Acadêmica é o histórico final (ou integral) e já está disponível na versão 0.16.0 do Conector.
Atualmente o conector não previu o armazenamento da representação visual do histórico escolar.
Será realizada uma análise sobre o desenvolvimento desta funcionalidade em versões futuras.
Vale ressaltar que este caso não gera impedimento pois o histórico pode ser gerado a qualquer momento já que todos os dados que o compõem estão registrados.
Segundo a norma, é obrigatório o envio do Histórico escolar.
O histórico Escolar Digital Final é gerado a partir da Documentação Acadêmica e ao solicitar a emissão do histórico é gerado de forma automática para ele.
Segue trecho da INSTRUÇÃO NORMATIVA SESu Nº , DE 15 DE DEZEMBRO DE 2020:
2.4.1 real A criação do XML de Histórico Escolar como documento avulso é a realização do Art 1º parágrafo 1º da Portaria 330/MEC/2018.
Representação Visual do Histórico Escolar (RVHE) com fidedignidade ao XML, e a disponibilização de uma URL para download do original XML para validação.
Sim há a necessidade de cadastro em um novo nó de assinaturas.
Referente aos Históricos, possuímos duas versões no conector:
0.16.0 (Documentação Acadêmica, Histórico Escolar Final, Diploma Digital e Representação Visual (opcional));
0.17.0 (Documentação Acadêmica, Histórico Escolar Final, Diploma Digital e Representação Visual (opcional) e Histórico Escolar Parcial (opcional)).
Para atualizar e necessário informar para qual versão gostariam de atualizar e se gostariam de assinar o Histórico Escolar Final com algum eCPF também.
Caso a resposta seja sim ao assinar com algum eCPF, preencha o arquivo "Cadastro de Assinadores - Modelo.xlsx" que se encontra no arquivo .zip em anexo e nos encaminhe apontando os assinadores do HistóricoFinal.
Sim, a partir da data para sua vigência será obrigatória a entrega. "Esse currículo veio para que futuramente possamos cruzar as informações do Histórico Escolar X Currículo Escolar Digital, justamente para a verificação de que a aprovação desse aluno está de acordo com a estrutura do curso. Foi definido também, dentro do Currículo Escolar, o uso obrigatório das etiquetas".
Assinadores do tipo pessoa física não assinam Histórico Parcial, apenas a IES com o CNPJ. (Obs.: Assinadores CPF conseguem assinar documentos Histórico Final).
A rota de validação não valida históricos parciais. Apenas históricos finais e outros documentos.
A validação necessária já é feita na geração pelo Conector.
De acordo com a norma técnica:
5.2.1 Os históricos digitais parciais devem possuir pelo menos uma assinatura digital institucional PJ, de acordo com o Padrão Brasileiro de Assinatura Digital.
A assinatura mínima é a de PJ não excluindo a assinatura PF para o Histórico Parcial.
Deve ser emitido o histórico parcial preenchendo o campo infHistoricoEscolarTransferencia, que na prática é emitir um Histórico de Transferência.
O relatório de aprovação é gerado pelo validador de diplomas (https://validadordiplomadigital.mec.gov.br/diploma), após escolher um arquivo .xml e verificar há o botão "Salvar relatório", que faz o download do relatório de aprovação.
Segue as seguintes informações a respeito do Histórico Escolar: 4 Orientações Acerca dos Históricos Escolares Digitais
4.1 Os históricos digitais integrais devem ser emitidos de acordo com as instruções deste anexo sejam eles emitidos de forma embarcada ao XML de Documentação para Emissão e Registro ou em arquivo próprios destacado de Históricos Escolar Digital.
4.1.1 Quando emitidos de forma destacada históricos digitais integrais devem possuir pelo menos uma assinatura institucional PJ de arquivamento (AD-RA) da IES emissora, sendo fortemente recomendado a inclusão de pelo menos uma assinatura PF da secretaria acadêmica em conjunto com a assinatura institucional.
4.1.2 As assinaturas nos históricos digitais integrais devem ser sempre feitas com certificados digitais A3 ou superior.
4.2 Os históricos digitais parciais somente podem ser emitidos de forma destacada e não devem ser embarcados no XML de Documentação para Emissão e Registro.
4.2.1 Os históricos digitais parciais devem possuir pelo menos uma assinatura digital institucional PJ de acordo com o Padrão Brasileiro de Assinatura Digital.
4.2.2 As assinaturas nos históricos digitais parciais podem ser feitas com certificados digitais A1 ou superior, dada a sua natureza transiente.
4.2.3 De acordo com o disposto no item 125.41 do anexo da PORTARIA N° 092, DE 23 DE SETEMBRO DE 2011 do Arquivo Nacional, sempre que houver a emissão de um histórico integral para o discente, todos os históricos parciais devem ser desativados através de eliminação das URLs únicas dos históricos digitais parciais.
4.2.3.1 É fortemente recomendado que a IES emissora desabilite as URLs únicas dos históricos digitais parciais anteriores a partir da emissão de um novo histórico parcial, evitando assim o uso de informações desatualizadas de integralização curricular.
O histórico de transferência é um tipo específico de histórico (tem diferenças para o histórico parcial e para o histórico final).
No Conector, esse tipo de documento é emitido usando o tipo histórico parcial mas preenchendo o campo infHistoricoEscolarTransferencia.
Para o caso do histórico de transferência é solicitada uma assinatura de arquivamento, já o histórico parcial comum é solicitada uma assinatura institucional.Para emissão do histórico final é necessário que a situação do aluno seja formado e que seja emitido a documentação acadêmica antes.
Por isso foi decido que, da lógica do serviço, o histórico de transferência fosse emitido com o tipo de histórico parcial.
Sim, é o histórico emitido a qualquer tempo da relação do discente com a IES com fins de comprovação jurídica do nível de integralização curricular. Esse histórico possui o documentType “1”, possui o docType "partial_academic_transcript" e está disponível para emissão a partir da versão 0.17.0.
As seguintes informações que podem ser preenchidas no campo ENADE (SituacaoENADE):
Segundo normativo do MEC 2.4.2.11 O elemento ENADE é um elemento obrigatório na definição do Histórico Escolar e deve conter informações referentes à participação do Aluno no ENADE. (http://portal.mec.gov.br/diplomadigital/arquivos/in-02-versao-completa-anexos-i-ii-e-iii-v1.04.1.pdf)
Habilitado
NaoHabilitado
Irregular
Não, seria o Histórico Integral (Final) (tipo 3), é o histórico emitido quando da finalização da relação do discente com a IES, com validade jurídica, seja para emissão de diploma ou para transferência externa. Esse histórico possui o documentType “3”, possui o docType "final_academic_transcript" e está disponível para emissão a partir da versão 0.16.0.
Não é possível por que o documento precisa estar assinado e validado.
É possível gerar os documentos após o status 8.
Tipo 3.
Para alunos que não finalizaram sua relação com a IES, porque evadiram ou pediram transferência, etc., deve ser emitido o histórico parcial.
● Histórico Parcial - é o histórico emitido a qualquer tempo da relação do discente com a IES com fins de comprovação jurídica do nível de integralização curricular.
Essa gestão é de responsabilidade da própria IES. Existe uma expectativa que, no futuro, exista uma validação de diplomas confrontando com o currículo (verificando, por exemplo, se cada aluno cumpriu os requisitos do curso descritos no XML do currículo). Então, nesse momento, os dois arquivos devem esta corretos e compatíveis.