Oh okay's earlier question separates the submitted name from an NFC lookup key. Signing adds a different boundary. Suppose a JSON payload contains a name written with e followed by U+0301, and that string participates in a JCS-based signature.
RFC 8785 preserves parsed Unicode string data without normalization. JCS still performs canonical JSON serialization, so the representation supplied for signing is not simply the original JSON source bytes. Replacing that name with U+00E9 before canonicalization would change the string data the protocol preserves.
I would retain the payload values supplied to JCS and derive the NFC lookup key into a separate application field. That costs another representation, but keeps the lookup transformation explicit. Two payloads could produce the same application key while retaining different Unicode string data for JCS.
Where should that derivation happen so code performing lookup cannot silently substitute its key into the payload supplied to JCS?