Estive pensando em algo desconfortável sobre a arquitetura do Sign nos últimos dias e não consigo me livrar disso.
O hook é executado uma vez. É isso. A entrada chega, a lógica do hook avalia quaisquer condições que o autor do esquema programou, e uma de duas coisas acontece.
A entrada se torna uma atestação ou desaparece. Não há estado intermediário. Nenhum registro visível da tentativa. Nenhuma pista do que se aproximou, mas não conseguiu. O protocolo simplesmente avança parecendo impecável.
E eu entendo por que isso é projetado dessa forma. Superfícies de evidência limpa são o ponto principal. Você não quer reivindicações rejeitadas mal formadas entulhando o SignScan ao lado de atestações válidas. Faz sentido tecnicamente.
O que me incomoda é o que esse design faz com as pessoas que leem a saída depois.
Quando olho para uma atestação resolvida no Sign, estou vendo a coisa que sobreviveu. Não estou vendo as três entradas que rodaram antes e falharam.
Não estou vendo se o gancho que passou este foi excepcionalmente permissivo naquele dia, ou se uma mudança de configuração alterou o limite de admissibilidade entre o lote de ontem e o de hoje. A atestação parece exatamente a mesma, independentemente de todo esse contexto.
O gancho é escrito pelo autor do esquema, não pelo Sign. Então, quando algo é rejeitado e desaparece, o protocolo é genuinamente limpo.
O Sign não cometeu um erro. O gancho do autor do esquema tomou uma decisão e essa decisão aconteceu em algum lugar que a camada de atestação nunca toca.
O que significa que se estou a jusante e tentando entender se essa aprovação significa o que eu acho que significa, estou lendo a saída de um portão que não posso ver, escrito por uma parte que talvez eu não entenda completamente, que foi executado uma vez e não deixou registro visível do que considerou.
Então há a situação extraData. Esta é a parte à qual continuo retornando. Os campos que carregam o contexto da política, a era do programa à qual esta atestação pertence, as condições específicas que tornaram esta reivindicação válida sob esta versão de esquema particular, viajam tecnicamente com a atestação. Eles estão lá.
Mas a maioria dos sistemas a jusante, TokenTable, integrações de parceiros, filtros de elegibilidade, verifica a correspondência de esquema e a validade da atestação e depois avança. Ninguém abre extraData. É trabalho demais para um portão binário de sim-não.
Então a atestação viaja. É portátil. Ela atravessa cadeias, é consumida por diferentes sistemas, aparece em distribuições seis meses depois.
E está carregando o contexto completo de quando e por que foi válido dentro de um campo que os sistemas que atuam sobre ele nunca leram.
Não acho que isso seja uma falha do Sign. Acho que é o custo honesto de tornar as evidências portáteis em grande escala. Você não pode fazer com que cada sistema a jusante reconstrua o contexto de decisão completo toda vez que toca um registro. Isso quebraria tudo.
Mas isso significa que a camada de atestação está fazendo menos trabalho do que parece. A verdadeira decisão aconteceu no gancho. O gancho foi executado uma vez de forma invisível.
O registro que saiu do outro lado parece autoritário, resolvido e completo.
E ele viaja dessa forma para sempre, quer as condições que o tornaram válido ainda se apliquem ou não. @SignOfficial $SIGN
