#dusk $DUSK @Dusk I spent time in Dusk's Citadel documentation and found a detail in the academic paper that the marketing description of self-sovereign identity never surfaces.
The revocation mechanism.
Citadel is described as a self-sovereign identity system. Users manage their own credentials. Prove attributes without revealing them. Age bracket. Residency. Accreditation status. The zero-knowledge proof means the service provider learns only that you qualify. Nothing more.
That part is real and genuinely well designed.
Then I found this line in the Citadel paper.
"If under some circumstances the SP no longer accepts some previously issued licenses, they can prove to the network that a given note is no longer valid."
The Service Provider initiates revocation. Not the user.
Hmmmm Self-sovereign identity typically implies the user controls their credentials. Citadel's revocation model inverts that specific control. The SP decides when a license is no longer valid and proves that to the network. The network accepts the revocation. The user's license stops working.
On a privacy chain where license notes are privately stored, the user has no on-chain visibility into whether their license has been revoked until they attempt to use it and it fails.
The Citadel paper lists three parties: the user, the service provider, and the license contract. The license contract enforces validity. The SP controls what validity means.
The docs describe this as programmable compliance. The EU can program regulations into Citadel itself. That framing makes revocation sound like a regulatory tool.
It is also an administrative tool. The same mechanism that lets a regulator revoke a sanctioned user's access lets any SP revoke any user for any reason.
What recourse exists after revocation and who arbitrates disputed revocations is the question the documentation does not answer.
The revocation mechanism.
Citadel is described as a self-sovereign identity system. Users manage their own credentials. Prove attributes without revealing them. Age bracket. Residency. Accreditation status. The zero-knowledge proof means the service provider learns only that you qualify. Nothing more.
That part is real and genuinely well designed.
Then I found this line in the Citadel paper.
"If under some circumstances the SP no longer accepts some previously issued licenses, they can prove to the network that a given note is no longer valid."
The Service Provider initiates revocation. Not the user.
Hmmmm Self-sovereign identity typically implies the user controls their credentials. Citadel's revocation model inverts that specific control. The SP decides when a license is no longer valid and proves that to the network. The network accepts the revocation. The user's license stops working.
On a privacy chain where license notes are privately stored, the user has no on-chain visibility into whether their license has been revoked until they attempt to use it and it fails.
The Citadel paper lists three parties: the user, the service provider, and the license contract. The license contract enforces validity. The SP controls what validity means.
The docs describe this as programmable compliance. The EU can program regulations into Citadel itself. That framing makes revocation sound like a regulatory tool.
It is also an administrative tool. The same mechanism that lets a regulator revoke a sanctioned user's access lets any SP revoke any user for any reason.
What recourse exists after revocation and who arbitrates disputed revocations is the question the documentation does not answer.