Resumo

  • draft-mcguinness-oauth-client-attesters-00 propõe client_attesters, com issuer e jwks_uri, para o publicador dizer quem pode atestar por seu client_id. A revisão 00 é um Internet-Draft individual, não um RFC.
  • O aval do publicador e a confiança do authorization server são condições independentes; assinatura válida não substitui nenhuma delas nem concede acesso.
  • Retirar o aval depende da atualização dos caches e não revoga grants ou tokens existentes, nem altera resource servers que validam a atestação diretamente.

Uma troca de plantão recebe a mensagem “atestador removido”. Horas depois, o mesmo cliente continua acessando uma API. A investigação encontra três causas legítimas ao mesmo tempo: metadata ainda fresca em cache, access token emitido antes da remoção e um resource server que mantém confiança direta. O erro foi transformar uma mudança de publicação em promessa de término.

O draft OAuth 2.0 Client Attester Endorsement cobre uma lacuna do ATTEST. Este último define como um Client Attester afirma fatos sobre uma Client Instance e sua chave, mas não estabelece qual attester pode falar por um client_id. O novo parâmetro coloca essa relação na metadata autoritativa do cliente.

Cada entrada informa o issuer exato e o jwks_uri HTTPS. O publicador está autorizando um porta-voz. Não está criando uma trust anchor para todos, autenticando a instância, delegando o usuário ou concedendo uma operação no recurso.

A aceitação fica na interseção

O authorization server só aceita quando a metadata atual endossa o iss e sua própria política permite a associação cliente-atestador e a fonte de chaves. O servidor pode estreitar a lista, nunca incluir um atestador não endossado. O publicador pode retirar um nome, mas não obrigar o servidor a confiar nele.

Em publisher-authorized key selection, o servidor já autorizou aquele publicador a escolher atestador e chaves. O jwks_uri publicado é consultado sob restrições de HTTPS, origem, caminho e rede. A escala melhora, porém a garantia não é independente do publicador: quem controla o CIMD pode operar seu próprio atestador.

Em AS-configured attester trust, o servidor configura uma fonte para o issuer exato. O URI endossado apenas coincide com ela ou com um alias explícito; não é usado como fallback. Divergência significa falha. Se esse trust estiver configurado para qualquer cliente, ele prevalece para o issuer em todos os clientes. Remover a configuração tampouco transfere automaticamente o controle aos publicadores.

A ordem dá significado à chave

Primeiro se escolhe uma única fonte autoritativa para client_id, sem misturar registro e CIMD. Depois vêm a entrada issuer == iss, a política da associação, a origem da chave e um único kid elegível. A chave fica vinculada a cliente, issuer, fonte e política; uma coleção de chaves ou um kid isolado não basta.

Os headers jku, x5u, x5c e jwk não escolhem a chave. Só então são validados assinatura, prova, sub == client_id e o restante do ATTEST. Ao final ainda há uma decisão separada de grant e autorização. Identidade comprovada não escolhe scope nem ação de negócio.

Quatro relógios após a retirada

O primeiro é o cache da metadata. O draft exige idade máxima finita, sem fixar valor; o trust agreement precisa declarar o limite. 404 ou 410 observados eliminam a cópia anterior, mas timeout ou 5xx não invalidam cache ainda fresco.

O segundo é o cache do JWK Set. Rotação planejada publica a nova chave, espera a propagação, inicia assinatura e mantém a antiga até expirarem as atestações. Mudança de localização exige também atualização da metadata e, no modo configurado, coordenação do operador.

O terceiro é a validade da própria atestação. O quarto pertence aos grants e tokens. Retirar endorsement impede autenticações futuras quando a alteração é vista; não revoga o que já foi emitido. Término exige revogar grants e tokens, bloquear refresh, devolver inactive na introspecção e tratar tokens validados offline.

Um resource server que recebe Client Attestation diretamente não descobre o endorsement por este perfil. Ele segue seu trust configurado. Por isso a retirada precisa de inventário, não apenas de edição.

Registrar a decisão inteira

O recibo operacional deve preservar client_id, fonte de metadata, hash, horário, cache e validade; endorsement exato e autoridade do publicador; modo de trust, precedência, source, aliases, hash e frescor do JWK Set; kid, algoritmo e chave única. Em seguida vêm assinatura, prova e correspondência de sub.

Também é necessário dizer se a atestação era obrigatória. A presença de client_attesters não a torna obrigatória; como sinal opcional, ela pode falhar e a política prosseguir com outra credencial. A decisão do grant é registrada à parte.

Na retirada, acrescentam-se primeira observação, convergência, última aceitação, expiração, revogação, refresh, introspecção, janela offline e validadores diretos. Este recibo é análise de Daniel Kade, não exigência normativa do draft.

O erro público invalid_client_attestation não revela a causa. Internamente, porém, é preciso separar falta de endorsement, conflito de fonte, kid ambíguo e falha transitória. Uma nova atestação não resolve desacordo de política.