A trivial approach would be to let the trusted party generate the commit and send the private vector along the signed commit to the proover, which should like this in your age range checking example:
Notation:
$P$ is the proover, $T$ is the trusted party, $V$ is the verifier, $a$ is the information to convince $T$ of $P$'s age, $A \rightarrow B: x$ means that party $A$ send information $x$ to party $B$.
- $P \rightarrow T$: $a$
- $T$ generates chooses a random $r$, calculates $C=rG+[age]H$ and signs $C$ using his private key.
- $T \rightarrow P$: $r, C, signature$
- $P \rightarrow V: C, signature, proof$
Whilst straightforward, the trusted party get's to choose the commit which you may not want depending on how much you trust the trusted party, so here is another approach that allows the proover to choose $C$.
- $P$ chooses a random $r$ and calculates the commit $C = rG + [age]H$.
- $P$ signs $a$ with $r$ as private key
- $P \leftarrow T: C,a, signature_a$
- $T$ looks up $P$'s age, calculates $R=C-[age]H$, verifies $signature_a$ against $R$ and sign's $C$ using $T$'s private key.
- $T \rightarrow P: signature_c$
- $P \rightarrow V: C, signature_c, proof$
Of course, $V$ will have to verify the signature. Instead of a signature, $V$ could also make a request to $T$ to check whether it approves $C$ which allows $T$ to revoke easily but requires you put more trust into the trusted party.
Lastly, I'd like to mention a completely different approach used in Monero's RingCT which uses commits to represent balances and the blockchain to keep track of and to verify them.
