Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Suplemento, assinatura e protocolo

Type em Reference da NF-e: atributo opcional não define o alvo

@TypenfeProc › NFe › ds:Signature › ds:SignedInfo › ds:Reference › @Type

Revisão editorial em 15 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.

Type em Reference é um atributo opcional que pode descrever o tipo do objeto referenciado segundo XMLDSig. Ele não informa o modelo 55/65, a finalidade da NF-e ou o tipo de operação fiscal.

Caminho desta página: /nfeProc/NFe/ds:Signature/ds:SignedInfo/ds:Reference/@Type. O alias ds neste XPath representa o namespace http://www.w3.org/2000/09/xmldsig#; ele permite localizar o elemento, mas não exige esse prefixo na serialização fiscal.

Que relação existe entre Type e URI?

URI identifica os dados que serão processados; Type fornece uma indicação de tipo. O schema fiscal declara Type como anyURI opcional, sem enumeração ou valor fixo. Já URI é obrigatório, e o MOC determina a referência a infNFe pelo identificador precedido de #.

O XMLDSig geral define identificadores para objetos próprios como Object e Manifest. Isso não torna http://www.w3.org/2000/09/xmldsig#Object um preenchimento universal da NF-e: infNFe é um elemento fiscal, não um ds:Object. O exemplo fiscal do MOC não exige Type para referenciá-lo.

Declaração XSD do contexto.

A ausência de Type impede a validação?

Sua ausência é permitida pelo tipo específico. O verificador continua obrigado a resolver a URI correta, aplicar as transformações, conferir o digest e testar a assinatura. Não inferir Type não significa ignorar essas etapas.

Exemplo de diagnóstico: um emissor adiciona um literal de tipo “Object” apenas porque o viu em um modelo genérico XMLDSig. O primeiro ponto a conferir é a correspondência semântica com o alvo real; a mera aceitação lexical anyURI não atesta essa correspondência. Não é necessário acrescentar um tipo para preencher uma lacuna opcional.

XMLDSig: processamento e elementos.

Como investigar uma divergência relacionada ao atributo?

Compare o perfil fiscal, o conteúdo original e a configuração da biblioteca. Se o software exige um tipo específico, verifique de onde veio essa condição, em vez de alterar o XML recebido para satisfazê-la. Type pertence a SignedInfo; inseri-lo ou mudar seu valor após assinar pode modificar a representação protegida por SignatureValue.

Não se oferece XML completo de Reference porque faltariam o alvo real e o digest correspondente. O atributo não prova integridade, confiança ou autorização. A solução técnica é tornar geração e verificação coerentes com o perfil, preservando o documento original.

MOC: perfil de assinatura, pp. 53–56.

Fontes e contexto

Schema específico XMLDSig da NF-e — PL_010f_v1.04 / xmldsig-core-schema_v1.01.xsd; MOC — Visão Geral — 7.0; XML Signature Syntax and Processing — 1.1, Recommendation 11/04/2013; XML Schema Part 2: Datatypes — Second Edition, 28/10/2004.

Referência técnica para integração

XPath completo
/nfeProc/NFe/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
Opcional

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.