Resumo

  • O rascunho JMAP Enhanced Result References permite usar valores de uma resposta anterior em propriedades, PatchObjects e FilterConditions posteriores, por JSON Pointer ou JSON Path opcional.
  • Um valor pode ter cardinalidade e tipo corretos e ainda pertencer à conta, ao tenant ou à finalidade errada. A resolução comprova fluxo de dados, não escopo autorizado.

A primeira chamada encontrou uma caixa postal e devolveu seu identificador. A segunda montou um Email/query e usou uma referência de resultado no campo de filtro. O servidor localizou a resposta anterior, avaliou o caminho e obteve uma única string. Tudo parecia suficientemente preciso.

Mas identificadores só adquirem significado dentro de um domínio. A mesma forma pode aparecer em contas diferentes; um serviço com visibilidade administrativa pode observar objetos que o fluxo normal jamais deveria misturar. O filtro recebeu um dado válido, porém não carregou a prova de que aquele dado pertencia ao universo da consulta.

Esse é o limite central do JMAP Enhanced Result References. A revisão 02 é de 21 de junho de 2026 e expira em 23 de dezembro de 2026. No corte da pesquisa, era um Internet-Draft ativo do grupo de trabalho JMAP na trilha Standards Track. Não é RFC final, certificado de implementação nem levantamento de adoção.

O texto amplia as referências de resultado do RFC 8620. Métodos em uma mesma requisição JMAP são executados em sequência. Uma chamada posterior pode indicar a anterior com resultOf e name, e selecionar dados dos argumentos da resposta por path. A extensão permite colocar essas referências em propriedades de /set, em valores de PatchObject e dentro de FilterCondition de /query. JSON Path é opcional e complementa JSON Pointer.

O ganho é composição. O risco é tratar composição como jurisdição.

O filtro conhece uma forma, não uma conta

Em /query, uma propriedade de FilterCondition pode receber uma referência pelo nome com prefixo #. Isso permite, por exemplo, obter dinamicamente um ID de caixa postal e usá-lo para filtrar mensagens. Condições aninhadas também são processadas recursivamente.

Se a referência não resolve, a consulta inteira falha com invalidResultReference. Se o filtro traz ao mesmo tempo a propriedade literal e a versão com #, a ambiguidade produz invalidArguments. Depois da resolução, o valor precisa corresponder ao tipo esperado pela propriedade de filtro.

Esses controles são importantes. Eles não respondem se a caixa postal pertence à conta ativa, se foi selecionada sob a mesma identidade ou se o operador tinha mandato para reutilizá-la naquela finalidade. Uma string continua sendo string em qualquer tenant.

O vínculo de domínio precisa ser verificado fora da mera tipagem. O recibo defensável inclui conta de origem, principal, método, expressão, conta de destino, propriedade de filtro e decisão de autorização. Sem esses campos, o sistema consegue explicar como o texto chegou ao filtro, mas não por que devia governar a busca.

Também é preciso observar o efeito. Uma expressão barata pode alimentar uma consulta ampla. O custo do seletor não mede quantos objetos o filtro examina ou revela. Operação e segurança devem correlacionar as duas etapas.

Cardinalidade impede preferências inventadas

JSON Path pode produzir zero, um ou muitos nós. Para um destino primitivo ou de objeto único, um nó vira o valor, zero vira null e mais de um gera invalidResultReference. Para arrays, zero vira [] e os nós encontrados formam a lista na ordem do RFC 9535. Para mapas, zero vira {} e somente um objeto compatível é aceito.

A regra de um nó para um campo escalar preserva uma incerteza valiosa. Se a expressão encontra três IDs de caixa postal, escolher o primeiro transformaria ordem estrutural em prioridade. Nada garante que o primeiro seja o correto, o mais recente ou o autorizado.

O aplicativo pode refinar a fonte, pedir uma lista, apresentar escolhas ou aplicar uma política explícita. Não deve esconder a ambiguidade para manter a automação verde.

Zero resultados também exigem julgamento. null pode limpar uma propriedade. [] pode significar que nada deve corresponder ou que todos os membros devem ser removidos. {} pode representar ausência de ajustes ou substituição por um mapa vazio. A regra define formato, não consequência.

JSON Pointer expõe outra diferença: um caminho exato sem wildcard que não existe é erro, enquanto uma seleção com wildcard sem correspondências pode produzir um vazio tipado. Trocar um ponteiro preciso por uma expressão mais larga para evitar falhas pode alterar o efeito da ausência.

O tipo certo não corrige a semântica

Depois da resolução, /set rejeita tipos incompatíveis como invalidProperties; /query usa invalidArguments. O rascunho adverte contra converter strings em números ou booleanos e contra serializar objetos complexos em texto apenas para satisfazer o destino.

A recusa preserva o desacordo entre contratos. A string "01" pode ser um código; o número 1, uma quantidade. Converter um no outro não é higiene de dados, mas interpretação. Essa interpretação precisa de regra e responsável.

Mesmo sem coerção, um valor bem tipado pode ser semanticamente inadequado. Um blobId pode apontar para conteúdo privado. Uma lista de pessoas pode ter sido reunida para análise interna, não para distribuição. Um booleano pode refletir uma política revogada.

Por isso, validação de tipo, validação de domínio e autorização devem aparecer separadas. Tipo responde “qual é a forma?”. Domínio responde “a que espaço isso pertence?”. Autorização responde “quem pode usar isso para este efeito?”. Um único indicador de sucesso apaga exatamente a pergunta que ainda está aberta.

Uma camada ignorante pode ser uma boa camada

O rascunho admite uma camada sintática intermediária que opera sobre JSON opaco. Ela aplica JSON Pointer ou JSON Path sem conhecer tipos de método, propriedades ou semântica. A camada de execução interpreta o resultado conforme a definição do destino.

Essa separação reduz acoplamento. Um gateway pode resolver referências de modo comum para várias famílias JMAP. Também produz uma declaração probatória estreita: a expressão aplicada à resposta produziu tais nós. O gateway não pode concluir que eles representam a caixa postal que a organização pretendia consultar.

A disciplina de camada fina de Heng Lu serve como freio. Participar do transporte não concede mandato. Anunciar a capacidade urn:ietf:params:jmap:refplus demonstra que o servidor compreende a extensão; a indicação de jsonPath demonstra suporte à linguagem. Nenhuma delas autoriza todas as transferências possíveis.

O registro de auditoria deve atravessar as camadas sem fundi-las. Guardar resultOf, nome, caminho, cardinalidade e tipo resolvido; depois propriedade de destino, validação, principal e autorização. Preservar apenas a consulta final elimina a origem da influência.

Dados podem cruzar contextos sem mudar de tipo

Imagine que uma resposta de Email/get contenha o identificador de um anexo reservado. Uma chamada posterior insere esse valor em um objeto compartilhado. O usuário pode ter permissão para ler o e-mail e editar o objeto, mas não para publicar o anexo por meio dele.

Ler e escrever são capacidades locais. A transferência entre os dois contextos é uma terceira decisão. Sistemas de suporte, contas administrativas e fluxos multitenant tornam essa distinção especialmente importante, porque um mesmo processo possui visibilidade ampla em uma etapa e um público diferente na outra.

O rascunho alerta para vazamento entre contextos e recomenda que logs registrem quais dados foram derivados de referências. O controle útil compara visibilidade da fonte e audiência do destino no momento da operação. Uma política genérica de “referências habilitadas” é larga demais.

O mesmo vale para filtros. Um ID não precisa ser copiado para um objeto público para causar impacto. Alimentar uma busca em contexto errado pode revelar contagens, existência, metadados ou resultados. A fronteira deve cobrir leitura e escrita.

Cache precisa carregar a época da permissão

Resolver caminhos parece uma operação naturalmente cacheável. A mesma resposta e expressão geram o mesmo valor. Só que a possibilidade de usar esse valor depende de identidade, conta e controle de acesso.

Se um usuário perde acesso depois da primeira avaliação, reutilizar o resultado mantém a correção estrutural e perde a legitimidade. O rascunho exige que caches não sejam compartilhados entre usuários ou contextos de segurança e que mudanças de ACL causem invalidação.

Uma chave robusta inclui principal, conta, permissões relevantes e época de política. Em fluxos sensíveis, inclui o contexto de destino. O log distingue avaliação nova de reutilização e registra por que a entrada ainda era válida.

Tempos de resposta também podem revelar se um caminho existe em outro contexto. Isolar os bytes sem controlar diferenças observáveis de cache deixa um canal lateral disponível.

Um acerto de cache só prova que a chave encontrou uma entrada. A qualidade da prova depende do que a chave escolheu lembrar.

JSON Path consome orçamento

JSON Pointer segue uma rota simples. JSON Path oferece filtros, wildcards e descida recursiva. Em respostas grandes, uma expressão pode criar listas enormes e consumir CPU e memória. Cadeias de referências e cópias aninhadas aumentam o custo.

O servidor precisa limitar complexidade, tempo, tamanho da lista, quantidade de referências, profundidade e custo acumulado. Ao atingir o limite, deve rejeitar com erro visível, não truncar silenciosamente. Truncar muda o conjunto selecionado e pode fabricar uma falsa singularidade.

O parser de JSON Path é parte da superfície de ataque. Biblioteca mantida, correções, isolamento e testes adversariais são controles centrais. Um pico de invalidResultReference por orçamento pode indicar abuso, crescimento inesperado da resposta ou expressão cliente que se tornou ampla demais.

Aumentar o limite automaticamente não resolve a causa. Pode transformar pressão de recursos em consulta de grande alcance, exatamente quando o filtro dinâmico já carece de contexto.

A evidência precisa sobreviver ao resultado

Uma referência bem-sucedida prova que a resposta indicada foi localizada e a expressão avaliada. As regras de cardinalidade mostram como os nós viraram valor. A validação confirma o tipo declarado. Nenhum desses fatos, isoladamente, prova procedência de negócio, atualidade, pertença à conta ou autoridade sobre o destino.

Código em execução deve testar zero, uma e múltiplas correspondências; ponteiro exato ausente e wildcard vazio; IDs de mesma forma em contas diferentes; mudança de ACL; filtro aninhado; expressões caras; transferência de conteúdo privado. Depois, a equipe deve reconstruir o efeito final a partir da trilha, não da memória dos desenvolvedores.

O filtro recebeu o ID certo no sentido mais estreito: uma string selecionada corretamente. O incidente nasceu quando essa verdade local foi promovida a uma afirmação global sobre conta, finalidade e mandato. Referências melhoradas tornam o encadeamento mais poderoso. Elas não tornam o contexto opcional.

Fontes