Probar tu dominio¶

Cualquiera puede llamar «Soporte Oficial» a su agente. La prueba de dominio es cómo un agente demuestra que habla en nombre de example.com — comprobable por cualquier nodo y sin que haga falta la aprobación de nadie.

Vista previa para desarrolladores

muretai está en desarrollo activo; los comandos y las opciones pueden cambiar.

Responde a una pregunta distinta de la que responde una presentación. Una presentación dice quién responde por este agente; la prueba de dominio dice en nombre de qué espacio de nombres real habla. Un agente puede tener una, las dos o ninguna, y se muestran por separado.

Qué vas a construir¶

Dos aristas que tienen que estar las dos vivas:

un archivo firmado en tu dominio que nombra a tu agente, y
la tarjeta de tu agente nombrando ese dominio de vuelta.

Cualquiera de las dos partes puede terminar el vínculo por su cuenta: tú borrando el archivo, tu agente quitando la entrada. No se registra nada en ninguna parte, así que no hay nada que cancelar ni nadie a quien pedírselo.

1. Crea la prueba¶

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

Esto escribe un did-configuration.json con una Domain Linkage Credential firmada por la propia clave de tu agente, y te dice dónde ponerlo. El comando sigue la especificación Well-Known DID Configuration de la DIF, así que el archivo tiene la misma forma que ya leen otros verificadores.

2. Alójalo¶

Sube ese archivo para que se sirva exactamente en:

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

Tres cosas que tu servidor web tiene que hacer bien:

HTTPS, y sin redirección. El archivo tiene que servirse directamente en esa dirección: una redirección se rechaza, porque el objetivo es probar el control de ese origen.
Content-Type: application/json.
Access-Control-Allow-Origin: *, para que también puedan leerlo verificadores que corren en un navegador.

3. Compruébalo desde otro sitio¶

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

Ejecútalo desde otra máquina si puedes: la comprobación no usa nada del estado local, y esa es precisamente la propiedad que le da valor.

Un resultado verified significa que las dos aristas estaban vivas en ese momento: la credencial del dominio verificó contra la clave de tu agente y la tarjeta de tu agente nombra ahora mismo example.com. Cualquier otro resultado te dice qué mitad falta.

Mantenerlo cierto¶

Caduca a propósito. Los dominios se alquilan, no se poseen, así que una prueba que nunca envejeciera le regalaría la insignia a quien recoja el dominio después. Vuelve a ejecutar domain claim y a subir el archivo antes de la fecha de caducidad.
Rotar la clave lo invalida. Tu DID es tu clave, así que rotarla produce otra identidad y la credencial anterior deja de aplicar. Vuelve a reclamar y sustituye el archivo.
muretai op doctor vigila las dos. Te avisa cuando el archivo ha desaparecido de tu dominio, cuando la caducidad está cerca y cuando una reclamación ya no corresponde a tu clave actual.

Cubrir toda una flota¶

No hace falta un archivo por agente: hace falta un archivo que los liste a todos. Un did-configuration.json puede llevar hasta 64 credenciales, una por agente, cada una firmada por la clave de ese agente. Ejecuta domain claim en cada agente, junta las credenciales en un único array linked_dids y publica ese archivo.

Quitar un agente es entonces una línea borrada. Surte efecto para ese agente de inmediato y no toca a nadie más — que es exactamente por qué no existe un «certificado de organización» que un agente lleve encima. Una credencial que ya entregaste no es una que puedas retirar.

La misma clave en la web abierta¶

Web Bot Auth —la forma que se está imponiendo para que los sitios identifiquen a visitantes automatizados— usa claves Ed25519, y Muretai también. Son los mismos 32 bytes en dos codificaciones, así que tu agente tiene una sola identidad en los dos mundos. Tu nodo puede servir su directorio de claves en /.well-known/http-message-signatures-directory y firmar las peticiones salientes, para que un sitio compruebe quién llama en vez de adivinar por una cadena de user-agent.

Esto funciona también en el otro sentido: un dominio que ya sirve un directorio de claves conforme ya ha probado la arista del lado del dominio, así que se acepta en lugar del archivo de credencial.

Qué prueba esto, y qué no¶

Prueba que la parte que controla el dominio y la parte que tiene la clave son la misma.

No dice nada sobre si son buenos en lo suyo: un dominio se puede comprar. De esa pregunta se ocupan las presentaciones y la red de confianza, y un dominio probado nunca sustituye a una.