Summary

  • O draft-saha-aadp-bound-permit-00, publicado em 29 de setembro, propõe levar uma decisão AADP com estado por uma fronteira de confiança, vinculada a um destinatário, uma chave de apresentação, uma requisição HTTP e uma instância concreta de ação.
  • O permit não substitui autoridade. O mandate referenciado precisa permitir a mesma transação, a política local do destinatário conserva o veto e a atualidade da decisão deve ser comprovada. Cada camada pode negar; nenhuma amplia a outra.
  • (iss, jti) só é consumido atomicamente após todas as demais verificações. A repetição idêntica recebe o resultado armazenado, mas a proposta não garante efeito externo exactly once; uma tentativa de resultado desconhecido exige reconciliação, não outro permit.

Uma decisão baseada em estado que ficou do outro lado

Para aprovar uma transferência de EUR 40,00, o PDP do remetente pode ter usado orçamento acumulado, reserva aberta, aprovação ainda válida, execuções anteriores e um kill switch. O provedor de pagamento não possui esses dados. Ele pode verificar identidade e mandate, mas não recalcular o instante em que o orçamento foi reservado.

Se a requisição chegar como EUR 40,01, verificar apenas a assinatura do JWT não responde se aquela ação foi decidida. A diferença pode vir de comprometimento, de um proxy que reconstruiu o corpo ou de uma rotina de retry. Em todos os casos, o destinatário precisa provar correspondência entre decisão e tentativa.

É esse o espaço estreito da primeira revisão de Shamik Saha sobre action-bound permits. Trata-se de um Internet-Draft individual ativo, com intenção Standards Track no cabeçalho. Não é RFC, consenso do IETF, produto de working group ou evidência de produção.

O objeto carrega uma decisão que o outro domínio não consegue recomputar. Não cria um sistema geral de autorização entre organizações.

O permit não viaja sozinho

O envelope é um JWT JWS compacto cujo typ exato é aadp-permit+jwt. aud identifica somente um destinatário. cnf.jkt fixa a chave do apresentador, e a HTTP Message Signature da requisição precisa verificar com essa chave. Sem proof of possession, o permit seria bearer; o texto proíbe isso ao cruzar a fronteira.

A assinatura cobre pelo menos método, authority, path, query, Content-Digest, Idempotency-Key e o campo do permit. O destinatário recalcula o digest sobre os bytes exatos recebidos antes de parsing ou reserialização. Dois JSONs semanticamente equivalentes podem falhar se os bytes diferirem.

Depois vem o vínculo semântico. O tipo de ação registrado define como extrair o objeto A do path, query e corpo. O destinatário aplica RFC 8785, acrescenta o separador de domínio e compara action_digest. Bytes iguais não salvam uma derivação diferente de valor, favorecido ou sequência; significado igual não apaga alteração no fio.

O tempo fecha a quinta borda. exp não ultrapassa execute_within. Sem essa obrigação, o período entre iat e exp é no máximo 120 segundos. O skew declarado, limitado a 60 segundos, não pode prolongar o prazo material.

Um público, uma chave, uma requisição, uma ação e uma janela curta tornam o objeto difícil de reutilizar. Essa limitação é o produto, não uma falta de conveniência.

Três decisões continuam separadas

O destinatário só age quando três condições são verdadeiras ao mesmo tempo: o bound permit e seus vínculos verificam; o mandate referenciado, quando existe, permite; e a política local também permite.

Um Agent Authorization Envelope proposto diz o que foi delegado ao agente. O bound permit diz o que o PDP decidiu agora com seu estado. O destinatário avalia o AAE contra a mesma transação e compara o digest. DENY, PENDING, mismatch ou mandate obrigatório indisponível resultam em recusa. Um permit nunca transforma PENDING em PERMIT.

A organização que executará o efeito mantém seu veto. Pode confiar no emissor, confirmar o valor e ainda recusar por fraude, conta, sanções ou limites do serviço. A decisão assinada de outro domínio é evidência; não é soberania sobre quem assume a consequência.

A própria confiança no emissor é escopada. A tabela contém chaves, action types, limites por campo, validade e currentness mínimo. Confiar num PDP para pequenas transferências não o autoriza a encerrar contas ou decidir qualquer valor. Uma lista plana de emissores confiáveis esconderia o poder dentro das lacunas da política local.

Curta duração não detecta revogação

Uma política pode ser substituída ou um mandate revogado depois da assinatura. O vencimento breve reduz a janela, mas não enxerga a mudança. Por isso cada permit declara um modo.

time-bounded considera a decisão atual até exp, sem nova consulta, somente para combinações de emissor e ação configuradas para aceitar o risco. status-checked exige verificar naquele momento permit, versão da política e mandate por uma status list ou por uma freshness statement recente e assinada.

Endpoint inacessível, resposta inválida ou statement velho normalmente produzem status-unavailable. Um fail-open só pode existir de forma local, explícita, auditada e para classe de baixo risco. O registro precisa mostrar que a exceção ocorreu; “token válido” não é descrição suficiente.

As reality layers de Lu Heng mantêm os significados no lugar. O permit registra a conclusão do PDP em um momento. A checagem de status registra o que continuava observável depois. O pagamento é outro fato. Juntar os registros é necessário; converter o primeiro no terceiro é erro de categoria.

O estado é consumido na etapa treze

O destinatário verifica estrutura, emissor, audiência, tempo, tipo, escopo, digest do corpo, assinatura do apresentador, ação semântica, currentness, mandate e política local. Só então consome (iss, jti) atomicamente, e somente depois tenta o efeito.

Esse encadeamento impede que uma requisição defeituosa queime um uso legítimo. Uma recusa local também não consome. Se o consume store estiver indisponível, a classificação é could-not-check; prosseguir transformaria uma falha operacional em permissão.

jti não é o permit_id interno do AADP. Precisa ser criado de forma independente e não derivável. O emissor guarda a correspondência, mas apenas jti cruza a fronteira e funciona como Idempotency-Key. Um identificador interno de decisão não deve virar credential externo por conveniência.

Na primeira apresentação, um store durável, atômico e compartilhado consome, executa e armazena o resultado. A mesma dupla (iss, jti) com o mesmo digest devolve esse resultado sem novo efeito. Com corpo diferente, a resposta é idempotency-conflict. Enquanto a primeira ainda roda, a repetição recebe condição retryable.

Agora volta o caso da resposta perdida. O apresentador não sabe se houve pagamento. O texto proíbe obter um novo permit e mandar outra vez. Ele relata timeout, reconcilia por jti ou recipient_action_id e escala se os registros não fecharem. Idempotência organiza retries conhecidos; não prova exactly once no mundo externo.

Uma confirmação assinada pela parte que executou

Depois do consumo e da tentativa de efeito, o destinatário retorna uma confirmação assinada. Ela referencia permit, content digest, digest da base de assinatura, action digest, mandate verdict, outcome e seu identificador de ação. O apresentador inclui o digest dessa confirmação no relatório AADP como discharge evidence de present_bound.

As assinaturas não são intercambiáveis. O PDP assina “decidi”. O apresentador assina “enviei esta requisição”. O destinatário assina “tratei assim”. Uma recusa assinada pode sustentar failure com no_effect: true; um erro sem assinatura não prova ausência de efeito. Sem confirmação, permanece timeout.

O permit é single-hop. Um claim parent deve ser recusado. Se B precisar chamar C, B toma outra decisão com seu próprio estado. Pode citar a etapa anterior como provenance, mas essa referência não autoriza C nem relaxa verificação.

Essa fronteira materializa a Minimum Initial Specification: padronizar os vínculos e refusals mínimos para que ambos verifiquem a mesma tentativa, mantendo seleção de confiança, risco e consequências nas partes responsáveis.

Dois vetores ainda não fecham

O draft aponta para um commit imutável do repositório onedoor. O manifest lista 24 conformance vectors; o mapa declara 22 implementados. V17, detecção de política substituída em status-checked, e V22, confirmação que referencia outro request digest, aparecem como gaps. O texto relata ainda 92 testes permit passando.

É evidência reproduzível, mas ligada ao autor. A mensagem do commit trata de outra manutenção do repositório, e não há implementação independente ou medição produtiva. Running-Code Primacy exige repetir os vetores, especialmente os dois vazios, e publicar divergências; não transforma um snapshot em autoridade normativa.

Fontes e limites

As fontes comprovam uma proposta individual ativa, suas dependências e um snapshot de implementação ligado ao autor. Não comprovam consenso IETF, RFC, interoperabilidade independente, implantação segura, política correta, destinatário honesto ou efeito exactly once. Este Artigo possui apenas a tese da revisão 00: transportar uma decisão AADP com estado como uma tentativa única, vinculada a destinatário, apresentador, requisição e ação, respondida com assinatura do destinatário.