Um destinatário por transação é crédito de largura de banda, não limite global

Resumo

• O limite de um destinatário por transação faz o solicitante gastar largura de banda comparável à que o relay gastará ao pedir consentimento. É um freio de amplificação, não um limite agregado nem prova de intenção legítima.
• A resposta HTTP 202 aceita a manipulação para processamento. O destinatário permanece pendente até que um permission document delimitado por sender, target URI e recipient URI seja autenticado e instalado na translation logic.
• O 470 Consent Needed, o refresh e o Trigger-Consent mantêm outras fronteiras: lista indivisível, validade e revogação. Nenhum desses recibos prova fan-out correto, entrega, atenção humana ou cessação após o deny.

O relay também pode ser um amplificador

Uma lista transforma uma entrada em várias saídas. Esse é o serviço esperado, mas também é uma superfície de multiplicação. Se um cliente pudesse adicionar mil endereços numa única operação curta, o relay poderia responder produzindo mil MESSAGEs de solicitação de consentimento.

O RFC 5360 remove essa vantagem direta. Para XCAP, cada transação HTTP pode adicionar no máximo um destinatário. Para o uso de REGISTER descrito pelo framework, cada transação também pode acrescentar no máximo um contact. Assim, quem propõe muitos destinos precisa gerar muitas requisições.

É útil pensar nisso como crédito de largura de banda. Cada pedido compra no máximo uma solicitação correspondente. A regra não mede moralidade, não identifica automaticamente um atacante e não impõe um teto global por hora.

Um agente ainda pode abrir muitas transações, distribuir contas, variar target URIs ou espaçar tentativas. O relay ainda precisa de orçamento por principal, por alvo, por destino e por período, além de detectar retries que recriam tráfego.

O recibo operacional deve registrar o principal autenticado, o target, o recipient proposto, bytes de entrada, saída esperada, taxa e decisão. Um 409 ou 403 mostra que aquela operação foi recusada; não prova que o sistema inteiro ficou abaixo de um nível seguro.

HTTP 202 não gasta o consentimento do destinatário

No fluxo clássico, A pede ao relay que adicione B. O serviço aceita o trabalho com HTTP 202 e coloca B em estado pending. Esse código significa que a manipulação entrou no processamento assíncrono.

Ainda faltam a solicitação entregue a B, a decisão de B, a autenticação dessa decisão, a instalação do estado, a correspondência em uma chamada posterior e a criação do pedido de saída. A palavra “accepted” não pode atravessar essas fronteiras.

O pacote de eventos Pending Additions existe porque o resultado chega depois. Os estados pending, waiting, error, denied e granted contam histórias diferentes. Se B estiver offline e não houver store-and-forward, até o pedido de permissão pode falhar.

Guarde o manipulation ID, o target, o recipient, a resposta, a versão do estado pending e cada NOTIFY posterior. O evento que muda para granted deve apontar para o documento e para o método de autenticação que sustentam a mudança.

Uma interface que mostra apenas “adicionado” mistura a autoridade do administrador para propor com a autoridade de B para aceitar. O sistema pode ter processado corretamente a primeira e ainda não possuir a segunda.

A permissão fica junto da translation logic

O relay recebe uma requisição dirigida a uma target URI e a converte em uma ou mais recipient URIs. Pode operar como proxy, B2BUA ou arquitetura híbrida. Registro, lista e configuração local podem participar do mapeamento.

É nesse ponto de execução que a permissão precisa existir. Uma anotação no cadastro ou um checkbox na tela administrativa não governa, por si, as futuras requisições de saída.

Enquanto o recipient não consentir, ele deve ser ignorado pela tradução. Depois do grant, o estado instalado precisa ser consultado para cada uso aplicável. Se a versão do mapa mudou, o relay deve mostrar qual versão encontrou e por que o pedido estava dentro do escopo.

Para auditoria, uma captura da edição comprova somente a proposta. Um clique autenticado comprova uma decisão delimitada. O runtime match precisa unir sender, target, final recipient, versão da permission e identificador da saída.

Quando um B2BUA termina uma mensagem e cria outra, sua custódia é diferente da de um proxy. O inventário deve nomear o papel, a versão da lógica e cada ponto em que uma identidade foi alterada ou reafirmada.

O administrador da lista não pode oferecer outra pessoa

O cliente que modifica a lista precisa ser autenticado e autorizado. Sem isso, qualquer ator poderia reconfigurar o relay. Mas credenciais válidas para administrar a lista não dão ao titular poder sobre o endereço de B.

O RFC 5360 preserva as duas decisões. A primeira pergunta se A pode propor a alteração. A segunda pergunta se B permite que aquele relay traduza tráfego para sua URI naquele contexto.

Registre quem autenticou A, qual política autorizou a proposta, qual identidade de B foi consultada, o que foi exibido a B e como a resposta foi autenticada. A frase “membro adicionado por usuário autorizado” apaga o mecanismo mais importante do framework.

Em listas compartilhadas, possuir o nome coletivo, operar o servidor e ter permissão dos recipients são fatos diferentes. Um grupo não absorve a vontade dos seus membros.

Essa separação também protege o administrador. Ela deixa claro até onde vai sua decisão e impede que um resultado posterior seja atribuído retroativamente a uma simples edição.

Permission document é uma tupla, não um sim genérico

O documento descreve sender, original recipient ou target URI, final recipient URI e as capabilities para grant e deny. Esses campos delimitam a tradução autorizada.

O sender pode ter escopo amplo e o target pode admitir wildcard no modelo. O final recipient não pode ser wildcard. A assimetria impede que uma anuência abstrata seja usada para destinos futuros não apresentados.

A sintaxe, porém, não garante entendimento. A parte legível mostrou os wildcards? Correspondia ao conteúdo de máquina? O target era um alias que depois foi apontado para outro serviço? A UI explicou que o grant poderia cobrir mais de um sender?

Conserve os bytes exatos, hash, versão do formato, identidade do relay, sender, target, recipient, hashes das capabilities e hash da apresentação humana. Um novo pedido deve ser comparado com esse escopo congelado.

Se o sistema guarda apenas consented=true, não será possível reconstruir a quem, a quê e por quanto tempo a decisão se aplicava.

Uma capability precisa ser usada pelo principal correto

O recipient responde com SIP PUBLISH ou HTTP GET de corpo vazio para a URI de grant ou deny. O corpo vazio não torna a ação sem contexto: a capability contém o vínculo com uma permissão específica.

O relay deve verificar que o originador é o dono da final recipient URI. O RFC discute SIP Identity, P-Asserted-Identity dentro de um domínio confiável, SIP Digest quando há segredo compartilhado e return routability.

Esses métodos não produzem a mesma evidência. Uma asserção de domínio depende da fronteira administrativa. Digest depende do segredo e do desafio. Uma identidade assinada depende da cadeia aplicável. Return routability prova algo mais estreito: alguém recebeu e usou uma URI imprevisível pelo caminho protegido.

Não registre apenas authenticated=true. Guarde método, principal alegado, recipient validado, domínio de confiança ou credencial, hash da capability, versão da política e decisão.

Credenciais corretas de outra pessoa continuam sendo a resposta errada. O controle precisa comparar a origem com o proprietário da URI final, não apenas verificar que algum usuário conhecido assinou.

Return routability prova posse por um caminho

No desenho de return routability, o relay gera uma URI difícil de adivinhar e a envia na solicitação de permissão. O uso posterior dessa URI pode ser aceito como autenticação nas condições do framework.

O MESSAGE deve seguir para uma SIPS URI; grant e deny precisam ser SIPS ou HTTPS; a parte aleatória deve conter pelo menos 32 bits de aleatoriedade criptográfica.

Mesmo assim, a inferência é limitada. Há evidência de posse de um segredo entregue a um endpoint alcançável. Não há prova independente de identidade civil, controle duradouro, compreensão humana ou ausência de cópia por encaminhamento.

Registre qualidade de geração, alegação de entropia, hash em vez do segredo reutilizável, rota protegida, momento de resgate, contexto de origem e tratamento de replay.

Ao migrar para identidade mais forte, versione a regra. Um relay pode passar a rejeitar grants antes aceitos; isso não transforma retrospectivamente as evidências antigas em equivalentes às novas.

470 impede uma expansão parcial invisível

Uma request-contained URI list escolhe recipients no momento da comunicação. O relay mantém um conjunto maior de permissões e verifica a lista recebida.

Se faltar permissão para uma única URI, o relay não deve executar a tradução e responde 470 Consent Needed. Permission-Missing identifica a URI ou o conjunto faltante.

A regra é indivisível. Enviar para quem já consentiu e silenciar o restante seria outra política, além de poder expor a composição do grupo por resultados assimétricos.

Guarde hash da lista recebida, versão do permission set, resultado de cada match, resposta 470 e conjunto divulgado. A lista de faltantes também pode ser sensível e merece controle de acesso.

A página de errata capturada contém um relatório técnico em estado Reported sobre colchetes angulares quando a pontuação torna ambígua a URI em Permission-Missing. Isso é um registro datado de uma possível correção, não autorização para fingir que o texto original já mudou.

Revogar exige mudança de estado

O recipient pode usar a deny capability do documento. Se a perder, uma requisição traduzida posterior pode trazer Trigger-Consent e o target. O recipient pede um novo documento e então nega.

Esse caminho de recuperação não é prova de revogação imediata. O 200 para o trigger aceita o começo da recuperação. A chegada do novo MESSAGE entrega material. Só o deny autenticado e a remoção na translation logic alteram a autoridade.

O ledger precisa conter intenção, trigger, emissão do novo documento, negativa, versão removida, instante de cutover e última saída produzida sob o grant antigo. Requisições concorrentes exigem regra explícita.

O contexto também pode encerrar a permissão. Remover o recipient deve apagar a permission relacionada. Expirar um registro deve remover a autorização do contact. Falha de refresh deve levar à exclusão conforme a política.

“Nunca revogado” não significa “válido para sempre”. Existência do target, frescor, vínculo de registro e regras de remoção fazem parte do poder concedido.

REGISTER de terceiro separa binding de autoridade

No registro comum, registrante e receptor podem ser a mesma parte. No third-party REGISTER, alguém pode ligar seu Address of Record ao contact de uma vítima e direcionar tráfego indesejado.

O framework permite que um 202 aceite o registro para processamento, mas mantenha o contact pending enquanto o registrar busca consentimento. O pacote Pending Additions relata o desfecho.

Isso não exige cerimônia extra para todo REGISTER. O RFC distingue o user agent que registra e recebe na mesma conexão do registrar que aceita associação de terceiro.

O log deve dizer qual caso ocorreu: AoR, contact, registrante autenticado, relação com a conexão, flag de terceiro, estado pending, permission tuple e decisão de encaminhamento.

“REGISTER concluído” pode ser apenas aceitação administrativa. Não é automaticamente autoridade para encaminhar chamadas ao contact.

Proteção do canal não prova a interpretação

Os documentos revelam relações entre sender, target e final recipient. Alterá-los pode fazer alguém conceder algo diferente do que a tela mostrou.

O RFC recomenda integridade e confidencialidade fortes, citando proteção fim a fim como S/MIME e TLS/SIPS hop a hop quando meios melhores não estão disponíveis. Store-and-forward também precisa preservar o conteúdo durante a custódia.

Essas proteções guardam bytes e transporte sob suas premissas. Não provam que texto humano e XML coincidem, que um wildcard foi exibido, que o principal certo acionou a capability nem que o relay instalou a mesma tupla.

Compare as duas representações, vincule a tela ao hash e registre proteção de canal separadamente da interpretação. Teste mutação, replay, vazamento, estado pending obsoleto e mudança de política.

Criptografia é necessária. O erro é deixá-la emprestar autoridade para fatos semânticos e resultados que ela não observa.

Uma atualização sintática não é recibo de implantação

O RFC 8217 atualiza o RFC 5360 e outros documentos SIP para esclarecer quando uma URI usa a produção name-addr. Isso altera o conjunto normativo usado na análise dos campos afetados.

Não prova que um relay instalou o parser novo. Cada execução deve preservar versão do software, configuração e conjunto documental governante.

Da mesma forma, Proposed Standard descreve o status do documento, não adoção por um produto, interoperabilidade em campo ou operação de um serviço específico.