feat: add DID signature verification and replay protection

[ntn-x2]

Fixes https://github.com/KILTprotocol/ticket/issues/2553.

The main changes are:

• Removed half-baked versioning support, to re-introduce a proper one once versioning and version negotiation will be tackeld
• Moved most of the logic from the runtime-common crate to a new kilt-dip-support crate, after making all the types generic over all the runtime configurations
• Updated the pallet-dip-consumer pallet to have a bunch more details, more info below
• Updated the XCM-simulator based tests

Updates to the dip-support crate

The dip-support does not contain any versioned types anymore. Support for versioning was half-baked and has been removed. Proper thought around versioning and version negotiation will happen in the (short) future.

New kilt-dip-support crate

The new kilt-dip-support crate contains types and traits that are not generic over ANY DIP deployment, but that can be used by every consumer that relies on the KILT chain as their provider. Hence, types are opinionated towards the way KILT implements the DIP protocol, but generic over the runtime configuration.
The most relevant types are MerkleProofAndDidSignatureVerifier, exported from the root, DidMerkleProofVerifier, exported from the merkle module, and DidSignatureAndCallVerifier, exported from the did module. When they are chained together, they allow a user to submit a Merkle proof revealing parts of their DID Document, and to use one of the revealed keys to sign a specifically-crafted payload which provides authenticity guarantees of the DID subject.

The default verification logic for the DID signature is the following:

1. Verify that the block number specified in the signature is no older than SIGNATURE_VALIDITY blocks, as specified by the runtime
2. Verify that the signature can be verified over the encoded tuple formed by (call, identity_details, submitter_address, block_number, genesis_hash, signed_extra), where signed_extra can be anything more that the runtime might require be included in the signature.
3. Verify that one of the keys revealed in the Merkle proof can be used to verify the provided signature
4. [OPTIONAL] If the type variant which also performs authorization checks on the call itself is used, i.e., the DidSignatureAndCallVerifier type, then the verification will also include checking whether the used verification relationship can be used to dispatch the specified call or not, as we do ourselves in our did pallet within the submit_did_call, but in a more generic way.

The verification logic for Merkle proofs has remained unchanged, and it can now be chained with the DID verification logic.

Refreshed pallet-dip-consumer

The pallet has been updated so that now the dispatch_as extrinsic takes a generic Proof instead of an IdentityProof, and internally performs the following checks:

1. Verify the origin is a signed origin (as before)
2. Verify that the call passes a preliminary filter, before any heavy computation is executed on the provided proof, via the DipCallOriginFilter type. This step will typically immediately filter out any calls that cannot be called with a Dip origin regardless of the content of the proof.
3. Retrieves the identity details from storage, if they exist
4. Delegate everything to the ProofVerifier, which has a mutable reference to the details fetched at step 3, in case they need to update some values that will be written to storage (e.g., the nonce)
5. The maybe mutated details are written back into storage
6. The call is dispatched with the new DipOrigin, which carries the additional information as returned by the ProofVerifier. In the demo runtime, this will be the set of keys revealed as part of the Merkle proof, that have been verified, parsed, and used for verifying the DID signature provided as part of the proof.

The pallet logic is very simple, and most of the (complex) logic lies in the types that have been exposed as part of the kilt-dip-support crate. This makes the pallet easier to understand, and more generic to be used in different contexts potentially for different identity providers as well, where each provider might require users to provide a different identity proof.

Minor changes

Other things have been updated to reflect the relocation of some files into the new kilt-dip-support crate.

How to test

1. Build this version of the SDK
2. Clone and yarn install && yarn build this version of the PolkadotJS apps
3. Copy-paste the @kiltprotocol/type-definitions output into the root node_modules folder of the PolkadotJS apps
4. Follow the steps to set up the HRMP channels, create the DIDs, and push the identity commitment from provider to consumer
5. Use this version of the kilt-did-utilities CLI tool to generate a valid DIP DID signature.
6. Enjoy ☀️☀️☀️

[weichweich]

Why not implement the From trait?

[ntn-x2]

That would also work, but the idea is to make clear that only the digest is initialised, the rest is taken as default. I am afraid the From would not make it as clear. What do you think?

[weichweich]

I think it's clear. Since it's also only get a digest as parameter.

[ntn-x2]

Alright, I replaced this with the implementation of the From<Digest> trait 👍

[weichweich]

Why is this specific for MerkelProof and DidSignature? If it's specific for those two, why the use of traits?

IMO this should be a general implementation for two IdentityProofVerifier (which it looks to be). In that case I would also call it that way.

[ntn-x2]

The logic here is a bit more convoluted.
Inside the code, we do:

	type IdentityDetails = <DidSignatureVerifier as IdentityProofVerifier<Call, Subject>>::IdentityDetails;
	type Submitter = <MerkleProofVerifier as IdentityProofVerifier<Call, Subject>>::Submitter;
	type VerificationResult = <MerkleProofVerifier as IdentityProofVerifier<Call, Subject>>::VerificationResult;

So this case is rather specific to the process of: 1. verifying the Merkle proof, 2. use the additional details + the result of the Merkle proof to verify the DID signature. It would be hard to chain them in a generic way, since the DID signature verifier requires the result of the Merkle verification + the DID signature and block number. I agree probably the traits are not really a good fit here. I'll remove them.

[ntn-x2]

Double-thinking this, I think it's ok to leave traits here. Yes, it's not generic, but for instance the DID verifier trait might or might not include the check on the call type. Having a generic Chained<A, B> type might make sense, but the provided default would still be the one provided here. Hence, I think, at least for now, I will not integrate this comment, although time and other projects will tell whether we need a more generic solution here.
For now, the only reason to have traits here, is that the individual components, i.e., the Merkle verifier and the DID signature verifier, can be swapped with other types that implement the same trait. For instance, for the DID verifier, it could perform the additional call filtering or not, depending on the use case.