Validate and Verify Audit Information Before Registration

[AkramBitar]

Problem

RegisterRecipientIdentity accepted recipient identity data without structural validation, so malformed or incomplete RecipientData could be persisted into the audit trail.

Solution

A structural validation in token/services/identity/wallet, run before the existing MatchIdentity cryptographic binding:

1. Basic structure — nil/empty checks and length bounds: identity 10 B … 1 MiB, audit info ≤ 50 KB. (The identity cap is generous so composite identities — MultiSig/Policy aggregate several inner identities — and larger X509/Idemix payloads are never falsely rejected; it only rejects pathological multi-MB blobs.)
2. JSON well-formedness — audit info must be valid JSON.
3. Identity structure — the typed identity is decoded once, its type must be recognized (Idemix, X509, IdemixNym, HTLC, MultiSig, Policy), and the raw identity payload must be non-empty.
4. Enrollment ID — non-empty, ≤ 256 B (non-composite types only).
5. Revocation handle — non-empty, ≤ 512 B (non-composite types only).
6. Cryptographic binding — existing Deserializer.MatchIdentity (identity ↔ audit info).

Composite types (MultiSig, HTLC, Policy) have no enrollment ID / revocation handle, so steps 4–5 are skipped for them in one place.