ICACT20260076 Question.1
Questioner: abilaaniloshan@gmail.com 2026-02-09 오후 3:36:22 |
ICACT20260076 Answer.1
Answer by Auhor pes2202100486@pesu.pes.edu 2026-02-09 오후 3:36:22
Chrome  Click!! |
| Your index uses a blue–green write queue and may reject queries that require freshness beyond the last index update. In production Zanzibar-like systems, how do you guarantee correctness or strong consistency during high write bursts—especially for permission revocations—without falling back too often to SpiceDB’s BFS resolver? |
Auth graphs are empirically read-heavy (~99% checks, ~1% writes), so production designs optimize for fast indexed reads while amortizing write cost. During high write bursts, updates are absorbed into the blue–green write queue, and index recomputation is triggered either when a write-count threshold or time bound is crossed, preventing the index from drifting too far from the datastore state.
Queries that require freshness newer than the last index update are not answered by the index and are handed to SpiceDB’s resolver, so correctness—especially for revocations—is preserved even under bursty writes.
Because most traffic is reads, this fallback path remains rare, letting the system retain low latency without sacrificing strong authorization guarantees. |
ICACT20260076 Question.2
Questioner: smaran.jawalkar@gmail.com 2026-02-10 오후 1:32:26 |
ICACT20260076 Answer.2
Answer by Auhor pes2202100486@pesu.pes.edu 2026-02-10 오후 1:32:26
Chrome Click!! |
| Respected Chair, We have been incorrectly marked as attending in-person while we are attending online.
Kindly request you to acknowledge the same and let us know of any additional details on how to attend online. |
|
ICACT20260076 Question.3
Questioner: abdelhadi.belfadel@irt-systemx.fr 2026-02-10 오후 3:32:11 |
ICACT20260076 Answer.3
Answer by Auhor pes2202100486@pesu.pes.edu 2026-02-10 오후 3:32:11
Chrome Click!! |
| How would this framework integrate with an Identity Provider like Keycloak?
Would the authorization check happen during the token issuance (adding permissions to the JWT) or as a real-time call to your graph index at the API Gateway level?
|
While I am unaware of the exact specifics of how keycloak works, Google Zanzibar / SpiceDB is a alternate Authorization system to the Authorization features provided by Keycloak or any Identity Provider, and is intended to assume full responsibility of the authorization. Relationship based Access Control (ReBAC) systems in general usually function via a real time call instead of the authorization being embedded in a token to be statelessly checked.
It might be possible to integrate some ReBAC systems with keycloak but that would be a non standard way of doing things, unless keycloak is only used for authentication and makes the real time call to spicedb. Such a use case is discussed in detail here: https://linen.authzed.com/t/28578814/how-does-spicedb-compare-to-keycloak-s
There also seems to be an open github issue to add spicedb as a native authorization engine to keycloak: https://github.com/keycloak/keycloak/issues/45096 |
ICACT20260076 Question.4
Questioner: abdelhadi.belfadel@irt-systemx.fr 2026-02-10 오후 3:54:03 |
ICACT20260076 Answer.4
Answer by Auhor pes2202100486@pesu.pes.edu 2026-02-10 오후 3:54:03
Chrome Click!! |
| Since I use Keycloak as my PDP in an ABAC approach (look for ZTA approach of my first presented paper in this session), could your indexing framework be integrated as a Keycloak Authorization Policy to speed up complex relationship lookups? |
The indexing framework laid out in our paper is designed to speedup authorization data which is modeled and stored as a graph. If Keycloaks ABAC ACLs can be modeled or are stored as a graph, our framework would be excellent at speeding it up. I am unaware of how Keycloaks Pluggable Auth Policies work. Perhaps you could provide me with some insights on how keycloaks ABAC stores/models is ACLs and based on that this indexing mechanism might or might not be helpful |
ICACT20260076 Question.5
Questioner: mahi.sfo@gmail.com 2026-02-11 오후 4:50:51 |
ICACT20260076 Answer.5
Answer by Auhor pes2202100486@pesu.pes.edu 2026-02-11 오후 4:50:51
Chrome Click!! |
| How does Dynaclo behave under adversarial or worst-case graph structures (e.g., highly skewed hierarchies or permission graphs where random support-vertex selection performs poorly), and what formal or empirical guarantees can you provide on correctness, fallback frequency, and latency in those cases? |
While we have implemented random SV selection for simplicity, the SV algorithm adapted by us presented in "Faster Fully Dynamic Transitive Closure in Practice" by Kathrin et al. supports 2 variants of the SV algorithm which clears the list of chosed support vertices after c updates called SVA (variant 1) and SVC where the there is exactly one Support Vertex per Strongly Connected Component (SCC) [More info on this can be found in the aforementioned paper]. If there were cases where our index performed poorly for certain graphs, we could explore changing our implementations to these variants of our already used SV algorithm. In any case since the worst case option is the fallback to BFS we would still perform better than vanilla spicedb. If you could provide me with some concrete examples of what such worst case graph structures look like, I can reason about their effect on fallback frequency and latencies, which in the end can only be tested experimentally. Correctness is always guarenteed under the current system as it prefers correctness over performance |
