I found a strange boundary in Citadel 2: the zero-knowledge proof can be valid and the user can still be denied.
The flow is stricter than “prove identity, get access.” A License Provider checks the user off-chain, signs the relevant attributes, and registers an encrypted license in a Citadel contract. Later the user proves they own a registered LP-signed license without putting the personal details or exact license on-chain. Citadel verifies that proof and records a public session.
But the session is not permission. The Service Provider still has to decide which License Providers it trusts, whether the disclosed attribute satisfies its rule, whether the session is expired or revoked, and whether the cookie can be reused.
That split is what I keep looking at. If I am building a regulated service on Dusk, cryptography proves the credential path. My policy still owns the final access decision. A stale or wrongly trusted session should die at that boundary, not become a valid-looking pass.
The pressure point is simple: when policy changes faster than credentials do, does the service reject the right session before access is granted?
#dusk $DUSK @Dusk
#USJulyCPI&PPIDueThisWeek
The flow is stricter than “prove identity, get access.” A License Provider checks the user off-chain, signs the relevant attributes, and registers an encrypted license in a Citadel contract. Later the user proves they own a registered LP-signed license without putting the personal details or exact license on-chain. Citadel verifies that proof and records a public session.
But the session is not permission. The Service Provider still has to decide which License Providers it trusts, whether the disclosed attribute satisfies its rule, whether the session is expired or revoked, and whether the cookie can be reused.
That split is what I keep looking at. If I am building a regulated service on Dusk, cryptography proves the credential path. My policy still owns the final access decision. A stale or wrongly trusted session should die at that boundary, not become a valid-looking pass.
The pressure point is simple: when policy changes faster than credentials do, does the service reject the right session before access is granted?
#dusk $DUSK @Dusk
#USJulyCPI&PPIDueThisWeek