Resumo

  • Em 1º de setembro, o IESG abriu a Last Call do SD-JWT VC -19. O grupo OAuth pede a publicação como Proposed Standard; os comentários terminam em 15 de setembro e ainda não há aprovação.
  • vct identifica o tipo principal. O emissor pode afirmar outros tipos em aka_vcts, enquanto extends organiza a herança entre documentos de Type Metadata.
  • Esses mecanismos permitem correspondência e reúso de regras. O rascunho determina que eles não sejam tratados como autorização para emitir um tipo reconhecido.
  • O Publisher dos Type Metadata também precisa de autoridade própria. HTTPS e integridade confirmam transporte e versão, não o mandato para definir o tipo.
  • Um recibo de autoridade mantido por cada ecossistema pode ligar o tipo às fontes de autorização do emissor e do Publisher sem criar um cadastro mundial sob controle do IETF.

A Last Call deixa a pergunta aberta

O anúncio de 1º de setembro não transformou o SD-JWT VC em RFC. Ele colocou a revisão -19 na etapa de Last Call de todo o IETF, com prazo até 15 de setembro, depois de o grupo OAuth solicitar sua publicação na trilha de padrões. No corte desta apuração, o Datatracker ainda não marcava data de telechat, apontava revisão de IANA necessária e não registrava decisão final do IESG.

A cautela com o estado do processo é parte da notícia. A orientação pública do IESG chama a Last Call, em situações normais, de última etapa aberta de revisão comunitária. É justamente quando objeções técnicas ou institucionais devem entrar no registro. Não é um selo antecipado.

O texto se apoia no RFC 9901. No SD-JWT, o emissor assina uma estrutura JSON. Algumas informações ficam visíveis; outras aparecem como resumos, e o titular escolhe quais revelações apresentar. O verificador confere a assinatura do emissor, os resumos divulgados e, se a política exigir, a vinculação da credencial a uma chave do titular.

O SD-JWT VC dá a essa mecânica um formato de credencial. O campo obrigatório vct é um identificador sensível a maiúsculas e minúsculas e resistente a colisões. Ele aponta para o tipo e para as regras associadas. O rascunho não cria valores concretos de vct: cada ecossistema define seus tipos, a semântica dos claims e as políticas adicionais de emissão e validação.

Esse desenho impede que um padrão de Internet escolha, por conta própria, quem pode emitir uma licença estatal, um diploma, uma carteira funcional ou uma credencial privada. A especificação descreve a linguagem comum. A autoridade vem de outro lugar.

A árvore de tipos não é uma árvore de mandatos

O extends, usado nos Type Metadata, diz que um tipo deriva de outro. O Consumer processa primeiro o tipo anterior e depois as particularidades do novo. Os metadados herdados continuam valendo; um tipo filho não pode tornar opcional um claim que o pai marcou como obrigatório, nem desfazer uma exigência fixa sobre divulgação seletiva.

O aka_vcts tem natureza diferente. É uma lista opcional, incluída na própria credencial e afirmada pelo emissor, que apresenta tipos adicionais. Ela ajuda quando um protocolo espera um tipo geral e recebe uma especialização. Funciona mesmo sem Type Metadata, a ordem não expressa hierarquia e os tipos não precisam estar ligados por extends.

Ambos resolvem problemas de interoperabilidade. Nenhum entrega poder institucional. A seção 7.7 descreve o risco de um emissor hostil imitar ou estender um tipo legítimo. Titulares e verificadores não podem aceitar a credencial apenas porque a hierarquia parece reconhecível; devem conferir, separadamente, identidade, situação de confiança e eventual acreditação ou registro do emissor.

O aviso alcança diretamente aka_vcts. A lista é tão confiável quanto quem a assina. Dizer “esta credencial também pertence ao tipo X” não demonstra que o emissor recebeu autorização de X, de um regulador ou de qualquer mantenedor do ecossistema.

Uma interface deveria, portanto, manter dois estados. “O tipo corresponde” é uma conclusão semântica. “O emissor está autorizado” é uma conclusão de governança. Exibir um único selo apaga a origem de cada uma.

Quem publica os metadados exerce outra função

O Publisher definido no rascunho pode ser um órgão de padronização, uma comunidade, uma autoridade do ecossistema ou qualquer parte que publique Type Metadata. Ele pode não ser o emissor. Seu documento descreve claims, apresentação, relações de herança e outras características do tipo.

O Consumer pode obter o arquivo por HTTPS e verificar um valor de integridade. Ainda assim, sabe apenas que recebeu aquela versão sem alteração. Não sabe por que o Publisher teria o direito de definir ou descrever o tipo.

A seção 7.8 separa a questão. O Consumer não deve pressupor que os metadados sejam corretos ou significativos se o Publisher não for reconhecido como autoridade para o tipo. O texto recomenda que os ecossistemas criem mecanismos de governança ou acreditação, identificando quais Publishers são autorizados e em quais condições seus documentos merecem confiança.

Surgem, assim, duas relações de mandato. A primeira autoriza o emissor a produzir a credencial. A segunda autoriza o Publisher a definir seus metadados. A mesma organização pode exercer ambas, mas o registro deveria continuar separado: escopo, prazo e modo de revogação podem mudar em datas diferentes.

Criptografia guarda uma declaração; não nomeia a autoridade

O rascunho exige que o verificador confirme que a chave de assinatura pertence ao emissor por um método admitido pela política aplicável. Se essa validação falhar, a credencial deve ser rejeitada. É uma regra indispensável e não há motivo para enfraquecê-la.

Mas controlar corretamente a própria chave não equivale a possuir licença para emitir um documento público. Um Publisher sem reconhecimento também consegue publicar uma cadeia coerente. Uma prova de integridade pode proteger, com perfeição matemática, um conteúdo produzido sem mandato.

É aí que a ideia de lavagem de mandato, formulada por Heng Lu, se torna útil. A camada técnica começa a circular como se fosse a própria fonte de poder que deveria apenas transportar. Em um aplicativo, tipo familiar, assinatura válida e um ícone verde formam uma narrativa contínua. Se o ícone não informa qual etapa foi verificada, o usuário tende a completar sozinho a lacuna institucional.

O mérito da revisão -19 é interromper essa inferência no texto normativo. O desafio operacional é não religá-la no design do produto.

Um recibo para a decisão que fica fora do token

Cada ecossistema pode manter um recibo de autoridade curto e versionado para as combinações de emissor e tipo que aceita. Esse recibo não precisa ser transportado como claim da credencial nem administrado pelo IETF.

O primeiro bloco registraria o vct, os aka_vcts admitidos e a cadeia extends processada. O segundo identificaria o emissor, o método de descoberta e validação de chave e a fonte externa de autorização: registro, acreditação, lei, contrato ou trust list.

Um terceiro bloco nomearia o Publisher dos Type Metadata, a versão e a referência de integridade do documento e a fonte que lhe confere autoridade para aquele tipo. Escopo geográfico ou setorial, período de validade, versão da política do verificador e horário da decisão completariam o registro. Uma não conclusão explícita diria que assinatura, correspondência, alias, herança ou download íntegro não bastam sozinhos.

O vocabulário negativo também importa. “Não consultado”, “não localizado”, “expirado”, “fora de escopo” e “não autorizado” são situações diferentes. A ausência de prova pública não autoriza acusar um emissor.

O recibo é uma proposta editorial deste Artigo, não uma exigência da revisão -19. Ele apenas preserva a decisão externa que o formato comum, corretamente, não toma.

A solução deve permanecer distribuída

Sistemas nacionais, universidades, conselhos profissionais e associações privadas não compartilham a mesma fonte jurídica de autoridade. Um registro universal centralizaria poder, criaria dependência e envelheceria conforme os mandatos locais mudassem. Também excederia o papel técnico do grupo OAuth.

Por isso, o lugar do recibo é o perfil do ecossistema, a política do verificador, a configuração de confiança da carteira ou o registro do programa. O IETF mantém a sintaxe, o processamento e a fronteira. Cada instituição competente continua decidindo quem pode emitir o quê.

Há ainda uma restrição de privacidade. vct e aka_vcts não são seletivamente ocultáveis e podem revelar o contexto da credencial. O texto também alerta para o phone-home: se o identificador do emissor variar por titular e o verificador buscar metadados online, um emissor malicioso pode acompanhar onde e com que frequência a credencial foi apresentada. O recibo deve usar combinações estáveis de emissor e tipo, permitir cache ou pinning e evitar consultas individuais a cada apresentação.

Fontes

  1. IETF — Last Call do SD-JWT VC -19
  2. IETF Datatracker — registro do SD-JWT VC
  3. IETF — SD-JWT VC, revisão -19
  4. RFC 9901 — Selective Disclosure for JSON Web Tokens
  5. IESG — orientação sobre Last Call
  6. IETF — charter do grupo OAuth
  7. Heng Lu — Mandate Laundering