I kept returning to the Citadel flow this morning.
A user requests a license from a License Provider. That provider checks the person off-chain, signs the relevant attributes, and registers an encrypted license. Later the user generates a zero-knowledge proof showing ownership of a registered license without placing the personal details or the specific license on the ledger. The contract records only a public session.
That is the selective disclosure piece in practice. The network never sees the underlying attributes. A service can still receive only the exact field it needs if the user chooses to open it.
One real situation this maps to is an investor trying to buy into a restricted security offering. In the traditional process the issuer or transfer agent often receives a full set of personal documents to confirm accredited status or residency. With this model the proof can confirm the required condition while the complete file stays private and is not repeatedly exposed.
Two things still sit unresolved for me.
The entire system depends on License Providers that institutions will actually trust. The hard verification work happens off-chain first. If those providers remain few or slow to appear, the on-chain privacy layer has limited reach.
A valid proof also does not automatically open the door. The Service Provider still applies its own policy after the session is recorded. It decides whether the disclosed attribute meets the rule, whether the session is still valid, and whether the source License Provider is accepted. Cryptography handles the credential path. Policy still owns the final yes or no.
The design keeps privacy as the default and disclosure as a deliberate choice. The open question is how cleanly that split works when real regulated workflows start using it at scale.
#dusk @Dusk $DUSK
A user requests a license from a License Provider. That provider checks the person off-chain, signs the relevant attributes, and registers an encrypted license. Later the user generates a zero-knowledge proof showing ownership of a registered license without placing the personal details or the specific license on the ledger. The contract records only a public session.
That is the selective disclosure piece in practice. The network never sees the underlying attributes. A service can still receive only the exact field it needs if the user chooses to open it.
One real situation this maps to is an investor trying to buy into a restricted security offering. In the traditional process the issuer or transfer agent often receives a full set of personal documents to confirm accredited status or residency. With this model the proof can confirm the required condition while the complete file stays private and is not repeatedly exposed.
Two things still sit unresolved for me.
The entire system depends on License Providers that institutions will actually trust. The hard verification work happens off-chain first. If those providers remain few or slow to appear, the on-chain privacy layer has limited reach.
A valid proof also does not automatically open the door. The Service Provider still applies its own policy after the session is recorded. It decides whether the disclosed attribute meets the rule, whether the session is still valid, and whether the source License Provider is accepted. Cryptography handles the credential path. Policy still owns the final yes or no.
The design keeps privacy as the default and disclosure as a deliberate choice. The open question is how cleanly that split works when real regulated workflows start using it at scale.
#dusk @Dusk $DUSK