suissAI

Posted on Feb 26

FullAgenticStack WhatsApp-first: RFC-WF-0025

#rfc #webdev #programming #whatsapp

RFC-WF-0025

Certification Attestation & Badge Metadata (CABM)

Status: Draft Standard
Version: 1.0.0
Date: 20 Nov 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0011 (CATS), RFC-WF-0016 (RCMC), RFC-WF-0013 (WKD), RFC-WF-0006 (EAS), RFC-WF-0021 (SECR)
License: Open Specification (Public, Royalty-Free)

Abstract

This document specifies Certification Attestation & Badge Metadata (CABM) for WhatsApp-first systems. CABM defines a canonical, machine-verifiable attestation format for compliance results, including control outcomes (RCMC), audit provenance (CATS), artifact versions, validity windows, and optional cryptographic signatures. CABM enables portable certification claims (e.g., WFS Bronze/Silver/Gold) and verifiable badges without relying on proprietary registries, while preserving evidence traceability to EAS artifacts.

Index Terms— attestation, certification, badges, compliance reports, signatures, verifiable claims, interoperability.

I. Introduction

Once you have specs (RFCs), controls (RCMC), audits (CATS), and discovery (WKD), the next ecosystem problem is: how do you publish a compliance claim that others can verify?

Teams need to say “we’re WFS-compliant” in a way that is:

precise (which controls? which version?)
reproducible (which audit ran?)
time-bounded (validity window)
optionally signed (tamper-resistant)

CABM standardizes that attestation artifact and the metadata needed for badges.

II. Scope

CABM specifies:

A standard attestation artifact format (JSON)
Required metadata for:
- audited system identity
- spec/control versions used
- audit tool provenance (CATS)
- control outcomes + severity
- evidence references
- validity window + renewal expectations
Optional cryptographic signature block
Well-known publication endpoint recommendation (via WKD)

CABM does not define the certification program itself (pricing, governance); it defines the technical claim format.

III. Normative Language

MUST, MUST NOT, SHOULD, SHOULD NOT, MAY are normative.

IV. Definitions

Attestation: A verifiable statement produced by an audit run summarizing compliance results.
Badge: A human-facing label (e.g., Bronze/Silver/Gold) derived from attestation rules.
Issuer: Entity producing the attestation (self-attested or third-party).
Verifier: Any party validating the attestation for trust decisions.

V. Design Goals

CABM MUST ensure:

G1. Verifiability: machine-readable, deterministic structure
G2. Traceability: links to CATS results and EAS evidence references
G3. Portability: usable across organizations and toolchains
G4. Freshness: validity window prevents stale claims
G5. Optional Cryptographic Integrity: signature block when needed

VI. Attestation Artifact (CABM-JSON)

A. Required Fields

An attestation MUST contain:

cabm_version (SemVer)
attestation_id (unique)
issued_at (timestamp)
valid_from, valid_until
issuer (id, type, contact)
subject (system identity + environment + tenant scope)
spec_versions (WFS spec version, RCMC version, CATS version)
results (control outcomes summary + per-control list)
evidence_refs (references to EAS artifact ids or evidence query links)
badge (optional derived label + ruleset id)
integrity (optional signature + hash)

B. Canonical Example

{
  "cabm_version": "1.0.0",
  "attestation_id": "uuid",
  "issued_at": "2026-02-22T00:00:00Z",
  "valid_from": "2026-02-22T00:00:00Z",
  "valid_until": "2026-05-22T00:00:00Z",
  "issuer": {
    "issuer_id": "fullagenticstack",
    "issuer_type": "third_party",
    "display_name": "FullAgenticStack Initiative"
  },
  "subject": {
    "system_id": "acme-pharma-wos",
    "environment": "staging",
    "tenant_scope": "tenant-staging-001",
    "discovery": "/.well-known/wfs.json"
  },
  "spec_versions": {
    "wfs_spec_version": "1.0.0",
    "rcmc_matrix_version": "1.0.0",
    "cats_tool_version": "1.0.0"
  },
  "results": {
    "summary": {
      "passed": 42,
      "failed": 0,
      "skipped": 3,
      "critical_failed": 0
    },
    "controls": [
      { "control_id": "WFS-C-001", "status": "pass", "severity": "critical" },
      { "control_id": "WFS-I-002", "status": "pass", "severity": "critical" }
    ]
  },
  "evidence_refs": [
    { "type": "eas_artifact_id", "value": "artifact_123" },
    { "type": "eas_artifact_id", "value": "artifact_456" }
  ],
  "badge": {
    "level": "Gold",
    "ruleset_id": "wfs-cert-v1",
    "notes": "No critical failures; IDS+OoC+RCP verified in sandbox."
  },
  "integrity": {
    "hash_alg": "sha256",
    "hash": "…",
    "signature": {
      "sig_alg": "ed25519",
      "sig": "…",
      "key_id": "issuer-key-1"
    }
  }
}

VII. Control Outcome Semantics

Each control entry MUST include:

control_id (RCMC)
status ∈ pass | fail | skip
severity ∈ critical | high | medium | low
optional reason_code for failures
optional remediation_hint (short)

Attestations MUST NOT claim a badge level if any critical control is failed (unless the ruleset explicitly defines exceptions and lists them).

VIII. Badge Derivation Rulesets

Badges MUST be derived from a declared ruleset:

ruleset_id MUST be included
ruleset MUST define:
- required controls per level
- allowed skips
- expiry/renewal policy
- environment constraints (prod vs staging)

Rulesets MAY be public documents; CABM does not mandate location but recommends WKD advertisement.

IX. Publication and Discovery

Systems MAY publish attestations at:

/.well-known/wfs/attestation.json (recommended)

If published, /.well-known/wfs.json SHOULD link to it under endpoints.attestation.

Attestations MAY also be attached to build artifacts in CI/CD.

X. Integrity and Signatures (Optional but Recommended)

A. Hashing

If integrity.hash exists, it MUST be computed over canonicalized JSON excluding the integrity object itself.

B. Signatures

If signature exists:

signature MUST cover the attestation hash
key identifiers MUST be provided
verifiers MUST be able to fetch public keys via a declared method (out of scope; referenced via issuer metadata)

XI. Privacy Considerations

Attestations MUST avoid leaking:

tenant PII
secrets
internal topology

Evidence references SHOULD be opaque IDs; detailed evidence access remains scope-gated via EAS query endpoints.

XII. Relationship to Other RFCs

CATS (0011): audit results provenance
RCMC (0016): stable control IDs referenced in attestations
WKD (0013): discovery/publishing of attestation endpoints
EAS (0006): evidence references for verifiability
SECR (0021): extension rules for future fields and version negotiation

XIII. Conclusion

CABM turns “we’re compliant” into a verifiable, portable artifact. By standardizing an attestation format with explicit control outcomes, provenance, validity windows, and optional signatures, WhatsApp-first compliance becomes publishable, comparable, and automation-friendly—ready for certification ecosystems and supply-chain trust.

References

[1] RFC-WF-0011, Compliance Audit Toolkit Spec (CATS).
[2] RFC-WF-0016, Reference Compliance Matrix & Control IDs (RCMC).
[3] RFC-WF-0013, Well-Known Discovery & Interop Endpoints (WKD).
[4] RFC-WF-0006, Evidence Artifact Schema (EAS).
[5] RFC-WF-0021, Schema Extensions & Compatibility Rules (SECR).

Concepts and Technologies

Compliance attestations, verifiable badges, control outcome catalogs, audit provenance, validity windows, optional signatures, well-known publication, evidence references, machine-verifiable certification claims.

DEV Community