Sharing, Roles, Provisioning, and Revocation

Visibility describes who may discover and read a Workboard board; it does not grant mutation rights. Precise modes prevent a UI label from promising more confidentiality than the APIs, caches, exports, or links actually enforce.

Mode	Anonymous read	Discovery	Authenticated read	Mutation
Public	Allowed	Listed in public catalog and search	Allowed	Active membership and role required
Unlisted	Allowed to a valid link holder	Excluded from catalog and ordinary discovery	Allowed to a valid link holder	Active membership and role required
Organization	Denied	Visible only inside the organization	Current organization membership required	Role and resource policy required
Private	Denied	Visible only to explicitly granted members	Active tenant membership plus an explicit board grant required	Role and resource policy required

public means anonymous reading is intentionally permitted; it never means anonymous create, update, delete, comment, export administration, or settings access. unlisted means possession of the URL or capability token permits anonymous reading. It is not a confidentiality boundary: recipients can forward the link, browsers can retain it, and referrers or logs can expose it. If Workboard implements unlisted access as a capability—a secret whose possession grants access—the capability must be high entropy, stored and logged safely, scoped to one resource, and rotatable.

organization requires a current active membership in the board’s tenant, even when the person knows the URL. private narrows access further to an active tenant membership plus an explicit board-scoped grant. The grant is resource-policy data, not a second tenant Membership, and it cannot create a tenant role by itself. A person can belong to Tenant Alpha and still be denied an Alpha private board.

Default to private for new enterprise boards. Missing or unknown visibility, tenant, membership, capability, or policy version produces denial, not a fallback to public. Visibility changes are security-sensitive writes that require authorization, audit events, cache invalidation, and subscription reauthorization.

Anonymous modes limit person-specific revocation. Workboard cannot block one revoked person from reading a board that remains public, because public read does not identify that person. Revoking access to an unlisted board requires rotating its capability link and purging old cache variants; revoking a membership alone does not invalidate a URL the person still holds. To stop anonymous reading entirely, change the board to organization or private visibility and invalidate every delivery path, while still acknowledging copies already downloaded.

An invitation is a request to create a relationship, not proof that the recipient already has access. Model it as a state transition so duplicate emails, expired links, identity mismatches, suspension, and revocation behave predictably.

The Workboard tenant Membership record has { tenantId, principalId, role, state, invitedAt, activatedAt, revokedAt }. When the recipient is not yet bound to a verified principal, keep the Invited and Expired states in a separate invitation record; create the principal-keyed membership as Active only after verified acceptance. The diagram below is the combined lifecycle view across those records. Bind acceptance to the authenticated principal and intended tenant, use a one-time expiring token, and record who invited whom.

Only an Active membership can satisfy an authorization decision. Invitation states and Suspended or Revoked memberships all deny. State changes use compare-and-set or another concurrency control so accepting and revoking the same invitation cannot accidentally reactivate it. Reinvitation creates a new invitation and token; it does not erase the audit history or mutate a revoked membership back to active.

Tenant owners may invite members and issue private-board grants only within policy; they cannot delegate a role or resource scope wider than their own authority. Require step-up authentication or a recent session for high-impact owner grants. Notify the affected person and tenant owners, but do not include secret invitation or capability values in general-purpose logs.

A role is a named bundle of allowed actions. Least privilege means assigning only the actions needed for a person’s job and limiting them to the correct tenant and resource rather than treating a role name as global power.

Tenant role	Read boards	Create or edit todos	Export board	Manage tenant members and board grants	Delete board
Viewer	Allowed by visibility and any required board grant	Deny	Policy-controlled	Deny	Deny
Editor	Allowed by visibility and any required board grant	Allow on accessible boards	Policy-controlled	Deny	Deny
Owner	All tenant boards	Allow	Allow	Allow	Allow with confirmation

The table is a policy input, not authorization by itself. Every decision still binds principalId, tenantId, resource, action, membership state, policy version, and expiry. A board grant can narrow which private boards a viewer or editor may use, but it cannot elevate that tenant role. An Alpha owner has no Beta permissions unless Beta independently grants them.

Keep organization administration separate from content work. Tenant owners manage organization memberships, approved domains, and private-board grants; editors change todos on accessible boards; viewers read accessible boards. Service accounts and API keys receive purpose-specific actions and expiry rather than being squeezed into human roles. Deny role self-escalation, the removal of the last required owner without a transfer flow, and grants wider than the granting principal is allowed to make.

Review dormant and high-impact memberships periodically. Record grants, changes, suspensions, and revocations as immutable audit events with actor, tenant, target, old and new role, policy version, reason, and trace identifier.

A sharing policy is only as strong as its least protected delivery path. Workboard must make the same visibility and authorization decision wherever board information can be rendered, queried, derived, copied, cached, streamed, or processed later.

Access path	Required enforcement
Server-side rendered page	Resolve current policy before rendering; private data never enters denied HTML
Direct API	Authenticate when required, derive tenant, authorize resource and action
Catalog, list, and search	Apply discovery semantics and tenant filters before ranking or counting
Export	Authorize at request and execution; scope output and download capability
Attachment or blob	Authorize before redirect/signing; short expiry and resource scope
Link preview or unfurl	Treat crawler as anonymous; do not reveal restricted title or image
CDN and application cache	Key by visibility, tenant, subject/policy class and policy version; purge on change
Background job	Carry tenant/resource context and reauthorize when work starts
Websocket or subscription	Authorize handshake and topic; reauthorize on reconnect and relevant policy change

For public content, caches can be shared anonymously only after policy explicitly returns public-read. Organization and private responses must not share cache entries across tenants or principals. Unlisted entries must not appear in sitemaps, catalog pages, ordinary search, analytics labels, or previews; cache keys must include the capability version so rotation makes older cache entries unreachable.

Authorize exports twice when queued: once when requested and again when generated or downloaded. Scope blob URLs narrowly and expire them quickly, but recognize that a recipient can copy downloaded bytes. For subscriptions, authorize the exact board topic rather than trusting a client-provided channel name, and stop delivery when membership or visibility changes.

System for Cross-domain Identity Management (SCIM) is an HTTP protocol for provisioning and managing identity resources such as users and groups across administrative domains. It lets an enterprise identity system drive Workboard lifecycle changes without manual account-by-account administration.

Map a configured SCIM client to exactly one Workboard tenant before processing resources. Authenticate and authorize the client, use TLS, validate schemas and tenant-scoped uniqueness, and make create and update operations idempotent. The SCIM external identifier helps correlate records but does not itself prove tenant or application authorization.

Group mapping can assign a maximum role allowed by tenant configuration, but changes remain subject to least privilege. Unknown groups grant nothing. A SCIM user becoming inactive triggers membership deactivation and the complete revocation workflow; deleting the directory record should not destroy audit evidence. Handle duplicate and out-of-order delivery through version checks, idempotency keys, and monotonic state rules so an older “active” update cannot undo a newer deactivation.

SCIM automates lifecycle signals; it does not replace OIDC authentication, Workboard authorization, or access-path enforcement. Monitor provisioning failures and expose actionable tenant-scoped status without leaking another tenant’s directory data.

Revocation removes future service access that was previously granted. Because a Workboard grant can be represented in memberships, sessions, tokens, keys, caches, live connections, and leased jobs, revocation is an idempotent fan-out workflow with observable completion—not one database update and not an instant universal guarantee.

Start by setting the relevant membership to revoked or inactive in the authoritative store. Every authorization decision that consults that source now denies, while cached decisions and already-running work remain explicit revocation legs until invalidated. Emit a RevocationEvent carrying the principal, tenant, affected membership IDs, server sessions, access and refresh tokens, API keys, cache namespaces, websocket connections, background leases, start time, completion time, and residualAccessUntil. completedAt remains empty until every required leg reaches a terminal result; residualAccessUntil bounds only future access through Workboard-controlled services, not possession of previously delivered data.

Each consumer performs its leg:

• Terminate server sessions and rotate or invalidate session families.
• Revoke refresh tokens and their authorization grants so no new access tokens can be minted.
• Expire, introspect, or denylist access tokens according to their format and the chosen security/availability trade-off.
• Disable human and service API keys, including derived keys and automation credentials.
• Evict or version subject, tenant, resource, permission, CDN, and capability-link caches; rotate the capability itself when unlisted access is being revoked.
• Close active websocket connections and require fresh authentication and authorization on reconnect.
• Cancel background leases, exports, scheduled jobs, and queued work; reauthorize before any retry.

Make consumers idempotent because events may be delivered more than once. Record per-leg attempt, result, timestamp, and error, retry transient failures within a bound, and escalate incomplete critical legs. A completed event means the defined controls reached their denial conditions; it does not mean information already copied outside Workboard ceased to exist.

A service-level objective (SLO) is a measurable reliability target over a defined time window. A revocation SLO states how quickly each controllable access mechanism must deny after the authoritative revocation start, making “access removed” testable instead of rhetorical.

Define separate targets rather than one vague number. For example, new API and page decisions might deny within 10 seconds at the 99th percentile; server sessions, refresh tokens, API keys, caches, websockets, and job leases within 60 seconds; self-contained access tokens no later than their five-minute expiry unless the risk tier requires online introspection or a denylist. The real targets depend on Workboard’s threat model and system capabilities, but they must be explicit before testing.

Build a test that starts an active session, access/refresh tokens, API key, warmed cache entry, websocket subscription, and leased export job for the same principal. Record startedAt, revoke the membership, and continuously attempt SSR, API reads and writes, discovery, export download, blob access, preview, cached delivery, subscription messages, refresh, API-key calls, and job completion. Capture the first uniform denial timestamp for each leg and compare it with its objective. One run proves that the fan-out is wired; a percentile claim requires repeated trials over a named window and representative load, including failure and retry conditions.

Leg	Denial proof	Honest residual limit
Membership and new decisions	Authoritative state and API denial	Replicas may have bounded propagation delay
Server session	Cookie no longer maps to an active session	Already rendered pages remain in browser memory
Refresh token	Refresh fails and family is marked revoked	Previously minted access token is separate
Access token	Introspection/denylist denies or expiry passes	Self-contained token may work until expiry
API key	All key IDs and descendants deny	External copies of returned data remain
Cache/CDN	Old variant unreachable after version/purge	A client may have stored a prior response
Websocket	Connection closes; reconnect denies	A received message cannot be recalled
Background lease	Work stops before publish; retry denies	Completed prior export may already be downloaded

Do not claim retroactive erasure. Offline devices may retain synchronized todos, recipients may keep exports, browsers may cache content, and screenshots or copied text cannot be clawed back. Policy and contracts can govern handling of those copies, but the technical revocation promise is bounded future access to Workboard-controlled services within the measured SLO.

These primary standards define provisioning, token revocation and status, and zero-trust access decisions. Dates and status make their authority explicit; all links were accessed on 2026-07-26.

• IETF RFC 7644, SCIM Protocol — Proposed Standard from September 2015 for cross-domain identity provisioning; the RFC index records later updates, and the linked datatracker page is the authoritative status source; accessed 2026-07-26.
• IETF RFC 7009, OAuth 2.0 Token Revocation — Proposed Standard from August 2013 defining a token-revocation endpoint and related behavior; accessed 2026-07-26.
• IETF RFC 7662, OAuth 2.0 Token Introspection — Proposed Standard from October 2015 defining an online way to query token active state and metadata; accessed 2026-07-26.
• NIST SP 800-207, Zero Trust Architecture — final NIST publication from August 2020 emphasizing per-request access decisions rather than implicit trust from network location; accessed 2026-07-26.
• OWASP WebSocket Security Cheat Sheet — living official OWASP guidance for handshake authorization, session expiry, message controls, and connection lifecycle; accessed 2026-07-26.

Sharing is an authorization contract that must remain consistent across every representation of Workboard data. Revocation is the measured removal of future access through all controllable mechanisms, with explicit acknowledgement of tokens and copies that cannot disappear immediately.

• Public permits anonymous reading and discovery, while mutation still requires membership and role.
• Unlisted link possession permits reading but is not confidentiality; capability-style links need rotation.
• Organization requires current tenant membership; private requires active tenant membership plus an explicit board grant.
• Invitation and membership states prevent an email or stale token from becoming accidental active access.
• Every SSR, API, discovery, export, blob, preview, cache, job, and subscription path enforces the same fail-closed policy.
• SCIM automates tenant-scoped user and group lifecycle but does not replace authentication or authorization.
• Revocation fans out to memberships, sessions, tokens, keys, caches, websockets, and leases, with per-leg evidence.
• Self-contained tokens, offline data, exports, browser memory, and screenshots impose residual limits that must be stated plainly.

Use this checklist to review Workboard’s sharing and removal controls before enabling enterprise collaboration. A checked item should have policy tests and observable denial evidence, not only a user-interface setting.

• [ ] Public, unlisted, organization, and private modes match the exact read, discovery, and mutation semantics.
• [ ] Unknown or missing visibility, tenant, membership, capability, or policy version denies by default.
• [ ] Invitations bind a verified principal to a tenant and follow an auditable state machine.
• [ ] Viewer, editor, owner, board-grant, service-account, and API-key permissions remain least privilege and resource-scoped.
• [ ] SSR, API, list/search, export, blob, preview, CDN/cache, job, and subscription paths share policy tests.
• [ ] SCIM clients are tenant-bound, idempotent, version-aware, and unable to reactivate a newer deactivation with stale data.
• [ ] Revocation deactivates membership first and covers sessions, refresh/access tokens, API keys, caches, websockets, and leases.
• [ ] Each revocation leg has a target, start timestamp, denial timestamp, percentile measurement, and escalation path.
• [ ] Public and unlisted limitations are explicit: person-specific anonymous public access cannot be revoked, and unlisted revocation rotates the capability and invalidates caches.
• [ ] Reconnects, retries, exports, and blob downloads reauthorize at the relevant execution seam.
• [ ] Documentation states the remaining access window for self-contained tokens and the irreversibility of offline copies, exports, and screenshots.