Signed Assertion

Every signed assertion involves three distinct entities, as defined by the W3C Verifiable Credentials Data Model:

• Issuer: The entity that creates and cryptographically signs the assertion.
• Holder: The entity that receives and controls the assertion, typically storing it in a digital wallet.
• Subject: The entity about which claims are being made (often the same as the holder).
• Verifier: The relying party that checks the cryptographic signature and issuer authority before trusting the claim.

The assertion is not merely associated with its metadata; it is mathematically bound to it. The issuer generates a digital signature over a hash of the claim set using a private key controlled solely by them. This creates a tamper-evident seal:

• Any modification to the claim (e.g., changing an expiration date) invalidates the signature.
• Verification requires only the issuer's public Decentralized Identifier (DID) and the signature, with no need to phone home to a central server.

Modern signed assertions support selective disclosure and zero-knowledge proofs (ZKPs). A holder can derive a cryptographic proof from the original assertion to satisfy a verifier without revealing the underlying raw data. For example:

• Proving you are over 21 without revealing your exact birthdate.
• Proving you are a citizen of a country without revealing your passport number.
• This is achieved through schemes like BBS+ signatures or Camenisch-Lysyanskaya (CL) signatures, which allow for the generation of proofs of knowledge.

Signed assertions do not require a centralized certificate authority. Issuers are identified by Decentralized Identifiers (DIDs), which are recorded on a distributed ledger or similar verifiable data registry. This architecture enables:

• Self-sovereign identity: Users control their own identifiers.
• Decentralized revocation: Status checks use cryptographic accumulators or bitstring lists published by the issuer, allowing a verifier to check if a credential is still valid without querying a live issuer API.

A single signed assertion can be embedded within another, creating a chain of custody. In the C2PA specification, this is called a Manifest. A photographer's camera signs the raw sensor data (Assertion A). An editor then signs the cropping and color-correction actions, referencing Assertion A (Assertion B). The final published file contains a verifiable chain of all actors and edits, making it impossible to insert a deepfake into the middle of the process without breaking the cryptographic chain.

The internal structure of an assertion uses a subject-property-value triple model, often serialized in JSON-LD. This links claims to globally unique, machine-readable vocabularies:

• "credentialSubject": { "id": "did:example:123", "alumniOf": "https://schema.org/CollegeOrUniversity" }
• This semantic grounding prevents namespace collisions and allows automated reasoning. A verifier knows exactly what alumniOf means because it resolves to a standard ontology, enabling interoperability across completely different systems.