Extending SecurityV0 with SCIM and Veza OAA

SecurityV0 baseline data model and intended use

What SecurityV0 is trying to model

SecurityV0 is specified (in the provided design docs) as an “Autonomous Execution Exposure Management” platform that treats execution authority as a first-class, cross-system graph problem: which identities (especially non-human/autonomous identities) can execute actions against what resources, through what authentication links, and how that authority drifts over time (ownership decay, scope expansion, persistent dormant privilege). fileciteturn0file0

A core architectural constraint set makes the data model unusually “forensic” compared with many identity catalogs:

• deterministic detections (no probabilistic scoring),
• read-only toward source systems,
• explainable “walkable” findings,
• temporal tracking of graph change,
• evidence-grade artifacts. fileciteturn0file0

These constraints matter directly when considering SCIM and OAA: SCIM is often used for provisioning (write operations), while SecurityV0 is explicitly described as read-only with respect to source systems; and OAA is optimized for publishing authorization snapshots into a catalog, while SecurityV0 additionally requires change history plus evidence packaging. fileciteturn0file0 citeturn24view0turn24view2

Core entity types

SecurityV0 is defined (status “Draft”) with a bounded set of core entities intended to compose an execution/authority graph:

• Identity (emphasis on autonomous/non-human identities as primary subjects),
• Owner (human/team/business-unit accountability),
• Role, Permission, Resource, Credential,
• Finding (deterministic triggers such as orphaned ownership, scope drift),
• Evidence Pack (sealed/immutable package of supporting graph facts). fileciteturn0file2

From a modeling standpoint, SecurityV0 is already “graph-native”: it defines explicit relationship types (e.g., Identity→Role, Role→Permission, Permission→Resource) and explicitly models cross-system authentication chains so that execution paths can traverse system boundaries (e.g., Identity A authenticates into Identity B). fileciteturn0file2

Core relationships and execution paths

SecurityV0’s relationship vocabulary is designed to support both “configured authority” and “observed execution,” including (among others) ownership assignment, role assignment, permission granting, permission scoping to resources, credential binding, cross-system authentication, and execution evidence linking an identity to a resource. This structure enables materialized execution paths (multi-hop traversals such as Identity→Role→Permission→Resource, plus cross-system hops through authentication links). fileciteturn0file2 fileciteturn0file1

Ingestion and storage architecture that shapes the data model

Two design choices are especially relevant when evaluating SCIM/OAA-style extensions:

1. Connector-centric normalization pipeline. The connector framework decomposes ingestion into Extract→Transform→Diff→Load, producing a database-agnostic normalized graph. The docs explicitly cite entity["company","Veza","identity security company"] OAA’s “extract→transform→load” pattern as an influence, while emphasizing SecurityV0’s differentiator: modeling execution paths and their temporal drift. fileciteturn0file3

2. Temporal persistence and eventing. The database design (Draft) uses a MongoDB-centered schema with explicit constructs for current state, historical versions/snapshots, event logging, materialized paths, and tenant scoping. fileciteturn0file1

Because the model is explicitly labeled “Draft,” it should be treated as an evolvable baseline; however, the entity/relationship vocabulary and temporal intent are clear enough to support a rigorous mapping exercise. fileciteturn0file2 fileciteturn0file0

SCIM specification analysis for identity provisioning and schema extension

What SCIM standardizes

SCIM is standardized by the entity["organization","Internet Engineering Task Force","standards body"] as a suite: RFC 7643 defines the core schema and extension model, RFC 7644 defines the HTTP protocol, and RFC 7642 provides definitions, concepts, actors, triggers, and use-case framing. citeturn7view0turn12view0turn7view2

RFC 7644 frames SCIM as an HTTP-based protocol that supports creation, modification, retrieval, and discovery of identity resources (notably Users and Groups), including custom resources and schema extensions. citeturn12view0turn15view0

Identity provisioning patterns and lifecycle triggers

RFC 7642 explicitly models provisioning as being initiated by “triggers” (joiner/mover/leaver-style business events, plus SSO-triggered flows) that drive CRUD operations. citeturn23view0turn23view3
This matters for SecurityV0 because many SecurityV0 findings (orphaned ownership, dormant authority) are conceptually “triggered” by state transitions that are similar to SCIM’s joiner/mover/leaver framing, even if SecurityV0 remains read-only and focuses on detection rather than execution. fileciteturn0file2 citeturn23view0

Schema definitions and core resources

RFC 7643 provides the schema model and defines the core resource schemas for:

• User (urn:ietf:params:scim:schemas:core:2.0:User)
• Group (urn:ietf:params:scim:schemas:core:2.0:Group) and the widely used Enterprise User extension (urn:ietf:params:scim:schemas:extension:enterprise:2.0:User). citeturn7view4turn14view2

Two SCIM details are particularly relevant when mapping into SecurityV0:

• Group membership semantics. In the User schema, the groups attribute is readOnly, and membership changes “MUST be applied via the Group Resource.” citeturn27view3
  In the Group schema, members is the multi-valued attribute whose value is a referenced resource id, with $ref pointing to the member resource; nested groups are explicitly contemplated. citeturn14view2turn14view4

• Roles/entitlements exist but are intentionally underspecified. The User schema defines multi-valued entitlements and roles attributes, but does not standardize vocabulary/syntax and explicitly avoids defining an authorization model. citeturn27view4
  This is a crucial constraint: SCIM can carry role/entitlement-like labels, but it is not an authorization graph specification.

Extension mechanisms

SCIM’s extension model is one of its strongest ideas for SecurityV0 to borrow.

RFC 7643 allows new resource types and additive extensions:

• New Resource Types can be defined; each resource type defines a name, endpoint, base schema, and registered schema extensions. citeturn14view1
• Extensions are additive (no inheritance model). The schemas attribute MUST contain the base schema URI and MAY include extension schema URIs; extension URIs act as JSON “containers” to namespace extension attributes. citeturn14view1turn14view3
• SCIM schema URIs and server-related schema URIs are managed in an IANA registry, which provides a stable “namespacing discipline” for extensions beyond any single vendor. citeturn7view4

For SecurityV0, the SCIM extension pattern is directly applicable to heterogeneous-source normalization: keep a stable core schema while allowing source/provider-specific extensions that remain machine-discoverable and non-colliding.

Protocol, discovery, and operational semantics

SCIM’s protocol standardizes both data-plane and control-plane behaviors:

• Well-known endpoints and HTTP methods. Users map to /Users, groups to /Groups, and SCIM standardizes GET/POST/PUT/PATCH/DELETE semantics. citeturn12view0turn15view2
• Discovery endpoints. SCIM defines three discovery endpoints: /ServiceProviderConfig, /Schemas, and /ResourceTypes. They advertise supported features and schemas and help clients discover endpoints (especially for custom resource types). citeturn13view0turn12view0
• Query model. RFC 7644 defines filtering, sorting, and pagination parameters, and it explicitly warns that pagination is not stateful and clients must handle inconsistent results. citeturn17view0turn18view2
• PATCH semantics. SCIM PATCH is based on JSON Patch, but SCIM constrains array semantics and uses add/remove/replace operations. citeturn15view4
• Versioning and concurrency control hooks. SCIM uses resource meta.version aligned to HTTP ETags, and supports If-Match / If-None-Match patterns. citeturn14view0turn13view0turn15view2

Scalability update: cursor pagination

In October 2025, RFC 9865 updated SCIM (7643/7644) by standardizing cursor-based pagination (cursor query parameter and nextCursor/previousCursor response attributes). citeturn19view0turn20view1
The RFC explicitly motivates this as a way to avoid inefficient “pagination translation” when a server sits atop cursor-native backends, and it defines behavioral requirements (e.g., nextCursor must be returned on all pages except the last). citeturn19view0turn20view2

For SecurityV0—whose multi-tenant graph can become very large—RFC 9865 is a timely source of design guidance for scalable, interoperable listing/query endpoints that don’t rely on fragile index-based pagination. citeturn18view2turn20view2

Veza OAA analysis for authorization modeling and integration workflows

What OAA is and what it optimizes for

entity["company","Veza","identity security company"] describes OAA (Open Authorization API) in its developer documentation as a mechanism “to publish information about identities, authorization, and resources” into the Veza entity catalog so that custom or unsupported applications become available for search, workflows, access reviews, and lifecycle management. citeturn24view0

OAA is explicitly positioned as a publisher API + standardized JSON schema approach: the integrator extracts metadata from the target system, generates an OAA payload conforming to a template schema, and publishes it via REST APIs or SDKs. citeturn1view1turn24view1

Key concepts: providers, data sources, templates

OAA makes two separation-of-concerns choices that are highly relevant when extending SecurityV0:

• Provider vs data source. Before uploading metadata, an integrator creates a custom provider and at least one data source; the provider represents the application type and determines the template used by the data sources, while the payload is pushed to a specific data source and overwrites/updates that source’s existing data. citeturn5view2turn5view0
• Template-driven modeling. OAA templates (“Custom Application,” “Custom Identity Provider,” “Custom HRIS Provider,” etc.) define the canonical structure for payloads; built-in integrations have fixed schemas, but OAA integrations adopt these flexible templates. citeturn24view0turn5view3

This “provider/data source/template” triad is not just an API shape: it enforces stable names, repeatable runs, and a clear boundary between integration identity (provider/data source) and payload content—useful for multi-instance enterprise environments. citeturn5view2

Authorization modeling capabilities

OAA’s Custom Application template (as documented) supports modeling a common authorization graph pattern:

• Local users and local groups,
• Local roles (collections of permissions),
• Resources with sub-resources (hierarchies),
• Permissions mapped to “canonical permissions,”
• Assignments of users/groups/IdP identities to roles/permissions scoped to resources or the whole application. citeturn24view4turn2view1

The developer “Modeling Users, Permissions, and Roles” guidance highlights two modeling features that matter for SecurityV0:

• Local vs federated identity correlation. OAA recommends representing system users as “local_user” objects even in SSO-enabled apps because local users can carry activity/timestamps and can reference a federated identity, creating graph links across services. citeturn2view1
• Canonical permission mapping. OAA requires mapping granular provider permissions into canonical categories (described as C/R/U/D-like). This supports cross-system querying (“who can delete buckets / merge code / read regulated data?”). citeturn2view1

API design and operational behavior

OAA’s push API and operations docs show a pragmatic integration design:

• REST API for provider and datasource management (create provider, create datasource, push payload, delete datasource). citeturn5view0turn24view3
• Payload push characteristics. The “Push Custom Provider Datasource” operation supports large payloads, optional gzip compression, and documentation calls out a maximum body size and escaping requirements. citeturn24view3
• Authentication. Veza’s documentation describes using API keys as OAuth 2.0 Bearer tokens for API calls. citeturn4search1

Full push vs incremental updates

OAA’s connector requirements and reference docs define a default operational model:

• Default behavior is full extraction + full payload push, overwriting the datasource’s information each run. citeturn4search12turn24view1
• Incremental updates are optional; they are declared via "incremental_change": true and per-entity operation values such as add, modify, delete, plus resource/tag-specific delta operations. citeturn24view2turn3view0

This aligns closely with SecurityV0’s Extract→Transform→Diff→Load pipeline: both ecosystems separate extraction from normalization, and both admit incremental patterns while acknowledging that full snapshots are often simpler unless the source system can reliably provide deltas. fileciteturn0file3 citeturn24view2

OAA + SCIM integration point (highly relevant)

Veza’s documentation explicitly treats SCIM and OAA as complementary:

• OAA is used for data gathering and authorization modeling.
• SCIM endpoints are used for user/group lifecycle management (provisioning/deprovisioning, group membership management). citeturn24view5

The “OAA with SCIM Lifecycle Management” page lists supported actions such as syncing identities, managing group relationships, de-provisioning users by setting active=false, deleting identities, and creating entitlements (creating groups in the target application). citeturn24view5

For SecurityV0, this is a concrete industry example of a two-part architecture: an authorization visibility model + a provisioning protocol, kept distinct but linked by shared identity/group concepts.

Comparative analysis of SCIM vs OAA for security and identity data modeling

Where they strongly overlap

Both SCIM and OAA encode a set of design ideas that translate well into SecurityV0’s needs:

• Interoperable JSON over HTTP. SCIM standardizes a JSON media type and REST behaviors for identity resources; OAA publishes standardized JSON payloads over REST. citeturn12view0turn5view0
• Discovery and schema discipline. SCIM provides /Schemas and /ResourceTypes as a formal self-description mechanism; OAA provides template schemas and documented expectations that act as a practical (though vendor-scoped) schema contract. citeturn13view0turn24view4
• Identity/group centrality. SCIM’s core resources are Users and Groups; OAA’s core application modeling uses users and groups as the primary assignment subjects. citeturn12view0turn24view4

Where they fundamentally differ (and why that matters to SecurityV0)

SCIM and OAA optimize for different problems:

• SCIM is lifecycle/provisioning-first. SCIM’s protocol model centers on CRUD operations against identity resources, and RFC 7642 explicitly frames “triggers” that initiate those CRUD flows. citeturn23view0turn12view0
  SecurityV0, by contrast, is described as read-only toward source systems and oriented toward detection + evidence rather than executing lifecycle change. fileciteturn0file0

• OAA is authorization visibility-first. OAA is explicitly about publishing identities/resources/permissions and their relationships to enable authorization graph visibility and governance workflows. citeturn24view0turn2view1
  This is closer to SecurityV0’s graph goals, but SecurityV0’s differentiator is its explicit modeling of execution paths and temporal drift plus evidence-grade output artifacts. fileciteturn0file3 fileciteturn0file2

• Authorization semantics. SCIM deliberately avoids defining an authorization model; even where it provides groups, roles, and entitlements, it leaves semantics to providers and clients. citeturn27view4
  OAA requires canonical permission mapping and explicitly models roles/permissions/resources and assignments, yielding a more opinionated authorization model. citeturn2view1turn24view4

Why they are complementary for extending SecurityV0

The Veza pattern (OAA for modeling + SCIM for lifecycle write-back) demonstrates a practical division of labor that suits SecurityV0’s constraints:

• Adopt OAA-like patterns to represent and ingest authorization structure (roles, permissions, resource hierarchies, identity correlation).
• Adopt SCIM-like patterns to standardize identity and group schemas, schema extension namespacing, and discovery/query semantics—optionally including a SCIM-compatible interface for ingestion or interoperability—without necessarily adopting SCIM “as a write-back mechanism” inside the core SecurityV0 platform. citeturn24view5turn14view1turn24view2 fileciteturn0file0

Extension points in SecurityV0 for integrating SCIM and OAA concepts

Identity and owner modeling: align with SCIM User + Enterprise extension

SecurityV0 already distinguishes Identity (including autonomous identities) and Owner (accountability entities). fileciteturn0file2
SCIM provides a mature vocabulary for human identity attributes and organizational context via the Enterprise User extension (department, costCenter, manager, etc.). citeturn14view2turn14view3

Concrete extension point:

• Add a SCIM-aligned attribute namespace for human owners and (optionally) human identities, including SCIM-like externalId and enterprise attributes, while keeping SecurityV0’s execution/authority semantics intact. citeturn14view2turn14view3 fileciteturn0file2

Group membership and organizational hierarchy: align with SCIM Group semantics

SecurityV0 needs group-like structures for:

• ownership hierarchies (Owner→Owner),
• membership relationships (Identity/Human→Role/Group),
• approval chains (where applicable). fileciteturn0file2

SCIM’s Group schema explicitly models members and contemplates nested groups; it also clarifies that user-side groups is readOnly and membership changes should be applied through Group resources. citeturn14view2turn27view3
Even if SecurityV0 is not executing membership changes, this SCIM semantics is useful for representing membership and reconciling authoritative group state.

Concrete extension point:

• Make “group-like” entities first-class in the SecurityV0 graph either by (a) introducing a distinct Group entity type, or (b) formally profiling a subset of SecurityV0 “Owner” and “Role” as SCIM Group-compatible. This is primarily a schema contract decision for interoperability. fileciteturn0file2 citeturn14view2turn27view3

Schema and extension strategy: adopt SCIM’s namespaced “schemas” container idea

SecurityV0 ingests heterogeneous source systems and already normalizes into a common graph vocabulary, but the long-term challenge is to maintain:

• a stable core schema,
• plus source-specific or domain-specific enrichments that don’t pollute the core. fileciteturn0file3

SCIM’s additive extension model—base schema plus URN-namespaced extension containers selected via the schemas list—solves precisely this problem. citeturn14view1turn7view4

Concrete extension point:

• Introduce a schemas (or equivalent) field on SecurityV0 entities and define a policy:
  • one SecurityV0 base schema per entity type,
  • optional extension containers for source-specific fields (e.g., urn:securityv0:schemas:extension:github:1.0:Identity), following SCIM’s “extension URI as JSON container” discipline. citeturn14view1turn12view0 fileciteturn0file2

API interoperability: SCIM-style discovery + query semantics for SecurityV0’s query layer

SecurityV0’s architecture describes a tenant-scoped API/query layer and emphasizes explainable evidence delivery. fileciteturn0file0
SCIM provides a battle-tested interoperability layer for resource discovery and query behaviors:

• /ServiceProviderConfig, /Schemas, /ResourceTypes advertise capabilities. citeturn13view0
• Standard filters, sorting, and pagination are defined; cursor pagination is now standardized via RFC 9865. citeturn18view2turn20view2

Concrete extension point:

• Expose a SCIM-inspired (or SCIM-compatible) discovery surface for SecurityV0’s entity types and supported query capabilities—especially if SecurityV0 aims to be a system-of-record that other governance tools integrate with programmatically. citeturn13view0turn17view0turn20view2 fileciteturn0file0

Authorization modeling ingestion: OAA-compatible payload as an additional connector format

SecurityV0 already defines a connector contract producing a normalized graph and explicitly cites OAA as an influence. fileciteturn0file3
OAA defines practical modeling constructs (local users/groups/roles/resources, permission canonicalization, identity correlation) and a mature push-based API pattern (provider/datasource registration, payload push). citeturn5view0turn24view4turn2view1

Concrete extension point:

• Add an OAA ingestion adapter that accepts OAA “Custom Application” payloads and translates them into SecurityV0 normalized nodes/edges (Identity/Role/Permission/Resource + relationships), then runs SecurityV0’s diff + temporal machinery to produce drift-aware findings and evidence packs. citeturn24view4turn24view2 fileciteturn0file1turn0file2

Incremental change capture: align OAA incremental updates with SecurityV0 diff/event model

SecurityV0’s connector architecture includes an explicit Diff Engine, temporal markers, and canonical events. fileciteturn0file3 fileciteturn0file1
OAA defines an incremental update contract (incremental_change, per-entity operation) as an alternative to full payload replacement. citeturn24view2

Concrete extension point:

• Allow connectors (including OAA-adapter connectors) to optionally submit typed deltas using OAA-like per-entity operation semantics, while keeping the “full snapshot” path as the default. citeturn24view2turn4search12 fileciteturn0file3

Practical recommendations, integration patterns, and artifacts

Recommended design patterns for extending SecurityV0

Canonical core + namespaced extensions (SCIM-inspired)

Adopt SCIM’s additive extension discipline as a first-class SecurityV0 modeling pattern:

• Keep SecurityV0’s core entity schemas minimal and stable.
• Move source/provider-specific attributes into URN-namespaced extension containers.
• Provide schema discovery metadata that tells clients which extensions are present. citeturn14view1turn13view0 fileciteturn0file2

This directly supports interoperability (clients can ignore unknown extensions), while preserving SecurityV0’s deterministic and explainable posture because “what was observed” can be stored verbatim in well-scoped namespaces. fileciteturn0file0 citeturn15view0

Provider/data-source boundary (OAA-inspired) for multi-instance systems

Even if SecurityV0 keeps its “connectorId/sourceSystem” framing, add an explicit logical concept akin to OAA’s:

• Provider: the technology type (e.g., “Git hosting platform,” “ITSM platform”)
• Data source: the tenant/instance boundary (org, account, workspace) citeturn5view2turn5view0

This makes multi-instance governance cleaner and aligns with SCIM’s multi-tenancy considerations (tenants can be represented via URL prefixes/subdomains/headers). citeturn13view0turn13view0 fileciteturn0file1

Hybrid snapshot + delta ingestion

Implement a two-mode ingestion contract that mirrors both OAA and SCIM scalability learnings:

• Default: full snapshot ingestion (simpler, aligned with OAA’s default overwrite model). citeturn4search12
• Optional: delta ingestion for sources with audit logs or change feeds, using:
  • OAA-like per-entity operations (add/modify/delete) for push sources, citeturn24view2
  • SCIM-like ETag/version semantics to guard concurrency and reconcile state, citeturn14view0turn13view0
  • cursor-based pagination (RFC 9865) for large enumerations. citeturn20view2

This preserves SecurityV0’s temporal drift detection goals and improves scalability without forcing every connector to implement complex delta logic. fileciteturn0file3 citeturn19view0turn24view2

Permission/action taxonomy bridging

SecurityV0 defines a normalized action vocabulary that extends beyond CRUD into execution/admin/delegation semantics. fileciteturn0file3
OAA requires mapping raw permissions into canonical permissions (described as CRUD-like) to enable cross-system search. citeturn2view1

A practical extension is to add a two-axis classification:

1. SecurityV0’s existing action categories (create/read/update/delete/execute/admin/delegate), and
2. an OAA-like “canonical permission” categorization (data vs metadata; read vs write vs delete) where applicable.

This permits interoperability with OAA-style ecosystems while keeping SecurityV0’s execution-path emphasis intact. citeturn2view1 fileciteturn0file2

SCIM as an interoperability surface, not necessarily a write-back engine

Because SecurityV0 is specified as read-only toward source systems, the safest SCIM adoption pattern is:

• Use SCIM schemas/extension discipline + SCIM discovery/query patterns for interoperable identity/group representation, and
• Keep provisioning/write-back (if desired) as an externalized workflow executed by another system, similar to Veza’s explicit split (OAA models access, SCIM performs provisioning/deprovisioning). fileciteturn0file0 citeturn24view5

Integration architecture diagrams

Proposed ingestion and interoperability architecture

This diagram intentionally mirrors OAA’s “extract/transform/upload” flow (payload publishing) while preserving SecurityV0’s explicit Diff/Temporal/Evidence stages. citeturn9view0turn10view1turn24view2 fileciteturn0file3turn0file1

Entity mapping sketch between SCIM, OAA, and SecurityV0

The mapping reflects an important asymmetry: SCIM is strongest for identity/group shape + lifecycle semantics, while OAA is stronger for permissions/resources/assignments as an authorization model. citeturn27view4turn24view4turn2view1 fileciteturn0file2turn0file3

Summary matrix of SecurityV0 vs SCIM vs OAA

The table below summarizes key overlaps/gaps based on the SecurityV0 design docs, the SCIM RFCs, and Veza’s OAA documentation. fileciteturn0file2turn0file1 citeturn13view0turn14view1turn24view4turn24view2

Modeling dimension	SecurityV0 (baseline)	SCIM (RFC 7643/7644/7642 + RFC 9865)	OAA (Veza docs)
Primary goal	Execution authority + drift detection + evidence-grade findings	Interoperable identity provisioning and management	Publish authorization metadata for visibility/governance
Core entities	Identity, Owner, Role, Permission, Resource, Credential, Finding, Evidence Pack	User, Group, plus extensible custom resource types	Applications, local users/groups/roles, resources/sub-resources, permissions, identity↔permission assignments
Cross-system identity correlation	Explicit cross-system authentication relationships and execution paths	Out of scope; focuses on resource identity representations	Explicit support for linking local users to external identities (IdP correlation)
Authorization model	Explicit Role→Permission→Resource, plus execution paths	No explicit authorization model; groups/roles/entitlements exist but semantics are provider-defined	Explicit: permissions/roles scoped to resources; canonical permission mapping
Extension mechanism	Draft model; connector normalization suggests extensibility	Strong URN-based schema + additive extension containers; IANA registry discipline	Template-based schemas; custom properties/tags; vendor ecosystem conventions
Discovery / schema introspection	Draft query surface; not SCIM-like by default	/ServiceProviderConfig, /Schemas, /ResourceTypes	Documentation + template references; provider/data-source registration
Query & pagination	Draft; database design anticipates large graphs	Standard filter/sort + index pagination; RFC 9865 cursor pagination adds cursor/nextCursor	Primarily push-based; operational APIs for push/management; payload size guidance
Versioning / concurrency	Temporal history and events; evidence packs sealed/immutable	ETag/meta.version alignment; If-Match/If-None-Match patterns	Full push overwrite is default; incremental updates via explicit per-entity operations
Best fit contribution to SecurityV0	Temporal/evidence-centric graph model	Namespaced schema extensions + discovery/query semantics for identities/groups	Authorization modeling templates + provider/datasource operational pattern

Primary sources (URLs)

The report’s primary citations are embedded inline; the URLs below are included to satisfy the request for explicit “links” in one place.

SCIM (IETF / RFC Editor / IANA)
- RFC 7642 (SCIM definitions, overview, concepts, requirements): https://datatracker.ietf.org/doc/html/rfc7642
- RFC 7643 (SCIM core schema + extension model): https://datatracker.ietf.org/doc/html/rfc7643
- RFC 7644 (SCIM protocol): https://datatracker.ietf.org/doc/html/rfc7644
- RFC 9865 (SCIM cursor-based pagination; updates 7643/7644): https://datatracker.ietf.org/doc/rfc9865/
- IANA SCIM Schema URI registry: https://www.iana.org/assignments/scim/scim.xhtml

Veza OAA (official developer docs + official materials)
- Veza Developers: Open Authorization API overview: https://developer.veza.com/oaa/guide/oaa
- Veza Developers: Getting Started with OAA: https://developer.veza.com/oaa/guide/getting-started
- Veza Developers: Providers, Data Sources, Names and Types: https://developer.veza.com/oaa/guide/core-concepts/providers-apps-datasources
- Veza Developers: Custom Application template reference: https://developer.veza.com/oaa/reference/templates/custom-application
- Veza Developers: Modeling Users, Permissions, and Roles: https://developer.veza.com/oaa/guide/core-concepts/modeling-users-permissions-and-roles
- Veza Developers: OAA Push API: https://developer.veza.com/oaa/reference/api/oaa-push-api
- Veza Developers: API operations reference: https://developer.veza.com/oaa/reference/api/operations
- Veza Developers: Incremental updates: https://developer.veza.com/oaa/reference/incremental-updates.html
- Veza Developers: OAA with SCIM Lifecycle Management: https://developer.veza.com/oaa/guide/core-concepts/oaa-scim.html
- Veza OAA solution brief PDF: https://veza.com/wp-content/uploads/2025/04/OAA-Veza-Mar-27-2025.pdf

---

Next Action

Status: adopted — shipped Findings incorporated into docs/architecture/01-data-model.md, 05-connectors.md, and associated ADRs. No further action required.