XPath em Transform do protocolo: estrutura e limites do perfil

XPath, neste artigo, é o elemento XMLDSig localizado em /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:Reference/ds:Transforms/ds:Transform/ds:XPath. Ele não é o caminho que a Biblioteca usa para identificar um campo. É um possível conteúdo estrutural de Transform.

O que o XSD permite e o que o algoritmo permite

TransformType declara uma sequência de XPath opcional e repetível: o conjunto pode estar ausente e pode conter várias ocorrências. Cada XPath tem tipo string. A indicação 1..1 do elemento, vista isoladamente, não elimina o minOccurs=0/maxOccurs=unbounded da sequência que o envolve.

Por outro lado, Algorithm de Transform é restringido por TTransformURI a enveloped-signature e C14N 1.0. A URI da transformação XPath geral não integra essa enumeração. Logo, a presença estrutural deste filho não autoriza instalar um filtro XPath arbitrário na assinatura fiscal.

Como distinguir expressão, localização e execução

O caminho editorial identifica onde procurar o elemento. O texto dentro de XPath, caso exista numa resposta, é outra informação. Sua eventual interpretação depende do algoritmo da transformação e de seu perfil. Validar que esse texto cabe em xs:string não valida a expressão como programa nem demonstra que ela foi usada na verificação.

O prefixo ds no caminho é um alias do namespace http://www.w3.org/2000/09/xmldsig#. Um integrador deve procurar pelo namespace, não exigir que o arquivo use literalmente esse prefixo. Não reserialize a resposta assinada para trocar nomes de prefixos.

Fragmento lexical e cenário de diagnóstico

O trecho sintético a seguir mostra apenas um valor string reconhecível; não configura uma transformação XPath permitida e não tem validade operacional de assinatura:

<XPath xmlns="http://www.w3.org/2000/09/xmldsig#">self::node()</XPath>

Não se deve inserir esse trecho em um protocolo. Ele demonstra que a declaração estrutural do filho não decide qual método o executa.

Se uma biblioteca exige esse filho em todos os Transform, compare sua configuração com o XSD: as etapas C14N e enveloped-signature não passam a depender de uma expressão só porque TransformType contém uma declaração XPath. Se uma resposta desconhecida contém parâmetros inesperados, preserve-a, valide contexto e perfil e examine o comportamento do verificador com segurança. Não execute expressões arbitrárias nem acrescente um filtro para fazer o digest coincidir.

Qual é o próximo passo seguro?

Registre a cadeia recebida, os Algorithms e o erro exato. Confirme com o perfil fiscal e a documentação da implementação como cada método trata seu conteúdo. Uma falha estrutural, uma expressão não suportada e um digest divergente são diagnósticos distintos. A conferência deve preservar o objeto assinado e nunca substituir a análise da assinatura, da confiança e do status oficial.

Leituras relacionadas

• Algorithm — /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:Reference/ds:Transforms/ds:Transform/@Algorithm
• Transforms — /nfeProc/protNFe/ds:Signature/ds:SignedInfo/ds:Reference/ds:Transforms

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.