Type de Reference em protNFe: o tipo do objeto referenciado
@TypenfeProc › protNFe › ds:Signature › ds:SignedInfo › ds:Reference › @TypeRevisão editorial em 15 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.
Type de Reference, em /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:Reference/@Type, é um atributo opcional do tipo anyURI. Na especificação XMLDSig ele pode informar o tipo do objeto referenciado. Não é o tipo de emissão da NF-e e não equivale a tpEmis.
Type informa uma categoria; URI localiza o objeto
O atributo URI é quem participa da identificação do recurso referenciado. Type não substitui URI e não faz o verificador localizar automaticamente infProt. No retorno fiscal, o grupo a assinar é definido por PR03/PR04 e PR90: as informações do protocolo identificadas por Id.
O XSD permite Type sem fixar um valor. Isso não significa que qualquer semântica fiscal possa ser inventada. A XMLDSig geral inclui categorias como Object, mas o schema específico de Signature da NF-e contém SignedInfo, SignatureValue e KeyInfo; não é uma licença para acrescentar um elemento Object ao protocolo.
Como interpretar presença e ausência
A ausência de Type é estruturalmente admitida. Não preencha um valor genérico para acabar com uma exigência de interface. Quando presente, preserve a URI exatamente como recebida e avalie seu significado no contexto da assinatura. Uma biblioteca não deve ignorar a URI do alvo só porque reconheceu um Type.
Também separe Type de SignatureMethod/@Algorithm: o primeiro descreve o objeto, o segundo identifica uma operação criptográfica. Nenhum dos dois é número de protocolo, ambiente ou status da nota.
Exemplo de investigação de uma exigência indevida
Considere uma integração que rejeita qualquer Reference sem Type antes mesmo de resolver sua URI. O XSD fiscal o declara opcional. Compare essa expectativa da integração com a resposta original e com o perfil aplicável; uma correção pode ser necessária no leitor, sem editar o documento recebido.
Outro caso: o software encontrou um Type conhecido e decidiu tratar a assinatura como válida, sem comparar DigestValue. O conhecimento da categoria não verifica integridade ou autoria. Execute a cadeia de referência, a verificação de SignatureValue e a avaliação de confiança.
Não há XML completo no exemplo, porque mostrar uma Reference real exige o alvo e o digest do protocolo original. O atributo deve ser lido no retorno, sem criar um valor para que a aparência do documento pareça mais completa.
Preservação da resposta
Type integra Reference, que integra SignedInfo. Alterá-lo pode mudar os bytes assinados. Se seu valor parece incompatível, registre o arquivo original, a versão do autorizador e a mensagem da biblioteca. Não substitua o atributo por tentativa. A situação fiscal continua dependendo dos campos de resposta e da consulta oficial, não da existência de Type.
Leituras relacionadas
- Reference — /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:Reference
- URI — /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:Reference/@URI
Fontes oficiais
- Schema XMLDSig NF-e/NFC-e — PL_010f_v1.04: SignatureValueType, SignedInfoType, ReferenceType, TransformsType e TTransformURI.
- NT 2025.002 RTC — 1.52: seção 5.1, p. 11; PR03–PR90, p. 13.
- XML Signature Syntax and Processing — 1.1: seções 3.2, 4.3, 4.4 e 6: processamento, referências, IDs e algoritmos.
Referência técnica para integração
- XPath completo
/nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:Reference/@Type- Namespace
Não informado- Leiaute
- 4.00 · PL_010e_v1.02
- Ocorrências no XSD
- 0–1 no contexto do elemento pai
- Tipo
- anyURI
- Preenchimento no catálogo
- Condicional
A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.