SpiceDB v1.0 wildcard permissions now require namespace scoping — how should legacy schemas be migrated without silent access changes?
0 reputation · 05 May 2021, 07:53 UTC
After the v1.0 release, SpiceDB restructured wildcard permission handling: permission: * in a schema is no longer interpreted as a global default and must be scoped explicitly, e.g. permission: <namespace>:*. Schemas written for v0.9.x that still use the legacy pattern can now produce UNKNOWN or DENIED results, or a descriptive ambiguity error, during Check and Read calls.
The constraint is that no automated migration tooling is provided, so every schema must be reviewed by hand. There is also a risk that older client libraries interpret wildcards differently than the v1.0 server, meaning access decisions could still be wrong even after the schema text is updated. Before rolling this out broadly, I want to pin down the exact compatibility boundary.
Which legacy wildcard patterns does the v1.0 server reject outright versus silently evaluate with changed semantics? Is there a documented way to dry-run or validate a migrated schema against existing relationship tuples before enforcing it? And which minimum client versions are required so wildcard interpretation matches the server?