Verify by DSEO Marketing
EN ES
API

Una API local. Se ejecuta en tu máquina, cuando la arrancas.

Cincuenta y tres operaciones en 127.0.0.1:4177, que sirven los mismos datos que muestra la consola y que usa el cliente de terminal. El documento de abajo se genera desde las rutas que registra el servidor, así que no puede separarse de lo que realmente responde.

Nada está alojado. Nada está desplegado. Ningún endpoint de este producto es accesible desde internet, y ejecutarlo en local no es lo mismo que estar auditado, certificado o publicado.

Implementadolocal y sólo loopback
01 Rutas
MétodoRutaPropósito
POST/v1/artifacts/inspectRegistra un artefacto y recibe su identidad canónica.
POST/v1/assessmentsEnvía un bundle, autoridad, política y pins para evaluación.
GET/v1/assessments/{id}Lee un resultado de evaluación producido previamente.
GET/v1/assessments/{id}/evidenceLee el grafo de evidencia consumido por una evaluación.
GET/v1/assessments/{id}/receiptLee el receipt ligado a una evaluación, si existe.

Leer el documento OpenAPI completo →

02 Qué separa la respuesta 
{
        "assessment_id": "asmt_...",
        "record_valid": true,
        "security_assessment_status": "FAIL",
        "release_authority": false,
        "errors": [ { "code": "...", "message": "..." } ],
        "evidence_ref": "/v1/assessments/{id}/evidence",
        "receipt_ref": "/v1/assessments/{id}/receipt"
      }
03 Decisiones de diseño
  • Idempotencia: el envío de evaluación acepta una clave de idempotencia; los reenvíos devuelven el resultado original.
  • IDs de petición: cada respuesta lleva un id de petición para correlacionar con logs.
  • Hashes de contenido: toda referencia a un objeto incluye su sha256, nunca sólo un nombre.
  • Referencias de política: una política se referencia por digest, igual que lo que el kernel realmente pinnea.
  • Modelo de error: los errores usan los mismos códigos de diagnóstico finitos que devuelve el kernel de referencia.
04 El mecanismo

Cómo funcionaría una integración.

Cómo funciona esto

  1. 01

    Quien llama envía un expediente y sus pins

    Los pins son cuatro digests entregados aparte: qué se espera que sean el expediente, la política, la autoridad y el artefacto.

  2. 02

    El servicio evalúa y responde en tres ejes

    Si el expediente es interpretable, qué muestra la evidencia, y que la autoridad de ejecución es falsa — fijada a falsa en el propio contrato.

  3. 03

    La evidencia y los receipts se piden aparte

    La respuesta lleva referencias en lugar de todo de golpe, para que quien llama decida cuánto quiere profundizar.

  4. 04

    El sistema que llama decide qué hacer

    La API describe una evaluación. Actuar sobre ella corresponde a quien tenga autoridad sobre el sistema en cuestión.

Paso a paso

  1. Abre el documento OpenAPI completo enlazado arriba.

    Verás cinco endpoints, la forma de sus peticiones y respuestas, y un modelo de error.

    Eso significa lo suficiente para planificar una integración, o para que tus ingenieros la juzguen.

  2. Busca release_authority en ese documento.

    Verás aparece con enum: [false].

    Eso significa el contrato prohíbe que ninguna respuesta conceda permiso. Es una garantía de diseño, no una convención.

  3. Mira la sección servers.

    Verás localhost, y un host futuro marcado como x-future-placeholder.

    Eso significa no se está insinuando ninguna dirección activa. Aquí no hay nada funcionando.