I was looking at a credential this morning to see how it would behave after issuance.
Not whether it verified.
That part was already done.
It had passed.
schemaId matched.
attester checked out.
attestTimestamp was recent.
Everything about it looked clean.
What I wanted to see was what happens after that.
So I tried to revoke it.
Nothing changed.
No error.
No rejection.
The credential stayed valid.
For a second I assumed I had called the wrong path.
Or hit the wrong address.
So I checked where revocation authority actually sits.
The address was there.
Explicit.
But it didn’t match the attester.
That’s where it started to shift.
I didn’t rerun the same credential.
I picked another one.
Different schema.
Different issuer.
Same outcome.
Issuance came from one entity.
Revocation authority pointed somewhere else.
Still no failure.
Still no warning.
The system accepted both roles without conflict.
That’s what didn’t hold up.
Because verification had already told me the credential was valid.
But nothing in that step reflected who could later invalidate it.
So I slowed down.
Not checking again.
Just following what the system allows.
attester defines the claim.
Schema.registrant defines whether it can continue to exist.
Two different fields.
Two different authorities.
Onevisible at issuance.
The other only visible if you go looking for it.
And nothing requires them to align.
That’s when it settled.
Revocation split.
Not a mismatch.
Not an error.
A structural separation.
The entity that establishes truth...
and the entity that can remove it...
don’t have to be the same.
I kept pushing it through different cases.
Multiple issuers.
Different schemas.
Different timestamps.
The pattern held.
A credential could be issued by one party...
and silently controlled by another.
And every time, verification returned the same result.
Valid.
That’s where it gets harder to reason about.
Because verification doesn’t fail.
It completes exactly as designed.
But what it confirms is narrower than it looks.
It confirms that a credential was issued correctly.
Not that the entity you trust...
is the one that controls its lifecycle.
That dependency sits outside the verification step.
Hidden in how authority is assigned.
So two systems can read the same credential.
Check the same attester.
See the same data.
And still be relying on different assumptions about control.
Not because anything changed after.
Because the split was already there.
Before verification even happened.
I kept thinking about what that looks like under real usage.
Not single credentials.
Systems.
Where schemas evolve.
Where registrants change.
Where revocation rights can be delegated or transferred.
The credential itself doesn’t surface that boundary.
You see the issuer.
You trust the issuer.
But the authority to revoke it may sit somewhere else entirely.
And nothing in the verification result tells you that.
From the outside, everything is consistent.
Inside, control is fragmented.
That shifts what “valid” actually means.
Because now validity depends on more than correctness.
It depends on alignment.
Between who defines the credential...
and who controls whether it continues to exist.
$SIGN only matters if the attester that issues a credential also holds revocation authority over it...
not just the Schema.registrant controlling the schema it was issued under.
Because once that boundary splits...
you don’t just introduce flexibility.
You introduce a second authority.
One that can override truth after it’s already been established.
And the system will still report everything as valid.
So the real question becomes this.
If issuance and revocation don’t come from the same place...
what exactly are you verifying when you trust a credential?