We don't have a concrete design yet to answer all of those questions; there are a few different options we've discussed that would have different properties. If you can give examples of the time and location based accesses (ideally in the github issue so we don't lose track!) that will help us evaluate designs going forward But not to leave you hanging, these are my best-effort answers to what things might look like: > When you say 'user-supplied' attributes, what do you mean? If you have a relationship with a time caveat, you provide us with the "current" time to evaluate against. > When are these attributes supplied? Likely when you make an api call like

Check

. This proposal makes a distinction between the policy/attributes associated with a relationship (which would be provided when the relationship is written) and attributes that you provide at query time to evaluate against the stored relations. > How are these attributes expressed? TBD, but ideally in a way that won't tank cache hit ratios. I would think something datalog-y so that rule evaluation is order-independent, but we don't have any concrete proposal yet. > Do you plan to support different data types for these attributes? Also TBD, but probably. Distinguishing time at a minimum seems valuable to me, but other folks may have other ideas.