Resumo

  • O Capability Language Core, publicado em 27 de setembro como Internet-Draft individual, separa allow_unresolved de uma autorização plena.
  • Condições de horário e rede reconhecidas mas não avaliadas pelo núcleo seguem para o ponto de aplicação; três programas do mesmo autor não comprovam validação independente.

O risco de uma autorização automática nem sempre está em conceder poderes demais no papel. Às vezes a restrição está escrita corretamente e some na passagem entre dois programas. Um componente entende que um agente só pode agir de determinada rede; outro, encarregado de executar, recebe apenas um booleano e interpreta qualquer resultado que não seja recusa como liberação. O texto de Jijie Wei tenta tornar essa perda de informação visível no próprio veredito.

O documento draft-wei-capability-language-core-00 tem data de 27 de setembro de 2026 e pretende o status Experimental. No Datatracker, continua como I-D Exists, apresentação individual sem posição formal no processo de padronização do IETF. Não se pode chamá-lo de RFC, norma aprovada ou prática implantada. A proposta descreve uma linguagem para identificar capacidades de agentes, comparar concessões com operações, cruzar limites de várias fontes e emitir decisões determinísticas com motivos definidos.

O ponto decisivo aparece na seção 8.4. Se o núcleo v1 reconhece a gramática de uma condição de tempo ou rede, mas não tem como avaliá-la, ele deve conservar essa obrigação na lista unresolved. O resultado não é allow, e sim o valor distinto allow_unresolved. Antes de executar, o consumidor da decisão precisa confirmar cada obrigação; se não puder, deve negar. Quando há várias condições pendentes, a confirmação de uma só não libera as demais. A precisão da enumeração impede que uma condição válida seja descartada silenciosamente.

A seção 8.5 especifica Resolve: o sistema consumidor relata, condição por condição, se foi satisfeita, violada ou permaneceu desconhecida, e o núcleo calcula uma nova decisão. Essa função organiza o retorno, mas não fornece automaticamente um relógio confiável, um sensor da rede ou autoridade para escolher a regra local. Uma ponte que reduza os três valores a “negar” e “todo o resto” pode destruir o controle exatamente no último passo. É uma hipótese de risco de integração, não relato de invasão, incidente ou produto vulnerável.

O alcance da linguagem é intencionalmente limitado. O CLC não resolve quem é um emissor confiável, como se valida a assinatura do artefato original, o que ocorreu depois da invocação nem qual formato de token ou recibo circula entre sistemas. O RFC 9396 já define authorization_details para pedidos OAuth detalhados; o novo draft o menciona como possibilidade de transporte, não como endosso ao CLC. A expressão de uma permissão e a confirmação de sua origem continuam sendo trabalhos diferentes.

O autor relata 123 vetores e 1.184 casos de propriedades para a parte de autorização. Implementações em Go, Python e TypeScript passam nesses testes, mas têm autoria comum. O próprio draft chama essa concordância de teste de regressão e reconhece que a meta de duas implementações independentes não foi atingida. A classe CLC-A é apresentada como base; a classe CLC-E, voltada a evidências, não é reivindicada. Por isso, o avanço documentado é a definição da pergunta e dos testes, não uma interoperabilidade já demonstrada.

Fontes