Add governance hooks for identity assertion

[scouten-adobe]

No description provided.

[chalford]

Looks like this is still early in development - will likely need more review as it develops.

While it's not explicitly called out here, I think we should avoid binding actor identity governance & trust with wider metadata governance. The two should interact, but I'd be keen not to make actor identity proofing to require any use of metadata governance controls.

As we go forward, there's a couple of requirements I'd like us to consider:

1. Addressing actor identity for general consumers as a single problem, and not require that consumers understand the intricacies and meanings of the various trust lists at that level
2. Potentially bringing logotype ownership governance into scope for a generic actor identity solution
3. Finding a way to express the "value add" of individual governance programmes that can layer on top of base identity (e.g. the IPTC's Verified News Publisher check of whether an organisation is a news one)

[chalford]

There's a few terms in here that I think need expanding on, as I'm assuming this will be referenced by the normative spec.

[chalford]

Is this intended to be backed by a protocol? If so, I think it'll need a section on it's own to explain how it maps into CAWG, and what conclusions and meanings those protocols bring to actors, and potentially, other CAWG assertions in the case of governance.

[dcondrey]

Suggested change

	? "trust_registry_uri": https-uri, ; TO DO: define
	? "trust_registry": trust-registry-map, ; TRQP authorization payload

Aligns the CDDL with overview.adoc (§5.1) and the cbor-schema example, which both treat trust_registry as a structure, not a uri. The map still needs a definition. Sketching it here for discussion rather than committing it, since the TRQP fields are still marked TO-DO:

trust-registry-map = {
  "trqp_authorization_uri": https-uri,
  "entity_id": tstr,
  "authority_id": tstr,
  "action": tstr,
  "resource": tstr,
}

[dcondrey]

trust_registry and referenced_registry_uri sit outside signer_payload so they're covered by claim generator's seal but not credential holder's signature. The named actor doesn't sign their own governance or registry claim; the tool does. Is that intentional? If so, what binds these fields and the trust implication?

Consider moving trust_registry into signer-payload-map.

[dcondrey]

Suggested change

This specification describes a specific _<<C2PA assertion>>_ that can be added to a _<<C2PA Manifest>>_ to allow an _<<_actor,actor>>_ backed by a governing authority that manages its own trust registry to prove control over a digital identity and to bind that identity to a _<<_c2pa_asset,C2PA asset>>_ (and, at their option, one or more _<<_c2pa_assertion,C2PA assertions>>_) produced by them or on their behalf.

This specification describes a specific _<<C2PA assertion>>_ that can be added to a _<<C2PA Manifest>>_ to allow an _<<_actor,actor>>_ optionally backed by a governing authority that manages its own trust registry to prove control over a digital identity and to bind that identity to a _<<_c2pa_asset,C2PA asset>>_ (and, at their option, one or more _<<_c2pa_assertion,C2PA assertions>>_) produced by them or on their behalf.

trust_registry is optional but this scopes the spec to an actor backed by a governing authority that manages its own trust registry. That reads as presuming governance for every actor and excluding the ungoverned base (1.2) case. Suggest framing governance as an optional layer.

[dcondrey]

This sentence is hard to parse and conflates two functions. 'allows for a link to additional assertions can be made' is grammatically broken, and the two distinct uses, linking external assertions versus verifying metadata, are run together. Suggest splitting into two sentences, one per function.

[dcondrey]

Reinforcing @chalford's point about keeping actor-identity governance separate from wider metadata governance. The use-case doc for this PR currently has all three cases conveying entitlement through the identity assertion (insurance policy, consent, royalty), which runs into §1.3's caveat that the assertion SHOULD NOT convey attribution or ownership. Suggest the governance hooks stay scoped to signer-binding plus issuer authorization, with rights, consent, and metadata living in referenced assertions.

[chalford]

An actors use of a credential issued by an issuer on a trust registry might demonstrate affiliation with the governance framework of those issuers, or it might not. If we assume something like the Mozilla Root Program will be allowed in this framework, there's a much weaker link between the actor and the Root Program governance.

[chalford]

Suggested change

This specification describes a specific _<<C2PA assertion>>_ that can be added to a _<<C2PA Manifest>>_ to allow an _<<_actor,actor>>_ backed by a governing authority that manages its own trust registry to prove control over a digital identity and to bind that identity to a _<<_c2pa_asset,C2PA asset>>_ (and, at their option, one or more _<<_c2pa_assertion,C2PA assertions>>_) produced by them or on their behalf.

This specification describes a specific _<<C2PA assertion>>_ that can be added to a _<<C2PA Manifest>>_ to allow an _<<_actor,actor>>_ to prove control over a digital identity and to bind that identity to a _<<_c2pa_asset,C2PA asset>>_ (and, at their option, one or more _<<_c2pa_assertion,C2PA assertions>>_) produced by them or on their behalf. These actors can be backed by an authority governs the actor or how the actor's credential is issued.

[byh-trufo]

One actor may be be backed by multiple governing authorities, and may have multiple digital identities they could use (each one backed by a different governing authority); perhaps we should be add some language on how the digital identity itself is recognized by a the governing authority.