C2PA Identity Assertions

A C2PA manifest normally identifies the software, hardware, or service that generated and signed the claim. That product-level identity is essential, but it does not necessarily identify the photographer, editor, publisher, company, or other person or organization behind the content.

Identity assertions add that missing layer. They allow a named actor to associate a verifiable identity with a specific asset and with selected provenance statements about that asset. The identity signal is signed independently from the ordinary C2PA claim signature, so a verifier can distinguish the tool that generated the manifest from the human or organization taking responsibility for particular parts of the recorded history.

The identity assertion is defined by the Creator Assertions Working Group, or CAWG, rather than by the core C2PA specification. C2PA 2.4 explicitly recommends CAWG specifications for human and organizational provenance. CAWG Identity Assertion 1.3 was ratified by the Decentralized Identity Foundation on August 17, 2026.^[1]

The identity gap in an ordinary C2PA manifest

The ordinary C2PA trust model is centered on the claim generator and its signing credential. A conforming camera, editing application, cloud service, or AI system creates a claim, hashes the assertions in that claim, and signs it. That signature can support confidence that the manifest came from a recognized product and has not been altered. The process is explained in How C2PA Signing Works.

The product that issued the manifest may be acting on behalf of someone else. A newsroom publishing system may sign a claim while acting for a media organization. A camera application may create a manifest while being operated by a photojournalist. A creative tool may record edits made by several people. A model-serving platform may issue provenance for content requested by a customer.

Trying to squeeze all of those relationships into the product signing certificate would create ambiguity. The certificate would have to identify both the machine responsible for constructing the claim and every human or organization associated with its contents. It would also be unclear which person was responsible for which assertion.

CAWG identity assertions solve this by adding a second, scoped signature. The claim generator remains responsible for the C2PA manifest as a technical artifact. A named actor separately signs a payload that identifies the assertions and asset binding for which that actor is willing to claim authorization, participation, or responsibility. The identity assertion is then included in the manifest and protected again by the C2PA claim signature.

This separation is why identity assertions should be understood as an additional trust signal, not a replacement for product signing. For a broader explanation of these layers, see C2PA Certificates and Trust Lists and What C2PA Proves - and What It Does Not Prove.

Two signatures, two different responsibilities

The identity assertion does not sign the entire C2PA claim. It signs a deliberately scoped signer payload. That payload contains cryptographic references to the assertions selected by the credential holder, and it must include the hard-binding assertion that connects the active manifest to the asset. The ordinary C2PA claim then includes and protects the identity assertion alongside the other assertions in the manifest.

This creates overlapping protection. The named actor or aggregator signs the identity-specific payload. The claim generator signs the complete claim that contains the identity assertion. A verifier evaluates both signatures and keeps their meanings separate.

The scope can be narrower than the complete manifest. A photographer may sign the capture action and the asset binding. An editor may sign the edit actions. A publisher may sign publication-related metadata. The claim generator can still sign all of those assertions as part of one manifest without implying that every named actor endorsed every statement.

The actors and credentials involved

Identity assertions use several related terms. They should not be collapsed into a single generic word such as creator or signer.

The distinction between the named actor and credential holder is especially important. A company might be the named actor while a managed signing service holds the private key. An individual creator might be the named actor while an identity claims aggregator signs the asset-specific credential. The signature is valid only if the relevant credential holder was authorized to act for the named actor under the applicable trust framework.

What is inside an identity assertion?

The CAWG identity assertion uses the label cawg.identity. Each instance represents exactly one credential holder and contains a signed data structure called signer_payload. Multiple instances can appear in the same manifest when several people or organizations need to be represented.

The referenced-assertions list is the heart of the scope. Each entry is a hashed URI reference. The reference identifies an assertion and commits to its exact bytes through a cryptographic hash. The selected assertion may be in the same C2PA claim or in a claim reached by following ingredient manifests. The same assertion cannot be referenced twice.

The list must include the applicable hard-binding assertion and must not include a different hard binding. The identity assertion may also reference another identity assertion, provided the references do not form a cycle. It cannot reference itself because the hash of the final identity assertion is not available before its own signer payload is signed.^[3]

Requiring the hard binding is a security measure. Without it, an attacker might copy a valid identity assertion from one asset into another and falsely associate the victim's identity with unrelated content. Because the named actor signs a reference to the content binding, a verifier can detect that the identity assertion was issued for a different protected asset representation.

What the named actor is actually signing

An identity assertion should generally be interpreted as evidence that the named actor authorized or actively participated in the production of the asset in the way described by the referenced assertions. The exact conclusion depends on which assertions are referenced, the role declared, the credential method, and the trust policy used by the verifier.

Consider an identity assertion that references a hard binding, a capture action, and selected capture metadata. The named actor is associating their identity with that asset and those statements. If the same identity assertion does not reference a later editing action, it should not be presented as though the actor approved the edit.

The identity assertion specification is deliberately cautious about legal conclusions. It should not be treated as a claim of copyright ownership, legal authorship, rights transfer, or entitlement to compensation. Those claims may be expressed elsewhere, including in separate metadata, rights, or consent assertions, but they are not automatically created by adding identity.

Named actor roles

The optional role field helps explain the actor's relationship to the asset. CAWG Identity Assertion 1.3 recommends the following role labels, while also allowing appropriately namespaced extensions.

A role is part of the named actor's signed statement, but it is not independently proven simply because the signature validates. The credential may prove control over an organizational identity or a verified online account; whether the actor legitimately qualifies as the creator, editor, or publisher remains a contextual question. Interfaces should display the role as a claimed relationship, not as a legal judgment.

Multiple people and organizations

A single asset can contain any number of identity assertions. Each instance receives a unique assertion label, allowing a verifier to keep the scopes and signatures distinct. This is essential for collaborative work.

• A photographer can associate their identity with capture actions and the asset binding.
• A retoucher can associate their identity with specific editing actions.
• A producer can sign production-related metadata and approvals.
• A publisher can associate its organizational identity with publication or distribution assertions.

The scopes may overlap. Two collaborators can both reference the same hard binding and a shared metadata assertion while separately signing the actions they performed. An organizational identity assertion can also reference an individual identity assertion, allowing an organization to add an additional trust signal around a contributor. Cyclic references are prohibited.

This graph-like model is more precise than one unstructured creator field. It preserves who signed what, which relationship each actor claimed, and which trust method supports each identity.

The two current credential methods

CAWG Identity Assertion 1.3 defines two current signature and validation methods. They solve different identity problems and should be presented differently.^[4]

Identity claims aggregation

Identity claims aggregation is designed for named actors who do not directly issue an asset-specific signature with their own long-lived credential. An identity claims aggregator verifies one or more identity signals, retains the relationship for later use, and then creates a unique credential for a particular C2PA asset when the actor asks to attach identity.

The underlying signals can include document verification, control of a website or domain, a social-media account, an email relationship, a cryptographic wallet address, a professional accreditation, or another identity-provider claim. The asset-specific credential can record the verified name, username, address, URI, verification method, verification time, and identity-provider details, depending on the signal.

In this method, the aggregator signs. The result should not be described as though the named actor directly applied their own private-key signature. The correct interpretation is that the aggregator verified specified identity signals and attests that the same actor presented the asset and claimed a role in its production.

Trust therefore depends on the aggregator, the identity providers, their verification methods, the dates of verification, credential status, and the verifier's policy. A verified social account and a government-document check provide different assurance. A verified website shows a relationship with that URI at the time of verification; it does not endorse everything that may later appear at the website.

X.509 certificates and COSE signatures

The X.509 method is intended for an actor whose identity is represented by a certificate and whose credential holder can sign directly for that actor. The signer payload uses the signature type cawg.x509.cose, and the signature is carried in a COSE structure with the relevant certificate chain and, where available, trusted time and revocation evidence.

This model is particularly important for organizational identity. A news organization, government agency, campaign, company, or institution can use an identity credential that identifies the organization rather than relying on the product certificate used by the C2PA claim generator. The claim-generating application still signs the C2PA claim; the organization separately signs the assertions for which it accepts responsibility.

Certificate validation remains a policy decision. The verifier must evaluate the chain, credential purpose, trusted time, revocation status, and accepted trust sources. These concepts are covered in C2PA Certificates and Trust Lists.

A version note for organizational profiles

C2PA 2.4 recommends the CAWG Organizational Identity Profile for organizations. Implementers should nevertheless record the exact profile and specification versions they support. As of August 2026, the ratified Organizational Identity Profile 1.0 names C2PA 2.2 or 2.3 and CAWG Identity Assertion 1.2. A 1.1 draft adds C2PA 2.4 support and separates generator and validator requirements, but it still names Identity Assertion 1.2. The current ratified Identity Assertion is 1.3.^[7]

That temporary version gap does not make organizational identity unusable. It means a product should avoid a vague claim such as "CAWG compliant" without stating the precise profile, identity-assertion, C2PA, metadata-assertion, and credential-method versions it implements. Conformance claims should match an actual published profile rather than an informal combination of newer components.

How an identity assertion is created

Identity signing is part of the final manifest-generation workflow, not a metadata field that can be inserted casually after the fact. A reliable generator performs the following sequence:

1. Identify the named actor, the role or roles to be expressed, and the credential method allowed by policy.

2. Obtain informed consent for the identity data, verification details, and roles that will be disclosed.

3. Create the C2PA assertions that the named actor will reference. These assertions must exist before their hashes can be placed into the signer payload.

4. Create the applicable content binding and include that hard-binding assertion in the referenced-assertions list.

5. Build signer_payload with the referenced assertions, signature type, and optional role values.

6. Present the exact signer payload to the credential holder or identity claims aggregator for signature.

7. Independently validate the returned signature before using it.

8. Replace any reserved placeholder with the completed identity assertion, construct the final C2PA claim, and apply the claim generator's signature.

9. Validate the completed asset and manifest independently before release.

Some file formats and data-hash workflows require the generator to reserve space for the completed identity assertion before the asset binding can be finalized. CAWG therefore defines padding fields and a multiple-step process that fits within C2PA's normal final-layout signing model. The practical rule is the same as for ordinary C2PA signing: do not modify the protected output after the relevant bindings and signatures have been created.^[3]

How an identity assertion is validated

Identity validation begins only after the surrounding C2PA manifest has been validated as at least well-formed. A consumer should not interpret identity data from a manifest whose structure or claim integrity has already failed.

A validator then performs several distinct checks:

• Parse the cawg.identity assertion and confirm that the required CBOR fields are present.
• Resolve every referenced assertion and confirm that it appears in the same claim or in a reachable ingredient claim.
• Recalculate each referenced assertion hash and reject duplicates or mismatches.
• Confirm that the list contains the applicable hard-binding assertion and no conflicting hard binding.
• Validate the signature according to the declared signature type.
• Evaluate the credential, issuer, time, revocation status, and trust configuration for that credential method.
• Report the result for each identity assertion separately from the C2PA manifest's own validity and trust result.

CAWG distinguishes identity assertions that are trusted, well-formed but not trusted, and revoked. Those descriptions belong to the identity trust layer. They should not be substituted for the C2PA manifest states of Well-Formed, Valid, and Trusted, and they should not be collapsed into one global "verified" label.

The surrounding C2PA validation process is described in How C2PA Verification Works.

Trust is more than certificate mathematics

Identity Assertion 1.3 separates three forms of trust. This is a useful framework for both system design and user-interface language.

Technical trust can establish a strong relationship between a credential and an asset. Governance trust can explain why the issuer and verification method are accepted. Reputation trust remains a human or policy judgment. A well-known organization can issue misleading content; an unknown but careful creator can issue accurate content. Identity makes the source more inspectable, not automatically truthful.

Identity is not ownership, copyright, or factual truth

An identity assertion can support evidence that a particular named actor authorized or participated in the statements it references. It does not, by itself, establish that the actor legally owns the asset, holds copyright, received every required consent, or has authority to license the work. It also does not prove that the assertions are objectively accurate.

The distinction matters in several common cases:

• A photographer can sign an identity assertion without being the copyright owner under an employment agreement.
• A publisher can sign an organizational identity assertion without having created every ingredient in the asset.
• A social account can be verified while still being operated dishonestly or after an account compromise.
• A role of cawg.creator can be signed by the credential holder but disputed by another person outside the C2PA system.
• An identity assertion can be valid even when the surrounding provenance history is incomplete.

For this reason, identity results should be read alongside the limitations described in What C2PA Proves - and What It Does Not Prove.

Privacy, consent, and redaction

Identity can make Content Credentials more useful and more dangerous. A public name, professional affiliation, verified website, social account, credential issuer, or verification date can expose personally identifiable information, create persistent linkability across assets, or put a vulnerable creator at risk.

CAWG user-experience guidance therefore treats participation as opt-in. Before manifest signing, an actor should be told what identity elements will be published and should be able to add, remove, or decline them. Consent should be granular: agreeing to publish an organizational affiliation should not silently publish a government-verified legal name or personal social profile.^[5]

Implementations should minimize disclosure. A credential can represent an organization, a professional identity, a pseudonymous identity, or a verified account without exposing unnecessary source documents. Identity providers and aggregators should retain only what their assurance and audit requirements justify, with explicit retention, deletion, and breach-response policies.

Later workflows may need to redact identity for safety. C2PA redaction mechanisms can preserve evidence that an earlier assertion was removed without requiring the public version to expose the original identity. Redaction policy should consider the safety of the named actor, the needs of investigators, legal obligations, and whether a less identifying organizational assertion can replace an individual one.

How identity should be presented

A verifier should display identity as a distinct section within the Content Credentials experience rather than mixing names into ordinary metadata. The interface should make several distinctions visible:

• Individual identity versus organizational identity.
• Direct X.509 signature versus identity claims aggregation.
• Trusted identity versus well-formed but untrusted identity versus revoked identity.
• Verified claims versus self-declared or merely referenced information.
• The actor's role and the exact assertions covered by that actor's signature.
• The issuer, verification method, verification date, and root of trust where useful and safe.

Progressive disclosure is well suited to this information. A compact first view may show a trusted organization and role. A second view can list people and concise verification status. A detailed view can expose the credential method, issuer relationships, status evidence, referenced assertions, and validation messages.

Warnings should be local to the affected identity assertion. An expired, revoked, or untrusted identity credential does not necessarily invalidate unrelated identity assertions or the entire C2PA manifest. Color must not be the only indicator, and linked websites or social accounts should be clearly labelled as verified or unverified.

Three practical identity workflows

1. Photojournalist, editor, and publisher

A photojournalist captures an image with a C2PA-aware camera application. The journalist signs an identity assertion referencing the capture action and hard binding, with the role cawg.creator. An editor later creates a new rendition and signs a separate identity assertion referencing the editing actions, using cawg.editor. The newsroom publishing system creates the final claim and the organization adds an identity assertion with cawg.publisher.

A verifier can now distinguish the camera and editing products from the people and organization involved. It can also see that the photographer did not necessarily sign the later crop and that the publisher did not necessarily make the capture statement.

2. Official organizational media

A government agency or brand uses an X.509 identity credential to sign all official public assets. The credential identifies the organization, while the C2PA claim certificate identifies the conforming publishing product. The organizational identity assertion references the hard binding, publication-related assertions, and selected metadata.

Audiences can use the identity signal to distinguish official media from imitations, provided their verifier accepts the organization's credential chain or trust source. The signal does not prove that every statement in the media is correct; it supports evidence that the organization issued or authorized the covered provenance.

3. Independent creator using an identity aggregator

An independent illustrator verifies control of a website and a social profile through an identity claims aggregator. When exporting a new asset, the authoring tool asks the aggregator to issue an asset-specific credential linking those identity signals to the final work. The creator selects the role cawg.creator and approves which verified identifiers are published.

The consumer should see that the identity was attested by the aggregator, which signals were verified, how they were verified, and when. The interface should not state that the illustrator directly signed with the website or social-platform credential unless that is actually what the credential method establishes.

Security and abuse risks

A cryptographically valid identity assertion can still be abusive if the signing service is willing to attach a trusted identity to content the actor did not authorize. Identity systems therefore need the same production security, anti-abuse, and audit discipline as payment or document-signing systems.

Implementation recommendations

• Treat the C2PA claim signer and the named actor as separate identities in the data model, API, audit log, and user interface.
• Define the permitted credential methods, issuers, assurance levels, roles, and trust sources before implementing the signing flow.
• Require explicit actor consent for every identity element and referenced assertion before signature authorization.
• Show a human-readable summary of the signer payload, including the asset, role, and assertions being covered.
• Always include and validate the correct hard binding; never treat identity as detached profile metadata.
• Support multiple independently scoped identity assertions rather than merging all contributors into one field.
• Independently validate the returned identity signature before constructing and signing the final C2PA claim.
• Preserve credential chains, trusted time, revocation evidence, trust-policy versions, and validation results needed for later audit.
• Apply strict authorization, rate limits, tenant isolation, key protection, and abuse detection to identity-signing services.
• Sanitize all names, URIs, provider data, and status messages before display; identity assertions are untrusted input until validated.
• Present issuer, verification method, role, scope, and status separately; avoid one ambiguous verified badge.
• Maintain an explicit compatibility matrix for C2PA, Identity Assertion, Organizational Identity Profile, Metadata Assertion, SDK, and credential-method versions.
• Provide redaction, retention, deletion, and incident-response workflows for sensitive or compromised identities.

These controls should be incorporated into the larger architecture described in the C2PA Implementation Guide.

Common misunderstandings

The simplest mental model

• The C2PA claim generator signs the manifest as a product or service.
• A CAWG identity assertion adds a separate signature associated with one named actor.
• The named actor can be an individual or an organization.
• The signature covers a signer payload containing selected assertion hashes, the relevant hard binding, a credential method, and optional roles.
• Multiple actors can sign different or overlapping parts of the same provenance history.
• Identity claims aggregation and X.509/COSE are the two current validation methods in Identity Assertion 1.3.
• Technical trust, governance trust, and reputation trust are different judgments.
• Identity does not automatically establish ownership, copyright, truth, or a complete history.
• Consent, privacy, scope, versioning, key security, and precise presentation are part of the implementation - not optional polish.

Identity assertions make Content Credentials more humanly meaningful by showing who is willing to stand behind particular provenance statements. Their strength comes from precision: which actor, which credential, which role, which assertions, which asset, which trust framework, and which validation result. A system that preserves those distinctions can add useful attribution and accountability without turning identity into an unsupported claim of truth.

Sources and notes

Technical source notes are limited to exact structural, normative, version-specific, and current ecosystem claims. The primary sources are published by C2PA and the Creator Assertions Working Group.

[1] C2PA 2.4, Human and Organizational Identity Recommendation. C2PA recommends CAWG specifications for human and organizational provenance and the CAWG Organizational Identity Profile for organizations. See also CAWG Identity Assertion 1.3, ratified by DIF on August 17, 2026.

[2] CAWG Identity Assertion 1.3, sections 1 and 5. Scope, the independent trust signal, the cawg.identity structure, signer_payload, signature, and one-credential-holder-per-instance model.

[3] CAWG Identity Assertion 1.3, sections 5-7. Referenced-assertion requirements, hard-binding inclusion, roles, multiple instances, creation order, multiple-step processing, and validation.

[4] CAWG Identity Assertion 1.3, sections 8-9. Identity claims aggregation, X.509 and COSE signatures, credential and status validation, technical/governance/reputation trust, and threat considerations.

[5] CAWG User Experience Guidance 1.0. Consent, privacy, progressive disclosure, verified versus unverified identity, issuer and method presentation, organizational and individual identity, and warning states.

[6] C2PA Technical Specification 2.4, especially assertions, claims, content bindings, manifest trust, ingredient manifests, redaction, and multiple-step signing. These mechanisms provide the surrounding C2PA structure in which CAWG identity assertions operate.

[7] CAWG Organizational Identity Profile 1.0 and Organizational Identity Profile 1.1 draft. Current profile requirements and the version transition toward C2PA 2.4 support.