How should teams model public access in a relationship-based authorization system without creating a separate all-users construct?

Teams should represent public access as a relation that supports a wildcard subject type, so the permission graph can treat any subject of that type as eligible. This keeps the schema expressive, preserves type safety, and avoids the scaling and maintenance burden of creating one relationship per user or inventing a special public-only entity.

Modeling public access as a wildcard relation

In a relationship-based authorization model, public access works best as a first-class relationship pattern, not as a special exception bolted onto the schema. The key design choice is to allow the permission graph to accept a wildcard subject type, so “any subject of this type” can satisfy the relation without enumerating users or inventing a separate public entity. That keeps the model compact and predictable.

This approach preserves the same evaluation path used for ordinary relationships, which matters because authorization logic stays uniform. A request still resolves through the graph, but one edge can represent openness to an entire subject class instead of binding access to a long list of principals. For systems that already rely on relationship tuples, that uniformity is often the cleanest way to express public visibility without weakening the schema.

It also avoids the operational burden of scaling a public grant as a synthetic principal. If every new user, service, or account must be added to a pseudo “all users” construct, the model becomes noisy, harder to inspect, and easier to misuse. A wildcard subject type expresses the same business intent with less administrative overhead and less room for stale or orphaned membership logic.

Why this preserves type safety and graph clarity

Type safety is the main reason to model public access as a relation instead of an ad hoc bypass. In a typed graph, the schema can still constrain which subject kinds are allowed to participate, while the wildcard simply broadens eligibility within that type. That lets teams preserve compile-time or validation-time guarantees about what can be related, rather than dropping into an unstructured “public means anything goes” pattern.

Graph clarity matters just as much. A separate all-users construct often becomes a hidden dependency that is treated like infrastructure rather than authorization data. By contrast, a wildcard relation makes the public rule explicit at the same abstraction level as other permissions, which improves reviewability, reasoning, and policy maintenance. Teams can inspect the graph and understand that the openness is intentional, not an artifact of bulk membership management.

Where this is implemented well, the schema remains expressive enough to distinguish between truly public access and broader internal sharing. That distinction is important because not every widely shared resource should be modeled as public. The wildcard pattern should represent a deliberate authorization choice, not a shortcut for missing audience modeling. For teams designing the underlying policy language, a reference such as OWASP ASVS is useful for keeping access control semantics explicit and testable, even though the concrete modeling choice here is graph-based.

Risk and Threat Considerations

Public access is easy to over-broaden when teams model it as a convenience feature instead of a deliberate authorization state. The main risk is accidental exposure, where a wildcard relation is applied too widely, reused in the wrong context, or made difficult to distinguish from internal sharing. A second risk is governance drift, where a synthetic all-users entity accumulates ambiguous membership rules and obscures what is actually public.

Failure mechanism: The model loses precision when openness is represented indirectly, because administrators, reviewers, or automation may treat the public construct as a normal principal and extend it beyond the intended subject class. That can turn a narrowly scoped public rule into a broad access path that is hard to audit or revoke.

Impact: Mis-modeled public access can expose data, APIs, or content to more readers than intended, and it can make later entitlement reviews unreliable because the graph no longer clearly distinguishes public availability from named principal access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	The question centers on modeling and managing who can access resources.
Recommendation — Standardize how public relations are represented so access rules remain reviewable and consistent.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	The model affects how authorization decisions are expressed and enforced.
Recommendation — Apply access-control governance so public exposure remains intentional and auditable.

Practitioner Guidance

What to verify: Confirm that the wildcard relation is restricted to the intended subject type and that the evaluator cannot interpret it as a generic bypass for all authorization checks. Public should be a specific policy state, not a fallback for missing principal data.

Common mistake: Do not model public by creating a pseudo-group that behaves like a real audience. That pattern is harder to reason about during code review, makes policy diffs noisier, and increases the chance that later automation will inherit the wrong access semantics.

What good looks like: A reviewer can see one explicit public relation in the schema, trace how it resolves in the graph, and distinguish it cleanly from private or role-bound access without having to inspect hidden membership logic.

Practitioner takeaway: Treat public access as an explicit authorization relation with constrained wildcard eligibility, because the safest public model is the one that stays simple enough to audit without inventing a special identity for everyone.