Resumo

  • Na RFC 9796, verified=true informa que a parte que incluiu aquele campo Call-Info verificou a informação representada nele. O dispositivo receptor ainda precisa confiar de forma autenticada nessa parte.
  • A afirmação vale para o campo correspondente, não para todos os dados, para a intenção do chamador, para a conversa ou para o resultado. A ausência do parâmetro tampouco é prova de fraude.
  • O parâmetro integrity verifica a igualdade de bytes de um recurso. Origem, atualidade, disponibilidade, exibição, atenção humana e legitimidade permanecem perguntas separadas.

Há uma escolha arquitetural escondida em todo distintivo de confiança: levar a prova até o dispositivo ou levar apenas a conclusão. A primeira opção exige mais capacidade no terminal. A segunda transfere poder para o intermediário que interpreta a prova. RFC 9796 trata da segunda opção sem fingir que o intermediário desapareceu.

O documento define Rich Call Data no cabeçalho SIP Call-Info, com call-reason, verified, integrity e o propósito jcard. A expressão verified=true tem sujeito e objeto precisos. Ela diz que a parte que colocou aquele campo realizou uma verificação bem-sucedida da informação ali representada. A confiança do destinatário depende da relação confiável com a parte da qual recebeu a requisição.

Portanto, “verificado” não é uma propriedade universal da chamada. É um testemunho emitido por um ator, sobre um campo, para um par que aceita sua autoridade.

A economia do terminal custa uma transferência de custódia

RFC 9795 protege Rich Call Data e resumos de recursos por meio de PASSporT. RFC 8225 define o token PASSporT, na família estrutural do JWT de RFC 7519, enquanto RFC 8224 integra a identidade STIR ao SIP.

Um provedor de terminação pode validar assinatura, caminho de certificado e afirmações antes de uma interface de usuário-rede. Um aparelho simples talvez não consiga validar o PASSporT. A RFC 9796 permite que o provedor traduza resultados aceitos em Call-Info e os entregue a um dispositivo autenticado e confiável.

O ganho é real: não é preciso replicar toda a infraestrutura no aparelho. O custo também é real: o aparelho observa a declaração do provedor, e não o ato criptográfico original. A auditoria precisa conservar ambos.

Uma cadeia defensável distingue: dados candidatos; presença do PASSporT; validação da assinatura e do certificado; comparação de afirmações e resumos; decisão de política; identidade do tradutor; campo produzido; autenticação do par UNI; recuperação do recurso; igualdade do hash; decisão de renderização; visualização humana; ação; legitimidade posterior; resultado do serviço.

Se o parâmetro verified não estiver presente, o receptor deve assumir que a informação correspondente não foi recebida e verificada pelo processo da RFC 9795. Isso não torna a chamada fraudulenta. Apenas impede que o sistema reivindique esse recibo específico.

A ficha mistura elementos que não podem emprestar autoridade uns aos outros

RFC 3261 define SIP e Call-Info. Um nome comum em From pode ser ignorado ou substituído e não é autenticado apenas por existir. A RFC 9796 oferece uma forma explícita de transportar resultados limitados de verificação.

O jCard vem da RFC 7095, com sintaxe JSON apoiada pela RFC 8259. O perfil RCD restringe a representação a um objeto de entidade e exige consistência entre nomes, fotos, logotipos, From, P-Asserted-Identity e ícones sobrepostos. Essa consistência é necessária porque o cartão é uma montagem, não uma afirmação indivisível.

O conteúdo pode estar em uma URI data:, em uma parte MIME apontada por cid: conforme a RFC 2392, ou em outra fonte cuja integridade seja validável, como HTTPS associado a um domínio validado. Conteúdo incorporado, conteúdo em outra parte da mensagem e conteúdo remoto têm guardiões e falhas diferentes.

Também é possível usar uma URI data: nula com purpose=jcard para marcar um nome de exibição verificado. A concisão não amplia a certeza. Mesmo um sinal mínimo precisa preservar quem o inseriu e qual representação ele qualificava.

Um hash fecha uma comparação, não toda a investigação

integrity liga um algoritmo e um resumo ao recurso indicado por URI. As implementações devem suportar SHA-256, SHA-384 e SHA-512. Se o hash calculado corresponde ao declarado, os bytes recebidos são os bytes nomeados pela afirmação.

O resultado não identifica, sozinho, quem controlava o arquivo, se ele continua atual, se estava disponível durante o toque, se a política autorizou sua exibição, se o usuário o viu ou se a pessoa da imagem estava realmente na ligação. Integridade de conteúdo não é legitimidade de interação.

O call-reason também deve ser lido em seu tamanho real. É opcional, curto, pode ser truncado e não tem exibição garantida. A maneira como o chamador o define está fora do escopo. Um motivo exibido pode orientar uma decisão; não prova que o motivo seja verdadeiro.

A RFC 7852, ao tratar do namespace de prioridade de recursos SIP, ajuda a ver o padrão: uma marca protocolar tem semântica delimitada e depende de autorização ao redor. Não pode absorver toda a confiança só porque seu nome parece oficial.

A versão verificada precisa sobreviver ao caminho sem ganhar novos autores

A RFC 9796 pede uma única versão consistente de RCD em Call-Info. Participantes adicionais não devem alterá-la nem adicionar campos conflitantes. Sem STIR ou outra proteção, não se pode supor que modificações em redes interconectadas não confiáveis sejam detectadas.

Se um intermediário troca a foto ou o nome depois da verificação, muda o objeto da afirmação. Qualquer transformação legítima deve deixar recibos: entrada, política, verificador, transformador, campo de saída, destinatário e tempo.

Os materiais públicos estabelecem a norma, não sua adoção. O texto, o XML, a página de informação, as erratas, o histórico do IETF e o registro de parâmetros SIP da IANA permitem inspecionar o contrato. Nenhum deles prova implementação por uma operadora ou aparelho específico.

O princípio do código em execução pergunta qual componente executou a checagem. A especificação inicial mínima estabelece um piso de coordenação sem transformar decisões locais em garantia global. E separar as camadas de realidade impede que registro normativo, validação criptográfica, tela, crença e resultado sejam tratados como um só fato.

O mérito da RFC 9796 é permitir delegação útil. Sua leitura responsável é conservar o limite dessa delegação. O aparelho pode confiar no insertor; o sistema não pode esquecer quem foi o insertor.

Fontes