WIP: Adding Identity Hooks for Enhanced Privacy and Consistency

[andrewDworschak]

• I have read the CLA Document and I hereby sign the CLA.

---

WORK IN PROGRESS

---

I brought up the concept of “identity hooks” in a previous meeting and wanted to flesh out some of the details for why I think this is an essential feature for an identity credential and how I propose it be implemented into CAWG.

In my view, this change could be implemented in the CAWG standard with relatively minimal overhead, though it does change some of infrastructure identity aggregators and claim generators would be expected to maintain.

With that said, the potential benefits to privacy, consistency, extensibility, and user empowerment that identity hooks can provide make it a worthwhile feature to consider.

What is an Identity Hook?

An identity hook is a “created assertion” (i.e. an assertion that does not require human input and that a claim generator can attest to directly) that acts as a pathway for creators to add and append identity information to a credential, either immediately or in the future.

It binds an opaque, one-off key pair to a C2PA credential whose only purpose is to act as a hook for verified identities. The private key should be kept in strict confidence for the creator, and can be custodied by the claim generator, the identity claims aggregator, or the (expert) user themselves.

Because the key pair itself contains no identifiable or human-inputted information, the claims generator can create this hook themselves - even if the creator currently has no intent of binding identity info to it. (Assuming of course that a good claims generator doesn’t intend on disseminating the private key or binding false identities to the content)

Why is this so important?

There are a bunch of reasons:

1. I have many identities. I have a tax payer ID, a Twitter profile, a pseudonymous Reddit account, a crypto wallet, a work email, and more. The current spec allows this, but with some big caveats we can fix (see the rest of this list).
2. In many cases, I don’t want my identities associated with each other. If my identity claims aggregator signs one piece of content with one identity, and another with another, then the common ID the identity claims aggregator stamps as my username is a dead giveaway that all my identities are associated with each other. My privacy is gone. With an identity hook, those identities only get tied to the one-off key pair, keeping more of my info private.
3. Once the credential is published, if my identity isn’t on it, there’s no going back. Sure, I could wrap a new manifest around the old one, but that’s far less secure or convincing than if I was on the initial credential. I don’t want to lose out on that benefit just because I don’t have an identity claims aggregator accessible & pre-configured at the time I created my content. With an identity hook, the claims generator preserves my right to identify myself into the future without forcing the identity claim upfront.
4. When I’m in the process of creating content, I often have no idea if or how I want to publish it. I don’t want to preemptively bind an identity to the content when the credential is first being created. A hook gives me optionality into the future for which identity I want to put on the content, if I want one at all.
5. Privacy is one the biggest reasons that identity is not currently part of the core C2PA standard - but identity hooks change that. Sometimes, it might be necessary to prove my content binding to somebody, even if I don’t want to publish that in a credential. With a hook, I can always do this by signing a private message, and because the key pairs are one-offs, that person doesn’t learn anything about my identity beyond my affiliation with that single piece of content.
6. Especially in rights & attribution use cases, knowing who didn’t create a piece of content is just as important as knowing who did. If the initial credential doesn’t come with an identity assertion, there’s no credential down the line that can reestablish the identity binding. So the absence of an authentication pathway limits my ability to say when others are taking advantage of my content without attribution. An identity hook solves this, because it means that an unauthorized user is choosing not to prove their creatorship, not that they can’t prove their creatorship - i.e. it has the potential to shift the burden of proof.
7. Public identity is not a prerequisite for the distribution of rights, but consistency of identity is. Identity hooks give me a privacy-preserving pathway to issue downstream licenses to my content without needing to disclose my personal information. Even though this doesn't fall within the scope of CAWG today, it's a very helpful piece of functionality for others to be able to bind to later on.

The technical details

I haven’t put these in normative form or hammered out the finer points, but I’ve tried to include enough detail below to make the idea clear:

• An identity hook is a did:key created uniquely for that assertion via public-private key encryption. It’s an optional field that lives in the identity assertion alongside the cawg.role.
• The id field of the credentialSubject must, if present, either:
  • Match the identity hook of the current assertion. This would be useful for verified identities to be established in the same assertion as the identity hook, and provide a stronger signal that the creator consented to having their identity shared.
  • Match the identity hook of another referenced cawg.identity assertion from a previous manifest. This would be useful for appending identities to previously created assertions.
• This procedure is most useful for assertions made by the “creator”—i.e. the person who is operating the software/hardware used to create the content, because the device can reliably place the keys in the custody of that person. There might be cases where we want to make an identity assertion about someone who is not the “creator”, like the director of a film or the subject of a photo. In these cases, the binding of identity is naturally weaker because the subject is already one layer removed from the claim generator. So these claims should continue to be allowed, but have the id field omitted in the credentialSubject.
  • It’s unclear whether CAWG should voice which cawg.roles are permitted to include identity hooks, or whether it’s fair to allow software implementers to decide this.
• The id field of the credentialSubject is currently not described in the CAWG docs (aside from in one non-normative example), so this change would simply restrict the use of this field.
• For clarity, the concept of appending identities to a previous manifest DOES NOT imply that we modify a manifest - this never happens in C2PA. Instead, we would wrap the manifest in a new manifest that references the previous manifest’s identity hook, and by signing with the identity hook’s private key, we’d accept that the newly-reported identities are associated with the previous creator and tied to the original credential.
• The verifiable credential is signed both by identity hook’s private key (if included) and countersigned by the issuer (i.e. the identity claims aggregator).
• In some cases, multiple identity hooks will be issued at different stages of the editing process (e.g. photo capture and subsequent editing). We can express this consistency by listing an identity hook as a verified identity of another identity hook. In most cases, we’d want the earliest-timestamped hook to serve as the primary identifier, so we’d want the later hook to be expressed as a verified identity for the earlier hook.

FAQ

There are some nuances and intended limitations to identity hooks, and I’ve tried to describe them here.

Q: Does this add a bunch of unnecessary complexity to the workflow? Creators don’t want to learn public-private key encryption.
A: This doesn’t need to introduce any additional complexity into the process - the identity claims aggregator could custody all the information. But it leaves the door open to much richer workflows as well, such as where credentials are passed around between identity claims aggregators, where the ability to append identities is destroyed by deleting a private key, by allowing aggregators to perform private handshakes to establish identity without a credential, etc.

Q: Is an identity hook a created or gathered assertion, and where should it find its home in the C2PA stack?
A: The reservations I’ve heard so far for including identity assertions in the core C2PA standard, as a part of every credential, stem from either the concern that forcing the inclusion of identity credentials could create a privacy concern, or that identity credentials are “gathered assertions” that require human input.
Neither of these statements hold true for identity hooks, as any software system can unilaterally create key pairs (which even in the worst case where everyone ignores the identity hooks, could just pile up on the device to be used later), making it a “created assertion”. The opacity and uniqueness of the key pair results in no identifiable information whatsoever in an identity hook. Since identity cannot be recovered if it is not placed in the initial credential, identity hooks provide many potential benefits with no significant risks, and I believe that identity hooks could be moved into the core C2PA standard and become a part of every credential.
This level of adoption may require the hook to be separated from the gathered assertion that binds verified identities, but to accomplish that, one could just move the hook and role to another assertion type and have it referenced by the identity verification assertion.

Q: If I don’t want my many identities associated with one another, but still want to use the same piece of content between many of those identities, how can I prevent someone from knowing that identities 1 & 2 are associated with each other when I bind them to the same identity hook?
A: A few options:

• I can secretly prove my control over the identity hook to a whichever platform is requiring the authentication, without publishing a credential, because I control the key pair behind that content. Because this communication is private, nobody will be able to make the association.
• This might not be an identity problem at all: I can maintain a level of plausible deniability by issuing whichever rights are needed as licenses to the content, so that my two related identities look like common licensees as opposed to a consistent identity, accomplishing whichever goal I had. This falls outside of scope of CAWG as a rights & attribution problem, so it’s okay not to address this directly.

Q: Identity hooks allow someone to effectively append identity information to an existing credential - how large an attack service does that create?
A: We can break this into a few cases:

• Any identity info, or perhaps none, that I want to assert is done upfront (the existing model). The presence of identity hooks doesn’t change this ability. You can always delete the private key.
• I want to add identity info once, and never again. As soon as I know that I no longer want the append identity info in the future, I can delete the private key.
• I want to leave the door open to appending more identity info, but only of certain types (e.g. social media profiles). This isn’t possible under the current scheme, but it also doesn’t sound much like an identity use case anymore. We’re getting into the territory where I must not fully trust the custodian of my private key, so this is more likely an issue that should be addressed by multi-sig credentials, licensing, or some other mechanism.

Q: Is there ever an indication on the credential when a hook is no longer active?
A: We never explicitly label on the credential when we’re closing the door to additional identities. It might be reasonable to add a field like this, but it’s more of a confirmation to the credential reader than it is useful to the credential holder, and I’m skeptical whether this piece of information could be useful or reliable (since you can’t force people not to delete their private keys without telling you).

[andrewDworschak]

This is a fairly significant update that fleshes out most of the details for how identity hooks can be implemented into the CAWG standard.

There are 3 sections:

1. Refinements: Following a sub-group meeting we had on this issue as well as more analysis of the approach, I’ve added & changed some of the details for how identity hooks work to be more flexible and secure.
2. Schemas: This shows the actual implementation of identity hooks and the changes it makes from the existing claims aggregation model. This is just one possible implementation, and will take some work to get it into its final form, but it should be sufficient to understand the vision.
3. Validation: This describes changes to the validation process at a high level. It focuses on the parts of the validation process that weren’t clear just from the schemas.

Refinements

Question 1: In what contexts are identity hooks useful? Can they be useful after the publication & distribution of content, or only during the creation process?

We uncovered several related value propositions and different viewpoints for evolving identity that were not captured in the original post on identity hooks.

Identity hooks are meant to address the ability for a piece of content to pull in additional identity information relating to a named actor after an initial manifest was created, without losing the benefits of the trust associated with that. There’s a separate need for named actors to be able to push new information about their identity to content after that content is no longer in their control—e.g. to retroactively broadcast someone’s identity to social content after it goes viral, perhaps because their identity has changed or they now decide they want credit for their work.

Both of these problems, as well as the related problems brought up in the original identity hooks post, are very important for an identity standard to address. Identity hooks are the solution to that first problem (by design), and they also lay the foundation of a solution for the 2nd problem.

Here are some specific ways identity hooks play into that second problem:

1. Any time there’s a strong incentive for someone to seek clarification on the identity of a named actor, it’s likely that both the named actor and the verifier will have a vested interest in clarifying that identity. That opens up a world of incentives for contact to be made between the parties. At that point, those parties could privately confirm the control of the identity hook or publicly affix a new identity to the content using an update manifest.
2. Absent the interested parties being in contact, identity hooks can be used as a unique queryable ID on identity aggregation platforms. Either the named actor can stamp an identity aggregator onto the manifest who will make that ID accessible (so that others know where to look for updates), or a set of publicly accepted services for identity lookups can emerge with a central channel for look-ups. The implementation and privacy details of these methods are beyond the scope of this issue, but the important consideration is that the did of the identity hook opens the door to this type of reference system.

As a last note, it’s worth re-stating that identity hooks can be useful for anything ****that binds to a named actor. In rights & attribution scenarios, this includes licensing terms that can be demonstrably permissioned by a named actor in a privacy-preserving way via their identity hook. These licenses themselves are outside the scope of CAWG, but their binding to identity should not be.

Question 2: Why do identity hooks need to be a did:key? Isn’t that overly restrictive, and are there other did methods that would be better?

did:key is the simplest possible method to make identity hooks work, but they're far from the only method. Other did methods were brought up as promising alternatives that have many improved features like key rotation, multi-sig, and more.

My belief is that any did method with signing capability should be sufficient for an identity hook, and that it’s not the job of CAWG to dictate the acceptable methods except for verifier compatibility. Instead, CAWG should offer optionality on did methods with a standard that allows the user/identity claims aggregator as much control over the functionality they gain as possible.

This is where the problem comes in: in many cases, the claims generator will be in charge of generating the did for the identity hook, since a user-preferred identity claims aggregator may not yet be configured.

As a result, we could select and enforce a did method among claims generators that covers most of the functionality that people want (or could want in the future)—but that’s an unsustainable approach.

Instead, we should prescribe a method that allows the user to rotate their did (by expressing an older did as an identity of a newer did)—not only is this much easier, but the user can update their did to the latest supported method on their older credentials.

In summary, identity hooks should allow methods beyond just did:key, and introduce a method for did rotation.

Question 3: By default, there’s a custody change of the did from the claims generator to the user/identity claims aggregator. Isn't that a big security risk?

Yes, it could be a risk if the claims generator isn't well trusted. There are 2 ways to mitigate this:

1. Allow users/identity claims aggregators to pass their own generated did into the claims generator, so that the claims generator never has access to the did's signing authority. This is the most secure method, but depends on identity aggregation being preconfigured at the time of content creation, which is not always possible.
2. Perform a did rotation in concert with the identity assertion, so that the expression of identity is only associated with the most recent did. This doesn't stop a corrupt claims generator from peeling back the most recent identity manifest and replacing it with a new one binding a compromised identity key, but at least the newly asserted identity is not harmed. In the next question, I also address how this risk can be minimized.

We should support both of these methods in identity hooks.

Question 4: With all these identity hooks floating around on the different manifests, don't we risk falling back to the least secure key?

Not necessarily. Even though identity hooks allow identity to be appended to into the future, all identity statements on a given piece of content from a consistent creator should be rolled up to a single master did, by wrapping other dids as verified identities. The principle at work here is that it's much easier to demonstrate control over an identity than to demonstrate the absence of control over that identity—you usually can’t prove that someone deleted a private key.

Here are a scenario to make this more concrete:
Say a single creator takes a consistent role across 2 manifests—first when they snap a photo on their phone, and then when they make an edit in Photoshop. Each of these manifests will come with its own unique identity hook. The creator can bind their series of actions together by expressing the 2nd identity hook as a verified identity of the earlier identity hook. Or, alternatively, they can express both of these dids as identities of a new did they control via did rotation. We now have evidence that the creator was in control of all of these dids owing to their consistent role. However, the claims generator may also maintain control of some of these private keys in its memory. If that claims generator goes corrupt or exposes the keys, someone could wrap on a new manifest to make it look like that creator expressed a new identity to the work.

The easy-to-implement solution is simply to ignore identities tied to a previously (in the manifest stack) rotated or rolled-up did. That way, the compromised keys can still replace the manifest where the creator articulated their identity, but they can’t append to that manifest. In cases where the creator’s identity assertion gets buried in subsequent manifests, the attacker would then need to roll all of those manifests back as they replace the manifest. As a result, this approach solves most of the issues, and this is where we stop with this issue.

In the longer term, to more fully eliminate the risk of identities being added on compromised dids after the fact, we need a trusted registry that can validate the status of a did and control for any unauthorized identities, which would need to either be articulated in the original credential or be discoverable after the fact (e.g. via search engine or commonly accepted places to record such did statuses). This is beyond the current scope of identity hooks, but a promising future expansion.

Question 5: Should someone be able to create an assertion without an identity hook?

This was something I described in the original post, but I’m becoming more inclined to believe that every identity assertion should be bound to an identity hook. I previously included an option not to include the identity hook in an identity assertion for backward-compatibility (which may be a good enough reason in itself).

The obvious use cases for hook-less identity assertions are in making statements like “Alice was the subject of this photo and consented to her involvement”, or “Bob was the singer of this song”. However, none of these types of scenarios are covered by the existing set of CAWG roles: creator, contributor, editor, producer, publisher, sponsor, translator, so I think it’s safe to exclude them from the spec for now.

My big concern is that identity assertions, especially when bound to an identity hook, provide a substantial reason to trust the assertion because the hardware/software where the credential is generated have a direct line of communication with certain named actors. These other types of statements are far less secure because we need to rely on the user to relay the communication.

I propose that these other types of statements be addressed more directly via a separate type of assertion down the line (e.g. in a new Subject Consent Assertion), so that we can bring as much trust as possible to identity assertions today.

Schemas

Here’s a breakdown of the different schemas that identity hooks would introduce and modify, to give an idea of the implementation of the functions. For each schema, you’ll find an introduction and some notes explaining why it’s organized the way it is.

New IdentityHook schema

Purpose:

This schema allows claim generators to produce identity hooks, which can be used to both immediately and retroactively make statements on behalf of a named actor.

Most commonly, these statements will involve identity statements via an identity claims aggregator, and the binding together of many identity hooks from different manifests to show the consistent involvement of a single named actor in many steps of the creative process.

Required signatures:

• None, the hardware/software of the claims generator can attest to an identity hook directly—there’s no additional source of trust needed.

{
  "@context": [
    "https://cawg.io/identity/1.1/ica/context/"
  ],
  "type": [
    "IdentityHook"
  ],
  <-- "role" now lives in the identity hook, because that's something the claims generator can attest to directly -->
  "role": "cawg.creator",
  <-- "identityHook" MUST be a newly generated, opaque DID with signing capacity (not necessarily did:key), though claims generators SHOULD allow a user or configured identity claims aggregator to pass in that DID themselves (for better security) -->
  <-- The claims generator is responsible for placing the identity hook in the custody of the named actor (or their identity claims aggregator), either immediately or after a identity claims aggregator gets configured. -->
  "identityHook": "did:key:z2dmzD81cgPx8Vki7JbuuMmFYrWPgYoytykUZ3eyqht1j9",
  "c2paAsset": {
    "referenced_assertions": [
      {
        "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.hash.data",
        "hash": "U9Gyz05tmpftkoEYP6XYNsMnUbnS/KcktAg2vv7n1n8="
      },
    ],
    "sig_type": "cawg.identity_hook"
  },
  "credentialSchema": [
    {
      "id": "https://cawg.io/identity/1.1/ica/schema/identity_hook",
      "type": "JSONSchema"
    }
  ]
}

Note: The rest is pretty much just Identity Claims Aggregation as we know it, with a few little additions & tweaks.

The following 3 schemas are broken up for clarity, but can (and often should be) be used in conjunction with one another to simultaneously perform hook rollups, hook rotation, and identity claims aggregation.

Modification to the IdentityClaimsAggregationCredential schema

Purpose: This schema allows trusted identity claims aggregators to make statements about the identity of named actors, identified by their identity hooks.

Required signatures:

• Identity claims aggregator (issuer)
• Identity hook (credentialSubject.id)

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://cawg.io/identity/1.1/ica/context/"
  ],
  "type": [
    "VerifiableCredential",
    "IdentityClaimsAggregationCredential"
  ],
  "issuer": "did:web:connected-identities.identity.adobe.com",
  "validFrom": "2024-05-27T11:40:40Z",
  "credentialSubject": {
	  <-- "id" MUST match an identity hook from a referenced IdentityHook assertion -->
    "id": "did:key:z2dmzD81cgPx8Vki7JbuuMmFYrWPgYoytykUZ3eyqht1j9",
    "verifiedIdentities": [
      {
        "name": "First-Name Last-Name",
        "type": "cawg.document_verification",
        "provider": {
          "id": "https://example-id-verifier.com",
          "name": "Example ID Verifier",
        },
        "verifiedAt": "2024-07-26T22:30:15Z"
      },
      {
        "type": "cawg.affiliation",
        "provider": {
          "id": "https://example-affiliated-organization.com",
          "name": "Example Affiliated Organization",
        },
        "verifiedAt": "2024-07-26T22:29:57Z"
      },
      {
        "type": "cawg.social_media",
        "name": "Silly Cats 929",
        "username": "username",
        "uri": "https://example-social-network.com/username",
        "provider": {
          "id": "https://example-social-network.com",
          "name": "Example Social Network"
        },
        "verifiedAt": "2024-05-27T08:40:39.569856Z"
      },
      {
        "type": "cawg.crypto_wallet",
        "username": "username",
        "uri": "https://example-crypto-wallet.com/username",
        "provider": {
          "id": "https://example-crypto-wallet.com",
          "name": "Example Crypto Wallet"
        },
        "verifiedAt": "2024-05-27T08:40:39.569856Z"
      }
    ],
    "c2paAsset": {
      "referenced_assertions": [
        {
          "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.hash.data",
          "hash": "U9Gyz05tmpftkoEYP6XYNsMnUbnS/KcktAg2vv7n1n8="
        },
        <-- MUST include the referenced identity hook assertion, which could come from the same manifest or a previous manifest.  -->
        <-- Note: URIs referenced from a previous manifest are prefixed with a "/" per C2PA 8.4.2.1 Hashed URIs/Embedded.  -->
        {
          "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/cawg.assertions/c2pa.identity_hook",
          "hash": "G5hfJwYeWTlflxOhmfCO9xDAK52aKQ+YbKNhRZeq92c="
        }
      ],
      "sig_type": "cawg.identity_claims_aggregation"
      <-- Removes "role" from the identity claims aggregation assertion. Identity aggregators should not be expected to attest to the role the named actor played in the content -->
    },
  },
  "credentialSchema": [
    {
      "id": "https://cawg.io/identity/1.1/ica/schema/",
      "type": "JSONSchema"
    }
  ]
}

New IdentityHookRollupCredential schema

Purpose: This schema allows named actors to express their consistent involvement with an asset’s many identity hooks, by expressing one identity hook as a verified identity of another hook.

Required signatures:

• Parent identity hook (credentialSubject.id)
• Child identity hook(s) (credentialSubject.verifiedIdentities)

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://cawg.io/identity/1.1/ica/context/"
  ],
  "type": [
    "VerifiableCredential",
    "IdentityHookRollupCredential"
  ],
  <-- MAY be self-issued by the parent identity hook -->
  "issuer": "did:key:z2dmzD81cgPx8Vki7JbuuMmFYrWPgYoytykUZ3eyqht1j9",
  "validFrom": "2024-05-27T11:40:40Z",
  "credentialSubject": {
	  <-- This is the parent identity hook being rolled up to. "id" MUST match an identity hook from a referenced IdentityHook assertion -->
    "id": "did:key:z2dmzD81cgPx8Vki7JbuuMmFYrWPgYoytykUZ3eyqht1j9",
    "verifiedIdentities": [
      <-- MUST include at least one child identity hook -->
      {
        "id": "did:key:2ui7Pp3bSfXjirjfvycNs9GDFyJxW4EPuA8Cvgg7Uhqf4i",
        "type": "cawg.identity_hook"
      },
      {
        "id": "did:key:LWZAsr3Bsn9KjYa2sxWPVYS8UNGwvAVvhBXkVtVB3rz7Pr",
        "type": "cawg.identity_hook"
      }
    ],
    "c2paAsset": {
      "referenced_assertions": [
        {
          "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.hash.data",
          "hash": "U9Gyz05tmpftkoEYP6XYNsMnUbnS/KcktAg2vv7n1n8="
        },
        <-- MUST include all parent and child identity hook assertions.  -->
        {
          "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/cawg.assertions/c2pa.identity_hook",
          "hash": "G5hfJwYeWTlflxOhmfCO9xDAK52aKQ+YbKNhRZeq92c="
        },
        {
          "url": "self#jumbf=c2pa/urn:uuid:E9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/cawg.assertions/c2pa.identity_hook",
          "hash": "H5hfJwYeWTlflxOhmfCO9xDAK52aKQ+YbKNhRZeq92c="
        },
        {
          "url": "self#jumbf=c2pa/urn:uuid:D9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/cawg.assertions/c2pa.identity_hook",
          "hash": "I5hfJwYeWTlflxOhmfCO9xDAK52aKQ+YbKNhRZeq92c="
        }
      ],
      "sig_type": "cawg.identity_hook"
    },
  },
  "credentialSchema": [
    {
      "id": "https://cawg.io/identity/1.1/ica/schema/",
      "type": "JSONSchema"
    }
  ]
}

New IdentityHookRotationCredential schema

Purpose: This schema allows named actors to rotate the did of an identity hook, either to obtain a new did with the functionality they require for their identity use case, or to increase the security of their identity credential following a change of custody.

Required signatures:

• New identity hook (credentialSubject.id)
• Previous child identity hook(s) (credentialSubject.verifiedIdentities)

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://cawg.io/identity/1.1/ica/context/"
  ],
  "type": [
    "VerifiableCredential",
    "IdentityHookRotationCredential"
  ],
  <-- MAY be self-issued by the new overriding identity hook -->
  "issuer": "did:key:2ui7Pp3bSfXjirjfvycNs9GDFyJxW4EPuA8Cvgg7Uhqf4i",
  "validFrom": "2024-05-27T11:40:40Z",
  "credentialSubject": {
	  <-- This is the DID being rotated in to override the previous identity hooks -->
    "id": "did:key:2ui7Pp3bSfXjirjfvycNs9GDFyJxW4EPuA8Cvgg7Uhqf4i",
    "verifiedIdentities": [
      <-- MUST include at least one child identity hook -->
      {
        "id": "did:key:z2dmzD81cgPx8Vki7JbuuMmFYrWPgYoytykUZ3eyqht1j9",
        "type": "cawg.identity_hook"
      }
    ],
    "c2paAsset": {
      "referenced_assertions": [
        {
          "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.hash.data",
          "hash": "U9Gyz05tmpftkoEYP6XYNsMnUbnS/KcktAg2vv7n1n8="
        },
        <-- MUST include all identity hook assertions.  -->
        {
          "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/cawg.assertions/c2pa.identity_hook",
          "hash": "G5hfJwYeWTlflxOhmfCO9xDAK52aKQ+YbKNhRZeq92c="
        }
      ],
      "sig_type": "cawg.identity_hook"
    },
  },
  "credentialSchema": [
    {
      "id": "https://cawg.io/identity/1.1/ica/schema/",
      "type": "JSONSchema"
    }
  ]
}

Example of IdentityClaimsAggregationCredentialand IdentityHookRollupCredential being used at once

The same is possible for a IdentityClaimsAggregationCredential and IdentityClaimsRotationCredential, but the parent DID wouldn’t be expected to match an identity hook.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://cawg.io/identity/1.1/ica/context/"
  ],
  "type": [
    "VerifiableCredential",
    "IdentityClaimsAggregationCredential",
    "IdentityHookRollupCredential"
  ],
  <-- In this case, the issuer is key to the trust of the non-hook verified identities -->
  "issuer": "did:web:connected-identities.identity.adobe.com",
  "validFrom": "2024-05-27T11:40:40Z",
  "credentialSubject": {
	  <-- "id" MUST match an identity hook from a referenced IdentityHook assertion -->
    "id": "did:key:z2dmzD81cgPx8Vki7JbuuMmFYrWPgYoytykUZ3eyqht1j9",
    "verifiedIdentities": [
      {
        "id": "did:key:2ui7Pp3bSfXjirjfvycNs9GDFyJxW4EPuA8Cvgg7Uhqf4i",
        "type": "cawg.identity_hook"
      }
      {
        "name": "First-Name Last-Name",
        "type": "cawg.document_verification",
        "provider": {
          "id": "https://example-id-verifier.com",
          "name": "Example ID Verifier",
        },
        "verifiedAt": "2024-07-26T22:30:15Z"
      }
    ],
    "c2paAsset": {
      "referenced_assertions": [
        {
          "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.hash.data",
          "hash": "U9Gyz05tmpftkoEYP6XYNsMnUbnS/KcktAg2vv7n1n8="
        },
        <-- MUST include all referenced identity hook assertions, which could come from the same manifest or a previous manifest.  -->
        {
          "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/cawg.assertions/c2pa.identity_hook",
          "hash": "G5hfJwYeWTlflxOhmfCO9xDAK52aKQ+YbKNhRZeq92c="
        },
        {
          "url": "self#jumbf=c2pa/urn:uuid:E9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/cawg.assertions/c2pa.identity_hook",
          "hash": "H5hfJwYeWTlflxOhmfCO9xDAK52aKQ+YbKNhRZeq92c="
        }
      ],
      "sig_type": "cawg.identity_claims_aggregation"
    },
  },
  "credentialSchema": [
    {
      "id": "https://cawg.io/identity/1.1/ica/schema/",
      "type": "JSONSchema"
    }
  ]
}

Validation steps

The following are rough validation steps:

Identity hooks:

1. Identity hooks themselves should be globally unique DIDs—this is not verifiable, but the only harm would be a loss of privacy for the named actor based on the relation to other identity hooks.
2. Aside from the hard binding to the C2PA asset, identity hooks do not need validation.

Identity claims aggregation credentials:

1. The additional signature of the identity hook specified in the id is verified.
2. The reference to a valid identity hook assertion is verified.
3. If another identity assertion with an earlier validFrom date includes the referenced identity hook as a child hook (i.e. a rollup or rotation), validation fails. This prevents compromised or previously rotated DIDs from making invalid assertions.
4. Otherwise, identity claims aggregation verification proceeds as normal.
5. If successful, the identity of the named actor can be associated with the timestamp and actions of the original identity hook manifest.

Identity hook rollup credentials:

1. The signature of each parent and child identity hook is verified.
2. The reference to a valid identity hook assertion for each parent and child hook is verified.
3. If another identity assertion with an earlier validFrom date includes any referenced identity hook as a child hook (i.e. a rollup or rotation), validation fails.
4. The rest of the usual verifiable credential verification steps proceed.
5. If successful, the verifier may associate any verified identities of the hooks with one another, and any subsequent binding to the identity hook must be done to the parent.

Identity hook rotation credentials:

1. The signature of the new parent DID and each child identity hook is verified.
2. The reference to a valid identity hook assertion for each child hook is verified.
3. If another identity assertion with an earlier validFrom date includes any referenced identity hook as a child hook (i.e. a rollup or rotation), validation fails.
4. The rest of the usual verifiable credential verification steps proceed.
5. If successful, the verifier may associate any verified identities of the child hooks with one another, and any subsequent binding to the identity hook must be done to new parent DID.

[puhley]

"but the only harm would be a loss of privacy for the named actor based on the relation to other identity hooks." - The privacy of a named actor could be extremely important to the individual (as in terms of potential physical harm). Privacy of individuals is also governed by laws and have legal ramifications.

[andrewDworschak]

"but the only harm would be a loss of privacy for the named actor based on the relation to other identity hooks." - The privacy of a named actor could be extremely important to the individual (as in terms of potential physical harm). Privacy of individuals is also governed by laws and have legal ramifications.

Agreed, and I don't mean to trivialize the potential harm in that statement! My point here was more that there are real security benefits to be had by allowing people to pass in their own DIDs as identity hooks, because there would then be no change of custody in the private key.

But while we can write a standard that says a claims generator MUST generate a unique, opaque, one-off keypair for any identity hooks where they provide the DID, a claims generator can't be responsible for guaranteeing the uniqueness of any old DID they had no role in setting up, because whoever passed it in could just be lazy and lie.

There are ways we could get the best of both worlds - e.g. by saying that the claim generator MUST play a sufficient role in the generation of the DID to guarantee its uniqueness and opacity, still allowing identity aggregators to have the sole knowledge of the private key. You could even go a step further by forcing a unique piece of data from the content like its hard binding to be part of the key encryption process, which would allow anyone to verify that the keypair was sufficiently unique. But each of these approaches come at the cost of limiting the set of DID methods that can be used as hooks.

In any case, and the point I think we'll come back to again and again, the key is to be very deliberate and explicit about what responsibility the claims generator and other actors have in each statement they make and what consumers can infer based on those statements, in a way that isn't currently reflected in the CAWG standard.

[nigelcearnshaw]

Hi,

There is a lot of work here so apologies if I have missed this point.

I have a question about the timeliness of the inclusion of the identity hook and any subsequent verified identity apparently associated with it.

How can I know that these were bound together at the time of inclusion, i.e., at the time of the generation of the original manifest? For example, is it possible to include an identity hook and then subsequently sell or pass-on that private key to the highest bidder and therefore allow them to subsequently claim ownership? Is this a problem?

What guarantees are in place here about identity. I can see that there is a private key associated with this manifest but without a contemporaneously verified owner. In the simple case that means the creator can subseqently reveal that they now have that private key. But what guarrantee does that provide if private keys are exportable? What does it say about the integrity of the overall system? Can it be misused?

[andrewDworschak]

Hi,

There is a lot of work here so apologies if I have missed this point.

I have a question about the timeliness of the inclusion of the identity hook and any subsequent verified identity apparently associated with it.

How can I know that these were bound together at the time of inclusion, i.e., at the time of the generation of the original manifest? For example, is it possible to include an identity hook and then subsequently sell or pass-on that private key to the highest bidder and therefore allow them to subsequently claim ownership? Is this a problem?

What guarantees are in place here about identity. I can see that there is a private key associated with this manifest but without a contemporaneously verified owner. In the simple case that means the creator can subseqently reveal that they now have that private key. But what guarrantee does that provide if private keys are exportable? What does it say about the integrity of the overall system? Can it be misused?

Just seeing this Q now - these are the right questions to be asking!

I'll start by saying that the standard is currently silent on how to interpret the presence of an identity assertion, which allows for some confusing situations. Since creation can take place in multiple steps, and I can use update manifests to add information to credentials even when there are no changes to the digital content, it becomes very unclear what exactly a creator is taking responsibility for when the publish an assertion. Identity hooks would be a big step to make those statements more interpretable.

More directly to your questions, one goal of identity hooks is to relax the requirement that identity be asserted at the original generation time. This is important, because there are many reasons why the user might not bind a hook with their identity at creation time: maybe they don't know which of their (potentially pseudonymous) identities they wanted to assert yet, maybe they haven't configured an identity aggregator yet, maybe their identity evolves over time as they gain new accounts, retire old ones, change their name etc. but they still want to prove their role in the original creation of an asset.

There are lots of other reasons identity hooks can be helpful, but this is definitely one of their key powers.

But you raise good questions on how we measure the attack surface this creates by e.g. selling private keys to the highest bidder. I'd say it's very context dependent, but here are a handful of thoughts:

1. There isn't technically anything new being done here. I can always write in my own private key to an identity assertion and later add another identity assertion with that same private key plus a bunch of other stuff. The downside is that by not codifying this, it's more likely that we'll end up with less-secure, non-interoperable ways that people achieve that same goal. After all, identity does evolve, and creators don't always know what they want to assert up front, so it's very likely that they'll try to make these types of retroactive statements regardless of whether the spec is opinionated on it.
2. Even in the current standard, there's nothing to stop a creator from selling the identity bindings on their work to the highest bidder - they'd just need to do it at the time of publication. e.g. I can get you to sign and send over an identity assertion and add it to a credential for you, right as I publish that content. I also wonder how problematic this scenario really is - it feels a lot like the creator is just selling the ownership rights to their content. There are little nuances to work through around security, custody, and concealing information, but I think it's all quite solvable.
3. This mechanism isn't all that different than a passkey, which the world of password managers is already very well set up for. So there's certainly the user-education piece of explaining what an identity manager does and how they can apply the power of these tools to the content they create, but it doesn't seem like we're introducing any workflows the security software isn't already comfortable with.
4. It's probably not a good idea to rely on a retroactively revealed identity based on a hook as an alibi for a crime scene (i.e. to prove that so-and-so was snapping some photo on their camera and therefore far away from the scene of the crime). But aside from that relatively contrived example, I do struggle to think of places where the non-concurrent binding of identity reduces the power of the credential, so it would be helpful to bring up more potentially damaging scenarios if we can come up with them.

[scouten-adobe]

@andrewDworschak to lead discussion on this issue for 1.2 milestone.