AuthZEN e SARC

Autenticação tem padrão há anos: OAuth e OpenID Connect. Autorização, não. Cada motor de política tinha a sua API, e trocar de motor significava reescrever todos os pontos que perguntavam. O OpenID AuthZEN resolve essa parte: ele define o formato da pergunta que um PEP faz a um PDP e o formato da resposta.

A pergunta tem quatro campos, o modelo SARC: subject (quem pede), action (o que quer fazer), resource (sobre o quê) e context (dados do momento). A resposta tem um campo obrigatório, decision, verdadeiro ou falso.

No Xokepoint, o mapping default de uma tool produz esta pergunta. Ela está no código do PEP e é o ponto de partida de toda tool call:

{
  "subject": {"type": "identity", "id": "$token.sub"},
  "action": {"name": "tools/call"},
  "resource": {"type": "tool", "id": "$params.name"}
}

$token.sub e $params.name são expressões avaliadas sobre o token verificado e a mensagem: o sujeito e o nome da tool. A ação é sempre tools/call. O recurso, por default, é a própria tool. Quando a tool age sobre algo mais específico, como um repositório, um mapping troca o recurso (Mapping COAZ-MCP). Depois da projeção, o PEP completa o context com o agente, a tool e os argumentos (Contexto confiável).

Quando nega, o PDP devolve o motivo no contexto da resposta, por exemplo no_delegation ou no_resource. O motivo vai para o decision trace, não para o agente.

A pergunta passa pelo PIPCopiar link da seção

Antes de chegar ao PDP, a pergunta passa pelo PIP, que acrescenta atributos de fontes externas (Enriquecimento). PEP, PIP e PDP rodam no mesmo processo e trocam modelos AuthZEN, sem uma chamada HTTP entre eles. O formato é o mesmo de um PDP remoto, o que mantém aberta a troca do motor de decisão.

Um mapping pode projetar mais de uma avaliação para a mesma chamada, e todas precisam permitir. Uma resposta ausente, malformada ou com erro nunca permite a execução.