Bidirectional binding of identity assertions and claims

[paulengland]

• [x] I have read the CLA Document and I hereby sign the CLA.

---

If a claim hashes an identity assertion - presumably as part of the gathered assertions - then the identity assertion is tamper-protected, but the converse is not true: an attacker can strip the claim signature and replace it without a validation failure. This can be problematic for some scenarios: for example, a claim signature from a phone could be replaced by a signature from an editing suite.

Fundamentally, I think the binding is the wrong way around: it makes much more sense for the publisher (e.g., me) to commit to the claim-generator/tool that they used, not the other way around.

We could add band-aids - e.g., identity assertions contain the public key of the (subsequent) claim signer, but I think we should have a conversation about whether this is really the right way of doing this.

Similar arguments/problems occur in the case of multiple ID assertions: later assertions can be bound to ID assertions created earlier, but later ID assertions can be replaced without a validation failure.

[scouten-adobe]

ACTION: @scouten-adobe to write a PR addressing #68; follow up with @paulengland when that's available.

[scouten-adobe]

@scouten-adobe to provide write access to @paulengland

[scouten-adobe]

Closing in favor of #95.