Resumo

  • O RFC 9967, do qual Nancy Cam-Winget é coautora, define eventos de segurança SCIM transportados em SETs. Um SET informa que ocorreu uma mudança de estado em um provedor SCIM; o Event Receiver escolhe sua próxima ação local em vez de receber uma ordem.
  • Set-Txn associa uma resposta assíncrona 202 Accepted à declaração txn de um SET posterior. A associação, o armazenamento do evento ou a forma de sua carga não comprovam que o receptor encontrou o recurso, reconciliou o modelo, aplicou uma política ou alcançou o mesmo estado.

Em automação de identidade assíncrona, a palavra mais sedutora costuma ser “concluído”. Uma solicitação recebe 202 Accepted; mais tarde surge um SET com o txn esperado. Parece natural dizer que a alteração terminou em toda parte. O RFC 9967 não faz essa promessa. Ele prova algo mais disciplinado: o provedor aceitou trabalho assíncrono e depois publicou um evento que pode ser correlacionado pelo cliente. Não prova como cada domínio receptor interpretou a novidade nem qual efeito local ela produziu.

O RFC 9967, System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs), descreve o SET como informação sobre uma mudança de estado que já aconteceu em um provedor de serviços SCIM. Isso reduz a necessidade de sondagem contínua e é operacionalmente útil. Mas o texto impede que essa informação vire um comando. Cada receptor determina a melhor ação posterior no seu próprio contexto; a reconciliação de diferenças de esquema e tipo de recurso entre domínios é o exemplo dado pela especificação.

Essa ressalva corresponde ao funcionamento real dos sistemas. Dois domínios podem usar identificadores diversos, atributos que não se correspondem ou regras de ciclo de vida distintas. O receptor pode ligar o URI do evento a um registro local, ou não conseguir fazê-lo. Se não for capaz de corresponder o URI, o RFC permite que use a base SCIM acordada do provedor e o URI relativo para executar um GET. Também pode guardar o evento para recuperação e deixar uma fila local decidir a ação. A mudança declarada pelo provedor e a reconciliação do receptor permanecem fatos diferentes.

O cabeçalho de correlação é deliberadamente modesto. Para uma resposta SCIM assíncrona, o RFC requer 202 Accepted, sem corpo, e Set-Txn; o valor deve corresponder ao txn de um SET posterior, permitindo ao cliente procurar o evento de conclusão associado. Trata-se de uma boa junção de auditoria entre solicitação aceita e declaração posterior do provedor. Não é um recibo universal. O RFC separa txn de jti: jti identifica um token individual, enquanto um txn pode persistir em retransmissões ou publicações para múltiplos receptores. Uma correspondência mostra qual transação foi correlacionada, não qual receptor convergiu para qual estado.

A carga do evento exige igual cuidado. Deve existir exatamente um entre data e attributes. data traz uma representação do recurso após a transação; attributes enumera campos criados ou modificados. Mesmo uma representação completa pode exigir mapeamento de esquema e julgamento local. Uma lista de atributos pode pedir busca adicional. Nenhuma das formas afirma que o receptor aceitou os dados, executou uma decisão de acesso ou agora espelha o estado atual do provedor.

Persistência é mais uma evidência, não a mesma evidência. Antes de confirmar o recebimento, os receptores devem garantir que os eventos sejam persistidos direta ou indiretamente para suas necessidades locais de recuperação. A exigência permite recuperar um fluxo de longa duração diante de falha transitória ou repetição. Uma caixa de entrada durável demonstra que um evento foi retido; não demonstra reconciliação, ação ou estado local observado.

Running-Code Primacy oferece a disciplina apropriada: fazer cada artefato técnico provar apenas a mudança que ele realmente expõe. Solicitação aceita, Set-Txn, txn, jti, chegada do SET, persistência, correspondência local, resultado de consulta, regra avaliada, ação e estado observado são junções separadas. Chamar tudo de “sincronizado” apaga justamente a lacuna que um operador precisará investigar.

A prática mais forte não é desconfiar do RFC 9967 nem centralizar a decisão. O provedor responde pela declaração de mudança; o receptor responde pela interpretação dentro de seu modelo; a organização que suporta o efeito define a evidência necessária para chamar algo de reconciliado. O padrão amplia fatos verificáveis sem transformar um evento na decisão de outro domínio.

Fontes