Thanks Robert, this was very helpful.

I went through these points and made the consistency guarantees *explicit
backend conformance requirements in Parts 1 and 2*, rather than leaving
them implied by the proposed JDBC layout.

The contract now says that overlapping Tag operations must behave as if one
happened before the other: *a successful operation becomes fully visible,
while a failed one changes nothing*. The specific assign/update/delete
races are spelled out, *detach-all=true is all-or-nothing to API callers*,
and each reverse-lookup item must come from one assignment state rather
than combining a target, value, or apply method from different states.

I also added these as backend behavior-test requirements. *An
implementation that cannot provide the required result must reject or not
expose the operation; it cannot report success with weaker or partial
semantics*. The implementation mechanism remains open: transaction, CAS,
atomic batch, provider-native operation, etc.

On the authorization points:

For reverse lookup, *I kept the catalog-wide behavior intentionally*. The
operation requires a catalog-wide tag-assignment lookup privilege plus
TAG_READ on the named tag definition. It can return matching target
identities, selected values, and the direct apply method without doing a
property-read check on every matching target. I made this an explicit
disclosure/security contract rather than presenting it as a serving
optimization. Ordinary object read/list permissions do not imply this
authority.

For detach-all=true, *I changed the proposal: TAG_DROP alone is no longer
sufficient*. The caller needs both TAG_DROP and TAG_DETACH on the tag
definition. TAG_DROP authorizes deleting the definition; TAG_DETACH
additionally authorizes removing all of that definition's assignments
across the catalog. We still do not perform per-target detach checks for
this bulk path.

I agree with the general framing you suggested: *the observable consistency
and security semantics belong to the Tag contract; the physical mechanism
belongs to the backend.*

I've updated the doc, please check it out the latest and the greatest:
https://docs.google.com/document/d/1rIJGzcsmGhfrBiRXPac51hr-jeJuuKQQBYjgBdOb9-k/edit?pli=1&tab=t.0

Thanks again for calling these out.

-ej

Reply via email to