Reshaping the Section 9.3 Trust Scenarios into a more general framework

When we introduce the general-purpose verifiable credential bindings with more transportable credentials & support for verifiable presentations (as is currently underway), we open the door to use cases that fall outside the concrete Trust Scenarios in Sections 9.3.1 and 9.3.2 of the Identity Assertion spec. However, these use cases do not stray outside the framework those sections implicitly establish.

One specific use case is the following:

- An actor behaves much like the current “identity claims aggregator” – it collects and verifies identity credentials from one or more trusted issuers. 
- Instead of immediately producing an identity assertion that is bound to a specific C2PA asset, this actor restates the upstream credential(s) into a new, unbound, signing-enabled credential of its own.
- That new credential can then be used later, in a 9.3.1-style flow, to introduce content binding by signing a `signer_payload` for a specific asset using a verifiable presentation. 

This pattern is not cleanly captured by either 9.3.1 or 9.3.2 as currently written, but it clearly fits within the same trust model. The restatement step “looks like” 9.3.2, but because the result is an unbound, signing-enabled credential, its later use to bind content falls squarely into the 9.3.1 pattern.

I’d therefore like to propose adding a Section 9.3.3 that explicitly generalizes the model underlying 9.3.1 and 9.3.2, as well as revisiting whether the existing Sections 9.3.1 and 9.3.2 are still the clearest way to present things once we've established that generalization.

⸻

Proposed generalized model (9.3.3)

Assume a governed set of trusted issuers. Consumers trust that when these issuers make identity statements, those statements are accurate, and that consent/delegation between named actors and credential holders is handled at the governance layer. 

Every credential produced in this system can be described along two independent axes:

1. Binding axis

- Bound – the credential (or signature) is already tied to a specific C2PA asset (via the signer_payload and content binding). 
- Unbound – the credential only carries identity/attributes, with no specific content binding yet.

2. Signing axis

- Signing-enabled – the holder can generate new signatures (e.g., over new signer_payloads), and thus introduce new bindings later.
- Non-signing – the credential cannot be used to sign new payloads; it can only be presented/verified.

Within this framework, any trusted issuer can:

- Take existing credential(s) as input.
- Produce a new credential that is: bound or unbound, and signing-enabled or non-signing.
- Copy, filter, aggregate, or otherwise restate information from upstream credentials.

Similarly, any holder of a signing-enabled credential can sign content binding information onto the credential on behalf of the named actor, relying on the consumer's transitive trust relationship with the credential issuer.

The length of the issuer chain (original issuer → restating issuer → another restating issuer → … → signer that finally binds to content) is not special: verifiers simply need to be able to validate the entire chain of issuers back to their configured roots of trust and check revocation. 

⸻

9.3.1 and 9.3.2 as special cases

Within this generalized model:

9.3.1 Named actor as issuer is the case where:

- We already have a trusted, unbound, signing-enabled credential about the named actor. 
- The holder of that credential uses its signing capability to introduce the content binding by signing the `signer_payload` for a specific asset.
- The resulting signature is the identity assertion (an asset-specific credential).

In other words, we start from an unbound, signing-enabled identity credential, and use its signing ability to add the content binding directly.

9.3.2 Named actor without signature authority is the case where:

- We have a trusted, unbound, non-signing credential about the named actor. 
- A restating issuer consumes that credential, verifies it according to its own policies, and issues a new credential of its own that restates the identity information.
- That new credential is bound to a particular asset, so it is the identity assertion.

In other words, we start from an unbound, non-signing identity credential, have another trusted issuer restate it into a new credential, which also introduces the content binding.

⸻

Example new use case enabled by this generalization

The “VC binding” use case I opened with then becomes straightforward to describe:

1. Upstream identity: A named actor has one or more trusted, unbound, non-signing credentials issued by identity providers.
2. Restatement: Another trusted issuer (e.g., an identity claims aggregator) restates those credentials into a new unbound, signing-enabled credential.
3. Later binding: That new credential is used later, by whoever controls it, to sign `signer_payload`s for specific assets.

This uses:

- a 9.3.2-style restatement step without content binding, followed by
- a 9.3.1-style binding step, driven by the newly created signing-enabled credential.

⸻

Questions for the group

1. Placement / structure

- Should this generalized model become a new Section 9.3.3 (“Generalized trust model for identity assertions”), with 9.3.1 and 9.3.2 explicitly called out as examples/special cases?
- Or should we consider replacing the current 9.3.1 and 9.3.2 text with the generalized model, and then describe the existing flows as worked examples within that section?

2. Threats & harms

- Because this trust scenario is already implicitly covered by the existing trust scenarios, do we introduce any additional threat vectors in the generalization?