Alliance Charter Draft

Draft Charter v0.1 for the Proof of Cloud Alliance

Purpose

Proof of Cloud ("PoC") is a vendor-neutral alliance that maintains a signed, append-only registry of cloud-hosted server hardware identities (Intel DCAP PPID and AMD SEV-SNP CHIP ID), along with the evidence and endorsements establishing each entry's verification level. The registry's goal is to make it verifiable - not merely asserted - that a workload runs on genuine cloud hardware at a legitimate facility, while being explicit about residual risks and non-goals.

1. Scope & Non-Goals

  • Scope: Define hardware integrity verification levels and methodologies for adding hardware identities to a public, signed registry.
  • Non-Goals: The alliance does not claim protection against all physical attacks or certify the full operational security of any provider.

2. Governance

  • Members: Open to general members. One company = one member = one vote.
  • Chair: Elected for 6-month terms. Responsible for setting agendas, moderating votes, and acting as a tie-breaker (optional vice-chair).
  • Quorum & Voting: Simple majority quorum (e.g. with 8 members, 5 present). Decisions pass by simple majority unless security-critical.
  • Security-critical changes: Schema or protocol changes, as well as emergency revocations, require approval by at least 2/3 of all members.

3. Working Groups

  1. Verification WG: Handles onboarding, evidence review, and revocation proposals.
  2. Methodologies WG: Develops and maintains verification methods, threat models, and schemas.
  3. Ops & Outreach WG: Manages the website, registry infrastructure, key and signature management, snapshots, DNS anchoring, documentation, and community engagement.

4. Verification Levels

We define 3 levels of verification, with higher levels indicating stronger security guarantees. These levels are intentionally defined abstractly, allowing flexibility for future evolution of detailed verification methodologies.

Level 1: Human-Assisted Verification

Verification relies on human agents who collect and validate sufficient evidence to confirm the hardware's integrity.

Examples:

  • Extract hardware id from a remote attestation performed via cloud control plane (e.g. OVH's serial console), verified by a human in a real-time video session
  • Verifying a colocated data-center server via live, human-attended video inspection
  • In case the hardware is in Colocation, members perform a verification of signed Colocation Provider Pledge.

Level 2: Automated Verification

Verification is fully unattended, eliminating the need to trust any human participant in the process.

Examples:

  • Extracting the hardware id from an attestation performed through the cloud control plane (e.g., OVH's serial console), verifiable via zk-TLS
  • vTPM-based cryptographic claims issued by hyperscalers (as described in arXiv preprint arXiv:2510.12469, 2025)
  • Cryptographic proofs generated by tamper-evident RFID beacons

Level 3: Continuous Monitoring

Provides Level 2 security with ongoing monitoring to ensure sustained hardware integrity and detect any violations in near-real time.

Examples:

  • Periodic checks or re-attestations using any Level-2 verification method

5. Registry

The registry is a transparency log that records the latest verified hardware IDs under each vendor. Anyone should be able to verify that a given piece of hardware is included in the registry.

Privacy

Although the registry is public, it does not need to disclose the full list of hardware IDs. This approach keeps the transparency log succinct while preserving vendor privacy. Privacy can be achieved by committing to a list rather than publishing it directly.

For instance, each vendor may register the Merkle tree root representing its verified hardware set. A user who possesses a hardware ID and its Merkle proof can independently verify inclusion.

Transactions

The transparency log must record all changes to registered hardware identities. Each change is expressed as a transaction of the form:

Update(vendor, newCommitment, signatures)

Entries

The evidence associated with a verified hardware unit is organized as a Proof-of-Cloud entry, which is stored as a key-value record:

  • Key: platform_uid - a string to uniquely identify the hardware
    • Intel TDX: intel:tdx:ppid:...
    • AMD SEV-SNP: amd:snp:chipid:...
  • Values:
    • method - how the verification was performed
    • level - verification level (1-3)
    • evidences[] - an array of binary artifacts supporting the verification; contents depend on the verification method
    • timestamp - when the verification was completed
    • endorsements[] - signatures from Proof-of-Cloud members indicating their endorsement (either as witnesses or as independent verifiers of the evidence)

Revocation list

TBD

6. Incidents & Amendments

Flagging SLA

  • Verification WG triages within 72h
  • Emergency quorum may freeze an entry

Amendments

  • Editorial: simple majority
  • Security-relevant: 2/3
← Back to Home