I used to assume that once a blockchain can prove someone holds a valid credential, the access decision is basically finished.
Reading about Citadel 2 on @Dusk made me realize those are actually two separate questions.
Citadel 2 allows a user to generate a zero-knowledge proof showing that they own a registered, License Provider-signed license without revealing which specific license is being used. The Citadel contract verifies the proof and records a public session.
But a cryptographically valid session does not automatically mean access should be granted.
Dusk’s documentation makes that distinction explicit. The Service Provider still decides which License Providers it trusts, which attributes it accepts, whether the session is expired or revoked, and whether the session cookie can be reused.
That separation changed how I think about digital identity.
The protocol can verify the cryptographic validity of a session while leaving service policy to the Service Provider.
To me, that suggests an important boundary: proving that a credential-based session is valid is not the same thing as deciding whether that proof satisfies a particular service’s requirements.
So perhaps the better identity question is not simply whether a user can prove something about their credentials.
It is: what should cryptography verify, and what should remain a policy decision for the service using that proof?
For me, that distinction is one of the more interesting ideas behind Citadel 2.
$DUSK #dusk @Dusk
Reading about Citadel 2 on @Dusk made me realize those are actually two separate questions.
Citadel 2 allows a user to generate a zero-knowledge proof showing that they own a registered, License Provider-signed license without revealing which specific license is being used. The Citadel contract verifies the proof and records a public session.
But a cryptographically valid session does not automatically mean access should be granted.
Dusk’s documentation makes that distinction explicit. The Service Provider still decides which License Providers it trusts, which attributes it accepts, whether the session is expired or revoked, and whether the session cookie can be reused.
That separation changed how I think about digital identity.
The protocol can verify the cryptographic validity of a session while leaving service policy to the Service Provider.
To me, that suggests an important boundary: proving that a credential-based session is valid is not the same thing as deciding whether that proof satisfies a particular service’s requirements.
So perhaps the better identity question is not simply whether a user can prove something about their credentials.
It is: what should cryptography verify, and what should remain a policy decision for the service using that proof?
For me, that distinction is one of the more interesting ideas behind Citadel 2.
$DUSK #dusk @Dusk
