@SignOfficial
I was decoding an attestation against its schema this morning when something didn’t line up.
The schema looked clean.
Fields made sense.
Then I pulled the attestation.
The data didn’t follow it.
Not loosely.
Not even close.
I thought I messed up the decode.
Ran it again.
Same bytes.
Nothing changed.
Still verified.
No error.
No rejection.
Nothing even hinting something was off.
That’s where it stopped making sense.
The schema said one thing.
The data did something else.
And the system didn’t care.
I tried another one.
Different issuer.
Same pattern.
schemaId holds.
Attestation.data drifts.
Still passes.
I stayed on it longer than I planned.
Because it felt like I was missing a rule somewhere.
But there wasn’t one.
That’s when it clicked.
Schema ghost.
The check isn’t between schema and data.
It’s between existence and reference.
It points.
That’s enough.
The structure shows up.
Whether it’s followed or not... doesn’t.
A credential that looks structured from the outside...
but isn’t held to it underneath.
The schema is there.
But it isn’t doing anything.
And once that happens...
it stops being a rule.
It just becomes a label.
$SIGN only matters if Attestation.data is actually validated against Schema.schema at verification time...
not just attached to it by reference.
Because if credentials can drift away from the structures they claim to follow...
verification starts looking correct...
without actually being correct.
So the real question becomes this.
If matching the schema isn’t required to pass...
what exactly does “valid” mean here?