# §6 — Confianza y verificación

Cabuya 0.1 · Normativa

Canonical: https://cabuya.org/es/developers/spec/0.1/6-trust-and-verification
Language: es

> Esta página es la traducción al español, y es informativa: donde las dos difieran, rige el texto en inglés. Está versionada junto a la sección que traduce, así que cambiar una sin la otra se ve en la revisión.

---


# §6 — Confianza y verificación

## §6.1 El bloque de verificación (Core)

Tres equipos del ecosistema lo inventaron por separado — la especificación lo
adopta como Core:

- **`last_confirmed_at`** — la **clave es REQUIRED en todos los registros;
  `null` es legal y honesto** («nunca se confirmó»). Omitirla no cumple.
- `confirmed_by` — un **token de rol** (`team` | `volunteer` |
  `official_source` | `partner:{publisher_id}`), nunca el nombre de una
  persona.
- `confirmation_method` — enum cerrado.
- `confirmations_24h`, `contradictions_active`.
- **`last_reported_absent_at`** — la confirmación negativa es de primera
  clase.
- **`updated_at` ≠ `last_confirmed_at`** (CR-1): las semánticas de frescura no
  son intercambiables — **editar no es confirmar**.

## §6.2 Mostrar la obsolescencia

Los consumidores MUST mostrar la antigüedad (§4.3, regla 2). Los publicadores
SHOULD definir `expires_at` en los lugares temporales por naturaleza.

## §6.3 Sin firmas en 0.1

La gestión de llaves es el costo que los equipos de voluntarios fallan de forma
más confiable, y el riesgo dominante del modelo de amenazas (datos de lugares
envenenados) se mitiga en la capa del **registro** (publicadores revisados,
URL canónicas) y en la capa de **escritura** (colas de moderación), no con
firmas por registro.

**Ruta de actualización (v1):** llaves publicadas en el manifiesto más firmas
desprendidas del feed (`{feed-url}.sig`), opcionales por publicador — el sobre
ya lleva `publisher_id`, así que el ancla de confianza existe.

Amenazas consideradas y sus mitigaciones: suplantación del feed (HTTPS más la
URL canónica del registro) · suplantación de identidad (revisión del registro)
· lugares envenenados (cola de moderación, `contradictions_active` y las
comprobaciones de procedencia del validador) · ocupación de identificadores
(la regla de espacio de nombres de §5 y el 409) · daño por datos obsoletos
(mostrar la frescura es obligatorio) · amplificación por agregadores
(preservación de la cadena, §4.3 regla 4).

---

## Navegación del Sitio

- [Inicio](https://cabuya.org/es)
- [Especificación](https://cabuya.org/es/developers/spec)
- [Esquemas](https://cabuya.org/es/developers/schemas)
- [RFCs](https://cabuya.org/es/rfcs)
- [Cambios](https://cabuya.org/es/changelog)
- [Desarrolladores](https://cabuya.org/es/developers)
- [Registro](https://cabuya.org/es/registry)
- [Gobernanza](https://cabuya.org/es/governance)
- [Participar](https://cabuya.org/es/join)
- [GitHub](https://github.com/Cabuya)
- [Repositorio de la skill](https://github.com/Cabuya/cabuya-skill)
- [Registro fundacional](https://github.com/Cabuya/cabuya.org/tree/main/docs/context)