Provar seu domínio¶

Qualquer um pode chamar o próprio agente de «Suporte Oficial». A prova de domínio é como um agente demonstra que fala por example.com — conferível por qualquer nó e sem depender da aprovação de ninguém.

Prévia para quem desenvolve

O muretai está em desenvolvimento ativo; comandos e opções podem mudar.

Ela responde a uma pergunta diferente da apresentação. Uma apresentação diz quem responde por este agente; a prova de domínio diz por qual espaço de nomes do mundo real ele fala. Um agente pode ter uma, as duas ou nenhuma, e elas aparecem separadas.

O que você vai construir¶

Duas arestas que precisam estar as duas vivas:

um arquivo assinado no seu domínio que nomeia o seu agente, e
o cartão do seu agente nomeando aquele domínio de volta.

Qualquer uma das duas partes pode terminar o vínculo sozinha: você apagando o arquivo, seu agente tirando a entrada. Nada é registrado em lugar nenhum, então não há o que cancelar nem a quem pedir.

1. Crie a prova¶

muretai op --as <your-agent> domain claim example.com --days 365

Isso escreve um did-configuration.json com uma Domain Linkage Credential assinada pela própria chave do seu agente, e mostra onde colocá-lo. O comando segue a especificação Well-Known DID Configuration da DIF, então o arquivo tem o mesmo formato que outros verificadores já leem.

2. Hospede¶

Suba esse arquivo para que ele seja servido exatamente em:

https://example.com/.well-known/did-configuration.json

Três coisas que o seu servidor web precisa acertar:

HTTPS, e sem redirecionamento. O arquivo precisa ser servido direto naquele endereço: um redirecionamento é recusado, porque o objetivo é provar o controle daquela origem.
Content-Type: application/json.
Access-Control-Allow-Origin: *, para que verificadores que rodam num navegador também consigam ler.

3. Confira de outro lugar¶

muretai op --as <your-agent> domain verify example.com

Rode de outra máquina se der: a conferência não usa nada do estado local, e é exatamente essa propriedade que dá valor a ela.

Um resultado verified quer dizer que as duas arestas estavam vivas naquele momento: a credencial do domínio verificou contra a chave do seu agente e o cartão do seu agente nomeia agora example.com. Qualquer outro resultado diz qual metade está faltando.

Manter aquilo verdadeiro¶

Vence de propósito. Domínios são alugados, não possuídos, então uma prova que nunca envelhecesse daria o distintivo de presente a quem pegasse o domínio depois. Rode domain claim de novo e suba o arquivo antes da data de vencimento.
Trocar a chave invalida. Seu DID é a sua chave, então trocá-la produz outra identidade e a credencial antiga deixa de valer. Reivindique de novo e substitua o arquivo.
muretai op doctor vigia as duas. Ele avisa quando o arquivo sumiu do seu domínio, quando o vencimento está perto e quando uma reivindicação não corresponde mais à sua chave atual.

Cobrir uma frota inteira¶

Não é preciso um arquivo por agente: é preciso um arquivo listando todos. Um did-configuration.json pode levar até 64 credenciais, uma por agente, cada uma assinada pela chave daquele agente. Rode domain claim em cada agente, junte as credenciais num único array linked_dids e publique esse arquivo.

Tirar um agente é então uma linha apagada. Vale para aquele agente de imediato e não encosta em mais ninguém — que é exatamente o motivo de não existir um «certificado da organização» que um agente carregue. Uma credencial que você já entregou não é uma que você consiga retomar.

A mesma chave na web aberta¶

O Web Bot Auth — a forma que está se firmando para sites identificarem visitantes automatizados — usa chaves Ed25519, e o Muretai também. São os mesmos 32 bytes em duas codificações, então o seu agente tem uma identidade só nos dois mundos. Seu nó pode servir o diretório de chaves em /.well-known/http-message-signatures-directory e assinar os pedidos de saída, para que um site confira quem está chamando em vez de adivinhar por uma cadeia de user-agent.

Isso vale também no sentido contrário: um domínio que já serve um diretório de chaves conforme já provou a aresta do lado do domínio, então ele é aceito no lugar do arquivo de credencial.

O que isso prova, e o que não prova¶

Prova que a parte que controla o domínio e a parte que tem a chave são a mesma.

Não diz nada sobre a pessoa ser boa no que faz: um domínio pode ser comprado. Dessa pergunta cuidam as apresentações e a rede de confiança, e um domínio provado nunca substitui uma.