Resumo

  • A versão 03 do RVP substitui a cascata obrigatória de cinco camadas e a soma portátil de confiança da versão 02 por evidências ligadas a uma exigência congelada.
  • Um token da primeira geração, assinado apenas sobre um desafio, pode ser preservado como histórico, mas não comprova a operação e o alvo exigidos pelo novo compromisso.

Uma pessoa responde a um desafio no celular; horas depois, um serviço tenta usar a mesma resposta para abrir outro contexto. A assinatura pode continuar válida e ainda assim ser insuficiente: ela não informa qual operação foi apresentada nem a qual alvo se referia. É esse espaço entre validade criptográfica e significado administrativo que o RVP tenta reduzir na revisão publicada em 29 de setembro.

O texto anterior assumia verificação contínua a cada interação. Uma sequência de cinco modalidades podia produzir pontuações somadas até um limiar. A execução de bloqueio ou permissão já era decisão local na versão 02; atribuir essa ressalva exclusivamente à 03 distorceria a notícia. A mudança real é retirar o modelo obrigatório de soma e reconhecer que sessão autenticada, presença humana recente, inscrição do dispositivo, recuperação e admissão são fatos diferentes. O consumidor escolhe, por política explícita, quando e como pedir evidência adicional.

Antes da resposta, a exigência de evidência recebe identidade, versão imutável e digest do conteúdo. O pedido especifica operação, alvo, sujeito, ator, propósito, consumidor, janela e prazo. Um compromisso criptográfico cobre o conjunto. O transportador pode ser uma checagem local, um aparelho acompanhante ou outro método; ele não recebe por isso poder para redefinir a pergunta. O verificador recalcula o compromisso usando o próprio pedido, em vez de confiar apenas no desafio transmitido.

O apêndice de migração impede uma conversão confortável, mas falsa. Registros da versão 1 podem continuar nos arquivos. Entretanto, se a exigência atual requer vínculo à operação e ao alvo, os tokens antigos não passam. Não se pode buscar campos faltantes no banco local e afirmar que o signatário os viu e aprovou. E uma verificação que pede o compromisso completo da versão 2 não deve aceitar silenciosamente uma resposta antiga que assinou somente o desafio.

Há ainda um intervalo entre satisfazer a pergunta e usar a resposta. match encerra a via de verificação dizendo apenas que a evidência cumpriu a exigência. bind é outro registro, produzido quando um consumidor efetivamente aplica a evidência a uma finalidade e a uma transição específica do alvo. O consumidor precisa reavaliar frescor e estado do alvo; usos concorrentes devem ser coordenados. Mesmo esse vínculo não autoriza acesso por si só. A admissão pertence à política do sistema de destino.

Daniel Kade propõe que uma migração documente versão do token, campos cobertos pela assinatura, digest da exigência, operação, alvo, consumidor, vínculo de uso e responsável pela autorização final. Essa lista é recomendação editorial, não formulário oficial. Ela evita a frase enganosa «a nota antiga era alta, portanto a ação nova foi consentida».

O Datatracker identifica a revisão como Internet-Draft individual ativo, sem RFC stream. O pedido de registro do tipo application/rvp+json não equivale a um registro feito. Tampouco se comprovou implantação ou incidente. O fato novo é uma troca de arquitetura proposta: da confiança que parece viajar livremente para a resposta limitada à pergunta efetivamente feita.

Fontes