Algorithm de CanonicalizationMethod: URI C14N no protocolo
@AlgorithmnfeProc › protNFe › ds:Signature › ds:SignedInfo › ds:CanonicalizationMethod › @AlgorithmRevisão editorial em 15 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.
Algorithm, no CanonicalizationMethod da assinatura de protNFe, é o atributo que identifica a canonicalização aplicada a SignedInfo. O caminho completo é /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:CanonicalizationMethod/@Algorithm.
Qual valor conferir
O schema fiscal de PL_010f_v1.04 declara tipo anyURI, uso obrigatório e valor fixo http://www.w3.org/TR/2001/REC-xml-c14n-20010315. O tipo amplo não libera valores alternativos: a restrição fixed também precisa ser atendida. A URI é o nome padronizado de Canonical XML 1.0 sem comentários.
Não acrescente #WithComments, não substitua por canonicalização exclusiva e não mude http para https como ajuste cosmético. Essas sequências podem identificar métodos diferentes ou não corresponder ao valor fixo do perfil. Identificar um algoritmo não exige seguir um endereço remoto recebido no XML.
Como reconhecer o atributo no XML
Fragmento sintético parcial, sem documento fiscal ou assinatura operacional:
<CanonicalizationMethod xmlns="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
O atributo pertence ao elemento XMLDSig, mas não tem namespace próprio declarado por prefixo. Uma consulta deve localizar o elemento pelo namespace e então ler @Algorithm. A forma algorithm não é equivalente: XML diferencia maiúsculas.
O que comparar quando há erro
Primeiro separe três atributos homônimos: este define canonicalização de SignedInfo; DigestMethod/@Algorithm define o resumo da referência; SignatureMethod/@Algorithm define a operação criptográfica da assinatura. O valor rsa-sha1 em CanonicalizationMethod é uma troca de contexto, não uma opção de canonicalização.
Num exemplo de diagnóstico, o validador estrutural rejeita um método com sufixo #WithComments, enquanto uma biblioteca genérica o aceita. Os testes respondem a perguntas diferentes: suporte genérico não prova conformidade com o schema fiscal. Confira o pacote aplicável e o arquivo original; corrija a seleção de schema ou a leitura da biblioteca quando comprovadamente erradas. Se a divergência veio da resposta recebida, preserve-a e investigue sua origem. Não altere a URI dentro da resposta para forçar uma verificação. A declaração correta tampouco demonstra que o cálculo da assinatura foi executado com sucesso.
Leituras relacionadas
- CanonicalizationMethod — /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:CanonicalizationMethod
- Algorithm — /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:Reference/ds:DigestMethod/@Algorithm
Fontes oficiais
- Schema XMLDSig NF-e/NFC-e — PL_010f_v1.04: SignatureValueType, SignedInfoType, ReferenceType, TransformsType e TTransformURI.
- 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:CanonicalizationMethod/@Algorithm- Namespace
Não informado- Leiaute
- 4.00 · PL_010e_v1.02
- Ocorrências no XSD
- 1–1 no contexto do elemento pai
- Tipo
- anyURI
- Preenchimento no catálogo
- Condicional
- Valor fixo no XSD
- http://www.w3.org/TR/2001/REC-xml-c14n-20010315
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.