Zero knowledge set membership protocol I read that paper Efficient Protocols for Set Membership and Range Proofs of Camenisch et. al that describes the zero knowledge range proof. The paper applications looks interesting like if you want to proof your age between a range without stating exactly what is the exact age?

But I read that a commitment (C) provided by the prover to the verifier should be first verified by a trusted party before it can be used in the zero-knowledge protocol? Is it just a signature on the C value? 

I need a simple explanation of how such a commitment can be done. Since as far as I know about a commitment (C) that is only known for only one party.
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.