Glossary

The PACS primitive that grants a cardholder access to a defined set of readers, doors, areas, or floors — usually constrained by a schedule. Every enterprise PACS has this concept, but **every vendor names it differently**. Mapping the AE-side abstraction "Access Level" or "Access Area" to the right vendor primitive is one of the most common per-deployment configuration tasks. - **AE Guardian**: Access Area (in PIAM); Role (in legacy guides) - **Lenel OnGuard**: Cardholder Access Level — assigned to badges via Change Badge Access Levels - **Software House C·CURE 9000**: Clearance (`ACVSCore.Access.Clearance` table) — joined to Doors via ClearanceItem records - **AMAG Symmetry**: Access Group (`AccessGroupTable`); supports composition of Readers, Reader Groups, Floor Groups, Intrusion Areas - **Honeywell Pro-Watch**: Clearance (`CLEAR` table) — three flavors: Permanent, Timed, Temporary - **Honeywell Pro-Watch DTU REST**: ClearCode (REST API term for clearance) - **PACOM GMS**: Global Access Group (GAG) for area access + Floor Access Group (FAG) for elevators; both permanent and temporary variants - **Siemens SiPort**: Profile - **Genetec Security Center**: Cardholder Group or Access Rule - **Brivo Access**: Brivo Role (provisioned via UserRoleData with role.id) - **Avigilon ACM**: Role (`ROLE_NAME` / `ROLE_ACTIVE`)

• AE Access Area (Guardian); Role (legacy)
• lenel Cardholder Access Level
• ccure Clearance
• amag Access Group
• genetec Cardholder Group / Access Rule
• honeywell Clearance / ClearCode
• brivo Role
• avigilon Role
• siemens Profile
• pacom GAG (Global Access Group) / FAG (Floor Access Group)

A PACS security policy that prevents a cardholder from re-entering a controlled area (or exiting) without first having performed the opposite movement — typically used to stop badge sharing or piggybacking. **Hard APB** denies the re-entry attempt outright; **soft APB** logs the violation but admits the cardholder; **timed APB** allows re-entry only after a defined cooldown. AE Guardian doesn't enforce APB itself — it's a property of the PACS that AE provisions against. But Guardian must respect APB-related metadata when provisioning visitor badges, temporary access, and post-exit reactivations. Misconfigured APB is a frequent source of "I can't get back in" tickets at large enterprises. Implementation across vendors varies: CCURE 9000 supports site-level APB configuration in Clearances; Lenel OnGuard supports per-reader APB modes; AMAG implements APB through Reader Group configuration; PACOM's GAG/FAG access model can layer APB at the area or floor level.

• AE Anti-Passback (Guardian SOC Insights surfaces APB violations)

The physical or virtual artifact a cardholder presents at a reader to authenticate. In its most generic form this is a card with an embedded credential identifier (Wiegand bits, CHUID, smart-card cryptogram, etc.). In modern deployments the credential may instead live in an Apple Wallet, Google Wallet, or Samsung Wallet pass on the cardholder's phone, or in a TOTP/biometric template. AE Guardian uses **Asset** or **Card** as the canonical term; PACS vendors use a startling variety of names — Badge (Lenel, CCURE, AMAG, Honeywell), Token (Avigilon ACM), Credential (Brivo, SSG, modern REST APIs), Card (most legacy systems). Multi-vendor deployments must standardize the AE-side mapping so the same physical badge is represented consistently across all integrated systems. Within a single PACS, a cardholder typically has **one primary credential** plus zero or more secondary / temporary credentials (visitor badges, replacement cards during reissuance, mobile passes alongside physical cards).

• AE Asset / Card (in Guardian)
• lenel Badge (BADGEKEY-keyed; CARDNUMBER as wire identifier)
• ccure Badge (CHUID, CHUIDFormatID, CardNumber, FacilityCode)
• amag Card (CardInfoTable.CardNumberDisplay; supports 5 format types — SeiwgV1, SeiwgGSC2_1, SRSeries_10And12Digit, SRSeries_15Digit, Standard)
• genetec Credential
• honeywell Card (BADGE_CARD_ALL.CARDNO)
• brivo Badge (CardNumber + FacilityCode; e.g. 'Standard 26 Bit' format)
• avigilon Token (TokenInternalNumber, plus 9 boolean flags including TokenVIP, TokenTrace, TokenExtAccess)
• ssg Credential (mobile-first; "Card" in API)

The principal identity inside a Physical Access Control System (PACS). A cardholder is the person whose credentials (badges / cards / tokens / mobile passes) grant physical access at readers and doors. In AE Guardian, a cardholder corresponds to an **Identity** — the same person may also exist in an HR system (Workday, SAP HR), an IAM system (Okta, Entra), and one or more PACS simultaneously. Guardian reconciles the cardholder representation across all systems. Vendor terminology varies meaningfully — what AMAG calls a cardholder is what CCURE calls a Personnel, what Avigilon represents as an LDAP-style object with `cn` attribute, and what Lenel models in the OnGuard `PERSONID` schema.

• AE Identity (in Guardian); Cardholder (when scoped to a PACS context)
• lenel Cardholder (PERSONID-keyed in OnGuard)
• ccure Personnel (ObjectID-keyed in ACVSCore.Access.Personnel)
• amag Cardholder (CardHolderTable.EmployeeNumber-keyed)
• genetec Cardholder
• honeywell Cardholder (BADGE_ALL row)
• brivo User
• avigilon User Data (LDAP-style cn attribute)

A PACS time policy that overrides normal access during designated holiday dates. Every enterprise PACS supports holiday scheduling because access policies routinely differ on Christmas, New Year's, Eid, Lunar New Year, and customer-specific corporate holidays — usually denying access to most cardholders while allowing facilities and security staff through. AE Guardian provisions access against a PACS but generally doesn't author holiday schedules — those are configured by the customer's PACS administrator. However, AE-side reporting (audit reports, compliance attestations) must account for holiday-overridden behavior to avoid false-positive findings. Multi-region deployments add complexity: a holiday in one site may be a normal business day in another, and the PACS must support region-specific holiday calendars.

• AE Holiday Schedule (in Guardian time-policy model)

The discrete state transitions in an identity's lifecycle that AE Guardian must detect and respond to. Each HR system models them slightly differently, but the core set is consistent: - **Hire** — new employee starts; provision birthright access - **Rehire** — terminated employee returns; re-activate with prior access (or reset) - **Transfer** — employee moves to a new role / department / location; reconcile access (typically remove old + add new) - **Promotion / Demotion** — title and access change; usually access-additive but compensation-affecting - **Leave** — employee on extended leave; typically suspend access without termination - **Return from Leave** — re-activate access - **Termination** — employee departure; **deprovision all access immediately**, especially physical (badge deactivation at the PACS) before they leave the building - **Title Change / Manager Change / Location Change** — attribute changes that affect access via role-based policies HR systems publish these events on different cadences — Workday and SAP HR support both full reconciliation and delta event streams; SailPoint ([[sail-point-rest]]) exposes them via polled query on identity events; PeopleSoft requires Component-Interface-based extraction. **Termination is the most operationally critical event** — for security reasons, badge deactivation should happen within minutes of the HR system marking the employee as terminated. AE Guardian's polling interval on HR connectors is typically configured tightly (every 15-60 minutes) for this reason.

• sailpoint Identity lifecycle state changes via Public API events index
• workday Workday lifecycle events via Worker / Position business processes
• sap SAP HR PA infotype changes (IT0001, IT0002, IT0006, etc.)

The discipline of governing the **full identity lifecycle** at enterprise scale — including birthright provisioning (new hire automatically gets the right access on day one), access reviews (managers / data owners periodically certify who has access to what), Separation-of-Duties (SOD) policy enforcement (no single user should have conflicting roles), and joiner/mover/leaver workflow. IGA sits *above* the IAM directory layer (Okta, Entra ID, AD) — those systems hold identity records and authenticate users; IGA orchestrates the workflows around lifecycle changes and the recertification of access. The dominant IGA platforms in the Fortune 500 are **SailPoint** ([[sail-point-rest]]), Saviynt, and Oracle Identity Governance. In an AE Guardian deployment, IGA matters because **SailPoint is typically the upstream system of record for identity lifecycle**, and AE Guardian acts as the downstream PIAM consumer. SailPoint owns "is this user actively employed and entitled to access" — AE Guardian receives that signal and drives PACS / IAM / network provisioning accordingly.

• AE IGA upstream consumer for PIAM workflows
• sailpoint SailPoint Identity Security Cloud — dominant IGA platform

Workday's dedicated service-account pattern for API integrations. An **Integration System User (ISU)** is a Workday user account specifically created for machine-to-machine API access — distinct from human Workday users and exempt from password expiration policies that would otherwise break integrations. An ISU is paired with an **Integration System Security Group (ISSG)** that defines exactly which Workday data domains (Worker, Organization, Job Profile, Position, Compensation, etc.) the ISU can read or write. The principle of least privilege applies: each integration gets its own ISU with the minimum ISSG it needs. AE Guardian's [[workday-rest]] connector requires an ISU with read access to the Worker, Organization, Job Profile, Supervisory Organization, and (optionally) Position data domains. The Workday admin creates the ISU + ISSG; AE configures the ISU credentials in the connector's System Parameters. Equivalent patterns elsewhere: SAP service-account user (for [[sap-hr]]), PeopleSoft operator (for [[people-soft]]), API Client in ClearPass / Cisco ISE.

• workday ISU — Integration System User
• sap Service-account user (for SAP HR via RFC/BAPI)

An identity-provisioning pattern where the user account in the **destination** system is created **at first login** rather than provisioned in advance. The flow: user attempts to access the destination, the IdP authenticates them, the IdP asserts identity via [[saml]] or [[oidc]], the destination sees a never-before-seen user and provisions them on the fly based on the asserted attributes. JIT is attractive because it eliminates the "provisioning gap" — the period after a new hire where they have an HR record but not yet an account in every system they'll need. With JIT, the first login creates the account. **Limitation in the AE Guardian context:** the [[adfs-sso]] and other SSO connector guides explicitly state that users must be **pre-synced into the AE Guardian database before SSO will work**. AE Guardian does **not** support JIT provisioning at the SSO layer — assertions for unknown users fail. The intended pattern is: use the [[active-directory]] / [[okta]] / [[microsoft-entra-id]] connector to reconcile users into AE Guardian first, *then* enable SSO. This is a deliberate security stance — Guardian's PIAM workflows need to know about the user before the user can authenticate.

• AE Not supported at SSO layer — pre-sync required via provisioning connector

Microsoft's unified REST API for Microsoft 365 + Microsoft Entra ID + Azure services — accessed at `graph.microsoft.com`. The Graph API exposes users, groups, directory roles, licenses, mailboxes, OneDrive files, Teams, calendars, and dozens of other Microsoft cloud objects through a consistent OData-flavored REST interface. AE Guardian's [[microsoft-entra-id]] connector uses Graph API exclusively for all provisioning + reconciliation operations. The connector requires an **Entra app registration** with specific **Application Permissions** granted via admin consent: - `User.Read.All`, `User.ReadWrite.All` — user CRUD - `Group.Read.All`, `GroupMember.Read.All` — group + membership - `Directory.Read.All` — SKU / license info - `RoleManagement.Read.Directory` — directory roles - `User-LifeCycleInfo.ReadWrite.All` — hire/termination dates - `User.EnableDisableAccount.All` — lock/unlock accounts - `User.ManageIdentities.All` — external identities Microsoft Graph throttling limits vary by resource. Large reconciliation jobs honor `Retry-After` headers on HTTP 429 responses.

• AE Used by the microsoft-entra-id connector for all operations
• entra Microsoft Graph — the REST surface for Entra ID

Defines the credential type, artwork, metadata, and policy that apply to every pass issued under it. The issuer configures the template once; per-user issuance instantiates passes from it.

• Wavelynx Pass template config
• HID v2.2 Part Number
• HID v3.x Pass Template
• Apple UAP passTypeIdentifier
• Google Pass Class
• AE Card Template

The discipline of governing physical-access identities across an enterprise — typically employees, contractors, and long-tenured non-employees. PIAM is the umbrella term for what AE Guardian does: it consumes identity from HR (Workday, SAP HR), syncs entitlements from IAM (Okta, Entra ID), provisions access into one or more PACS, and reconciles drift between the systems. PIAM is distinct from but adjacent to: - **IAM** (Identity & Access Management) — logical/digital access (apps, networks, data) - **VIM** ([[vim]]) — short-lived visitor identities - **PACS** — the downstream physical access control system itself The "PI" in PIAM is the differentiator — physical access has different requirements than digital (real hardware revocation, badge re-issuance after loss, on-site badging at hire, off-boarding day-of-termination escort policies). AE Guardian's value proposition centers on automating PIAM at enterprise scale.

• AE PIAM (the Guardian platform's core discipline)
• lenel PIAM (Lenel OpenAccess exposes Cardholder + Cardholder Badge + Cardholder Access for the PIAM scope)
• ccure PIAM (CCURE 9000 Victor exposes Cardholder + Cardholder Badge + Cardholder Access for PIAM)

HID's update mechanism for already-provisioned passes. Applied via PATCH /passes/{passId} on the v3.x Credential Management API. PPPU simplified the older state machine by removing intermediate REQUESTED / ACCEPTED states and applies uniformly to Apple and Google Wallet.

• HID v3.x PPPU

The encrypted/signed bundle delivered from the issuer to the wallet platform during provisioning. Contains the credential's cryptographic material (wrapped per the wallet's key-wrapping spec), display fields (name, role, photo), and identifiers needed to instantiate the pass on-device.

• Wavelynx Provisioning bundle (JWS-signed)
• HID v3.x Pass payload
• Apple UAP provisioningBundle

The atomic unit of credential issuance — what gets added to a wallet when a user taps "Add to Wallet". Each vendor names this differently, and HID has two competing names depending on which API generation you read.

• HID v2.2 Mobile ID
• HID v3.x Pass
• Apple UAP Pass / provisioningBundle
• Google Pass
• AE Mobile Credential

A REST + JSON-based standard for **identity provisioning** between systems — defined in RFC 7643 (schema) and RFC 7644 (protocol). Where [[saml]] and [[oidc]] handle authentication, SCIM handles the create/update/delete operations on user and group records. SCIM 2.0 is the version in production use. The protocol defines a small set of resource types — Users and Groups — and operations (GET / POST / PUT / PATCH / DELETE) over them with a fixed URL pattern (`/Users`, `/Groups`, `/Users/{id}`). In the AE Guardian context, SCIM is the wire protocol the upstream IdP (Okta, Entra ID) uses when **pushing** provisioning into downstream applications — including, in some configurations, into AE Guardian itself. AE Guardian's own IAM connectors typically don't consume SCIM directly — they use vendor-native REST APIs (Microsoft Graph API for Entra, Workday REST for Workday) — but SCIM is the standard the customer's IdP-side admin will be familiar with.

• ISO RFC 7643 (schema) + RFC 7644 (protocol)
• okta SCIM 2.0 supported as a downstream-provisioning protocol
• entra SCIM 2.0 supported for outbound provisioning to applications

AlertEnterprise's solution for ingesting badge events and alarm data from PACS to generate hardware-level and identity-level intelligence for the customer's Security Operations Center. Where PIAM and VIM are about **provisioning** access, SOC Insights is about **observing** what's happening at readers, panels, and doors — and correlating it with the identity context Guardian holds. Not every PACS connector supports SOC Insights. The list of confirmed-supported connectors includes [[lenel-open-access]] (via OpenAccess REST API — Readers, Panels, Events, Alarms) and [[ccure9000-victor]] (via journal log queries — CardAdmitted, CardRejected, ObjectChangedState, JournalStateChange event types). For an enterprise RFP, having SOC Insights coverage on the customer's PACS is a meaningful differentiator — without it, Guardian is a provisioning system; with it, Guardian is a converged security operations platform.

• AE SOC Insights (Guardian capability)
• lenel SOC Insights via Lenel OpenAccess (Readers / Panels / Events / Alarms reconciliation)
• ccure SOC Insights via CCURE 9000 (event types from ACVSUJournalLog tables)

The authoritative source for a given piece of identity data. In a well-designed identity architecture, **exactly one system is the SoR** for each attribute — everywhere else holds a copy that flows downstream from the SoR. Identifying which system is the SoR for each attribute is fundamental to PIAM design; otherwise reconciliation conflicts produce drift that the operator can't resolve deterministically. Typical patterns at large enterprise: - **Workday / SAP HR / PeopleSoft**: SoR for employee identity (name, employee ID, hire date, manager, department) - **SAP Fieldglass**: SoR for contingent worker identity - **SailPoint**: SoR for identity lifecycle state (active / pending termination / off-boarded) - **Okta / Entra ID**: SoR for application access entitlements (downstream of HR/IGA) - **AE Guardian**: SoR for physical access entitlements + badge / credential records When AE Guardian's connectors are configured, customers explicitly designate which connector reads-only (consuming SoR data) and which writes (provisioning derived state). Bidirectional connectors require clear delineation of which attributes flow which direction — otherwise reconciliation loops can corrupt data.

• AE SoR (Guardian's data model designates SoR per attribute)
• sailpoint SoR for identity lifecycle state in many enterprises
• workday SoR for full-time-employee identity in cloud-HCM deployments
• sap SoR for FTE identity in on-prem SAP HR deployments

A one-time code or token distributed to a user that authorizes them to claim a credential on a device. HID's model centers on this; in Wavelynx's model the partner manages users directly so no invitation primitive exists at the vendor level.

• HID v2.2 Invitation Code (16-char alphanumeric)
• AE Invitation Email

The visitor-oriented sister discipline to PIAM. Where [[piam]] handles employees, contractors, and other long-lived identities, VIM handles short-lived visitor identities — pre-registration, host-sponsored access, day-pass issuance, sign-in/sign-out audit trails, and automatic expiry. AE Guardian implements VIM as a first-class capability with its own object family (Visitors, Visitor Badges, Visitor Access). Not all PACS connectors expose VIM — both **Lenel OnGuard** (via [[lenel-open-access]]) and **Software House C·CURE 9000** (via [[ccure9000-victor]]) support PIAM + VIM through the same connector. Other PACS connectors are PIAM-only. Why this matters: an enterprise RFP asking "can your system handle 5,000 daily visitors at a Fortune 500 lobby" needs both connector-level VIM support *and* AE Guardian-side visitor workflows (pre-registration emails, kiosk-based ID capture, host notifications). The connector list alone doesn't answer it.

• AE VIM (Visitor Identity Management) — Guardian capability
• lenel VIM via Lenel OpenAccess REST (Visitor, Visitor Badge, Visitor Access objects)
• ccure VIM via CCURE 9000 Victor (Visitors, Visitor Badges, Visitor Access)

A standardized cardholder identifier used across PIV (Personal Identity Verification) and PIV-I (PIV-Interoperable) credentials, defined in FIPS 201. CHUID is a structured byte sequence — typically 18 bytes for the FASC-N portion plus optional GUID, expiration date, agency code, and digital signature — encoded in a card-format wrapper readable over Wiegand, ISO 14443, or NFC. CCURE 9000's Victor API exposes `Badge.CHUID` and `Badge.CHUIDFormatID` as discrete fields — the connector's typical formula maps it as `'000000$BadgeId'` (zero-padded card number). For federal and federal-adjacent deployments (DoD, GSA, large defense contractors), CHUID-formatted credentials are mandatory — the PACS must support reading and validating them, and the provisioning system (Guardian) must populate them correctly. Beyond federal, CHUID is increasingly seen in critical-infrastructure deployments (utilities, healthcare, transportation) where customers want PIV-grade credential trust without full federal-PKI certificate chains.

• AE CHUID (in PACS connector fields)
• ISO FIPS 201 PIV Cardholder Unique Identifier
• ccure Badge.CHUID + Badge.CHUIDFormatID

Request-scoped identifier carried in HTTP headers (or payload) for cross-system tracing during support investigations and asynchronous callback correlation.

• Wavelynx correlationId (Wavelynx ↔ NXP scope)
• HID v3.x CorrelationId (HTTP response header)
• Apple UAP sharingInstanceIdentifier

Identifier scoped to a specific (credential × device) pair. Distinct from the pass identifier, which references the issuance instance. A single credential can have many device IDs over its lifetime if the user provisions to multiple devices or re-provisions after wipe.

• Wavelynx VUID
• HID v2.2 Credential Container ID
• HID v3.x Credential Container ID
• Apple UAP device-bound IDs

How the customer's identity system (Workday, Okta, Entra ID, etc.) tells the credential platform which users are eligible to receive credentials. Apple and Google have no concept of user eligibility — the issuer is responsible. HID accepts SCIM-formatted eligibility data; Wavelynx delegates to the partner.

• HID v2.2 SCIM v2 eligibility payload

The federal-issued identifier embedded in a PIV credential, defined in NIST SP 800-73 and FIPS 201. FASC-N is a 75-bit (extended) or 200-bit (full) structured number combining Agency Code, System Code, Credential Number, Credential Series, Individual Credential Issue, Person Identifier, Organizational Category, Organizational Identifier, and POA (Person/Organization Association). FASC-N appears inside [[chuid]] wrappers — readers and panels validate the FASC-N portion against trust lists provisioned by the issuing authority. The numbers are long enough that traditional PACS card-number fields (32-bit unsigned integer ceiling, e.g. CCURE 9000's 4,294,967,295 limit) cannot hold the full FASC-N — those deployments must use the CHUID + FacilityCode credential-unique-fields path.

• ISO NIST SP 800-73 FASC-N

Wavelynx's design pattern: identifiers (VUID, PBID, device-bound IDs) are unique within a specific Wavelynx ↔ wallet-provider relationship but have no meaning outside it. They cannot be cross-referenced with third-party identifiers or end-user identity systems. Lets Wavelynx scope cardholder fields voluntarily — the credential can be fully anonymous.

Unique identifier for a single provisioned wallet pass instance. Used by issuer-side systems to reference and update a specific credential after issuance. Federated to the issuer↔wallet relationship — has no meaning outside that context.

• Wavelynx PBID
• HID v3.x passId
• Apple UAP provisioningBundleIdentifier
• Google passId

How a vendor models the end user. Wavelynx is user-less by design — partners manage users and Wavelynx exposes only credential and group identifiers. HID exposes a SCIM v2-compliant user model (with HID extensions) but limits it to credential management; HID's User Management API is not consumed by other HID services.

• Wavelynx federated identifiers only
• HID v2.2 SCIM v2 + urn:hid:scim:api:ma:2.2:UserAction
• HID v3.x SCIM v2 (limited)

Credential is provisioned, present on the user's device, and authenticatable at readers. The default operational state for a healthy credential.

• Wavelynx ACTIVE
• HID v2.2 ISSUED
• HID v3.x ACTIVE
• Apple active

Issuance or revocation could not complete. Causes include offline device, expired auth tokens, or unrecoverable wallet errors.

• HID v2.2 REVOKING_FAILURE
• HID v3.x FAILED

Initial state after issuance request, before the wallet has acknowledged receipt. Some vendors don't expose this state to partners.

• Wavelynx PENDING
• HID v2.2 (pre-issue, not exposed)
• HID v3.x (pre-issue, not exposed)

Issuance has begun and the wallet is processing the credential. Transient state — typically resolves to active within seconds.

• HID v2.2 ISSUE_INITIATED
• HID v3.x (PPPU in progress)

Terminal state. Credential is no longer valid; on-device material removed at next sync. Wavelynx soft-deletes (status moves to DELETED while billing/audit fields remain); HID hard-revokes via revocation flow.

• Wavelynx DELETED (soft-delete)
• HID v2.2 REVOKED
• HID v3.x CANCELLED
• Apple removed

Credential is paused — it remains on-device but doesn't authenticate at readers. Reversible via resume. HID v2.2 doesn't have a separate suspend state — the equivalent path goes through REVOKE_INITIATED.

• Wavelynx SUSPENDED
• HID v3.x (PPPU patch state)
• Apple suspended

The bit-layout structure of a physical or virtual access credential — defines how the reader interprets the bytes streamed off the card / wallet pass. Wiegand "26-bit standard" is the historical baseline; more secure deployments use longer formats (HID 35-bit, Corporate 1000, FASC-N) or smart-card cryptograms (Seos, MIFARE DESFire, Apple/Google mobile credentials). Each PACS exposes a fixed enum of supported formats. AMAG, for example, supports exactly five: `SeiwgV1`, `SeiwgGSC2_1`, `SRSeries_10And12Digit`, `SRSeries_15Digit`, `Standard`. CCURE captures the format alongside the CHUID. Brivo defaults to "Standard 26 Bit" with explicit `facility_code` + `card_number` fields. AE-side provisioning must specify the format on every badge operation, or the PACS rejects it (the CardFormat-mandatory limitation in AMAG and the CHUIDFormatID requirement in CCURE).

• AE Credential Format (in Guardian)
• lenel BadgeFormat (in OnGuard schema)
• ccure CHUIDFormatID / Badge.CHUIDFormatID
• amag CardFormat (5 enumerated values)
• brivo Standard 26 Bit (typical default)

The on-device data structure that an NFC reader actually authenticates against. Different vendors use different chip-emulation profiles. The device hardware doesn't care which vendor issued it — it cares which chip protocol the credential pretends to be.

• Wavelynx DESFire (Apple) / DESFire EV2 via NXP MIFARE2GO (Google)
• HID v3.x Seos
• AE Mobile Credential

HID's proprietary credential technology — the on-chip data structure and crypto suite used in HID-issued mobile credentials (and physical Seos cards). Apple Wallet's HID integration delivers a Seos credential payload that authenticates at HID readers.

• HID v3.x Seos

Intermediary HID infrastructure that brokers credential delivery between HID Origo and the wallet platforms. Sits between HID Origo and Apple Pay / Google in HID's deployment topology.

• HID v3.x HID TSM

LEGIC's HSM-backed key management service. Generates "never-visible" random keys inside LEGIC HSMs — the keys never leave the HSM in plaintext form. Recommended by LEGIC over customer-supplied master keys. Combined with LEGIC's installed base of secure-module-based access reader/lock hardware, Orbit lets wallet-credential encryption keys reach access hardware without ever appearing in plaintext outside an HSM. Required for encryption key rotation: rotation is supported only when Orbit is the key management path. Orbit is co-located with both LEGIC's Apple-side service (Apple Credential Provider & Orbit Service) and Google-side service (Google Access Hub & Orbit Service) — the same Orbit backend serves both wallet platforms. The keyset is configured once at project onboarding (step 2 of both the Apple and Google provisioning flows) and applies to all credentials issued under that project. Architecturally distinct from Wavelynx and HID: LEGIC's mobile- credential encryption keys are INDEPENDENT of physical card encryption keys. Wavelynx and HID both diversify per-credential keys from a master that's also used for physical-card encryption; LEGIC isolates the wallet key from the physical card key entirely.

• AE LEGIC Orbit

LEGIC's key-handling service infrastructure. Supports two paths for master keys: programmatic delivery via the LEGIC Connect API, or manual delivery via a documented key ceremony. Does NOT support HSM-wrapped key import — customer-supplied keys arrive either via the API channel or via the ceremony. LEGIC's stated recommendation is to skip customer-supplied keys entirely and use Orbit instead, since LEGIC's wallet credential keys are architecturally independent of physical card keys (no reason to import a master).

• AE LEGIC Trusted Service

Where the issuer's master keys (from which per-credential keys are derived) are physically held. Best-practice is hardware-backed (HSM) with database-side keys wrapped by an external KMS. Wavelynx documents an HSM-rooted, KMS-wrapped, no-plaintext-at-rest pipeline; HID's public docs are silent on the equivalent — depth lives in NDA partner material.

• Wavelynx HSM-rooted, KMS-wrapped Cloud SQL storage

Wavelynx's deterministic process for deriving a unique per-credential symmetric key from a per-partner-site master key. Diversified keys are never persisted — they're regenerated on demand. Compromise of any single issued credential does not compromise other credentials issued under the same master key.

• Wavelynx Per-credential key diversification

Symmetric credential keys delivered to the wallet platform in encrypted form, never as plaintext. Each wallet has a published key-wrapping spec the issuer must follow. The wallet's key-management infrastructure decrypts internally; the issuer never has access to the unwrapping key.

• Wavelynx Wrapped per Apple's key-wrapping spec
• AE authorizationBlobs (per AE diagrams — confirm equivalence)

Identifier HID issues to applications via the Technology Partner Service (TPS) certification program. Required header on every API call; HID will not accept calls from uncertified applications. AE has a TPS-certified Application-ID covering its mobile credential integrations.

• HID v3.x Application-ID

Microsoft Entra ID's policy engine that gates authentication based on signals — user, device, location, application, risk level. Conditional Access lets the customer's identity admin express rules like "require MFA when accessing AE Guardian from outside the corporate network" or "block sign-in if the device is non-compliant" or "step up to phishing-resistant MFA for privileged users." Requires **Entra ID Premium P1** (basic policies) or **P2** (risk-based policies with Identity Protection signals). Customers on the free Entra tier rely on Security Defaults instead, which apply a fixed policy across the whole tenant. When AE Guardian is registered as an Enterprise Application in Entra ID and the customer has Conditional Access policies targeting it, **all of those policies flow through automatically** when users SSO into Guardian via [[microsoft-entra-id-sso]]. AE doesn't need to configure anything Conditional-Access-related; it inherits the customer's policy posture. Okta's analogous concept is Sign-On Policy; PingFederate's is Authentication Policy / Selector chain.

• okta Sign-On Policy (the Okta analog)
• entra Conditional Access (Entra Premium P1+) — policy engine for context-aware auth

Authentication that requires two or more independent factors — typically **something you know** (password / PIN), **something you have** (TOTP authenticator / FIDO2 security key / push-notification approval), and/or **something you are** (biometric). MFA is now baseline expectation for all enterprise application access; insurance carriers and regulatory frameworks (NYDFS Part 500, PCI DSS 4.0, federal Zero Trust mandates) require it. **AE Guardian doesn't enforce MFA itself** — MFA enforcement is owned by the customer's IdP (Okta Sign-On Policy, Entra ID Conditional Access, PingFederate Authentication Policy). When AE Guardian uses SSO via one of the [[saml]] connectors, MFA enforcement flows through automatically: the IdP requires MFA before issuing the SAML assertion. The connectors don't need any AE-side MFA configuration. For the few authentication paths where AE Guardian authenticates directly (no SSO), MFA is enforced via AE's own configuration. These paths are rare in production deployments.

• okta Sign-On Policy (controls MFA requirements per app / per user / per location)
• entra Conditional Access (Entra Premium P1+) — MFA + risk-based gating

An identity layer on top of OAuth 2.0 — defined by the OpenID Foundation. OIDC adds an `id_token` (a JWT with user identity claims) to OAuth 2.0's access-token model, so that an application can verify the user's identity via a single round trip with the Identity Provider rather than calling a separate /userinfo endpoint. OIDC is the modern federation protocol for new applications — simpler than [[saml]], JSON-native (no XML signatures to validate), and well-supported across IdPs (Okta, Entra ID, PingFederate, Auth0, Google, Apple Sign-In). AE Guardian supports OIDC as an alternative to SAML for the SSO connectors but most enterprise deployments still standardize on SAML for historical reasons. Specifications: OpenID Connect Core 1.0 (final), Discovery 1.0, Dynamic Client Registration 1.0.

• ISO OpenID Connect Core 1.0
• RFC OAuth 2.0 base — RFC 6749
• okta Okta supports OIDC across all SSO scenarios
• entra Entra ID supports OIDC as primary protocol for new app registrations

How an integrator authenticates to the credential provider's API. Both major vendors use OAuth 2.0 client_credentials at the foundation; HID adds a PKI certificate option for higher-assurance partners.

• Wavelynx ECC P-256 signature → bearer JWT
• HID v3.x OAuth 2.0 client_credentials + PKI cert option

Vendor-specific headers required on every API call beyond standard Authorization. HID requires Application-ID + Application-Version tied to Technology Partner Service certification — partners cannot call HID Origo without TPS-certified application identity.

• Wavelynx x-api-key (webhooks); mTLS (partner)
• HID v3.x Application-ID + Application-Version (TPS-certified)

Security Assertion Markup Language — the dominant enterprise SSO federation protocol since the mid-2000s, defined by OASIS. SAML 2.0 uses XML-signed assertions to communicate user identity from an **Identity Provider (IdP)** to a **Service Provider (SP)**. The flow: 1. User attempts to access the SP (e.g., AE Guardian) 2. SP redirects browser to IdP with an AuthnRequest 3. IdP authenticates the user (against AD / Entra / OAM / etc.) 4. IdP posts a signed SAML Response to the SP's ACS (Assertion Consumer Service) URL 5. SP validates the signature, extracts claims (Name ID, attributes), logs the user in AE Guardian acts as the SAML **Service Provider** in all 5 SSO connectors ([[adfs-sso]], [[okta-sso]], [[azure-sso]], [[microsoft-entra-id-sso]], [[ping-federate-sso]]). Despite the existence of newer [[oidc]], SAML 2.0 remains the dominant federation protocol in enterprise deployments — primarily because customer policies and certifications were written around SAML in the 2010s and have not been updated. Bindings: HTTP-Redirect (for AuthnRequest), HTTP-POST (for Response), SOAP (for Artifact), Artifact (rarely used).

• ISO OASIS SAML 2.0 Core / Bindings / Metadata
• okta Configured as a SAML 2.0 Application in Okta admin console
• entra Configured as a non-gallery Enterprise Application in Entra admin

HID Origo's machine-account naming convention for OAuth client_id values. Format is `{organization_id}-OSRV{random_string}` — encoding the tenancy in the account ID itself.

• HID v3.x {organization_id}-OSRV{random_string}

The vendor-side primary key that scopes all of a partner's resources. Every API call carries it. Rate limits, billing, and webhook routing are all keyed on it.

• Wavelynx partner_id
• HID v3.x organizationId

PeopleSoft's mechanism for exposing PeopleSoft business logic to external integrators. A **Component Interface (CI)** wraps a PeopleSoft Component (a UI screen + its underlying business logic) and presents it as a programmatic interface that external systems can invoke. CIs are accessed via PeopleSoft's REST APIs, the **PSJOA (PeopleSoft Java Object Adapter)** library, or PeopleSoft Integration Broker. AE Guardian's [[people-soft]] connector uses PSJOA to invoke CIs directly. Common CIs the connector consumes: - `CI_PERSONAL_DATA` — cardholder demographic data - `CI_JOB_DATA` — job assignment + position history - `CI_PERSON_ROLES_USER` — role memberships Each CI must be **exposed to the integration user** in PeopleSoft Security — the operator's permission list needs to include the CI in its Component access. This is a frequent setup gotcha: the operator can log in but can't invoke the CI because the permission list wasn't extended.

An **Integration Flow** in SAP Business Technology Platform / Cloud Integration. An IFlow is a graphical / declarative integration pipeline — typically built in the SAP Integration Suite designer — that connects a source system to a target system via a series of transformation, routing, and protocol-translation steps. AE Guardian's [[sap-btp]] connector consumes IFlows configured by the customer to expose **SAP SuccessFactors**, **SuccessFactors Learning**, and **SAP Fieldglass** data in a normalized REST surface. The AE side doesn't author IFlows — those are the customer's SAP-Integration-Suite admin's responsibility. AE consumes whatever the IFlow exposes. IFlows can apply different authentication modes per step: OAuth 2.0 client credentials, SAML, API key, or Basic auth. This is why the SAP BTP connector documents support for all four auth modes — the customer chooses based on IFlow configuration.

• sap IFlow / Integration Flow in SAP BTP Cloud Integration

An open, bidirectional, SIA-standardized reader-to-controller protocol — the modern replacement for the one-way [[wiegand]] reader protocol. OSDP runs over RS-485 and supports **OSDP Secure Channel** (AES-128 encrypted command + response), tamper detection, configurable LED/buzzer feedback, and remote firmware updates. OSDP is the right answer for new enterprise deployments — Wiegand is unsupervised, plaintext, and vulnerable to wire-tapping attacks. SIA OSDP versions: v2.1.7 (2015), v2.2 (2022). v2.2 added more granular Secure Channel session key rotation. AE Guardian and the PACS connectors don't directly drive readers — the PACS panel handles that — but the reader-protocol choice affects what AE can expect to surface in [[soc-insights]]. OSDP readers report richer diagnostic data than Wiegand readers (tamper status, link health), which Guardian can ingest into SOC dashboards if the upstream PACS captures it.

• ISO SIA OSDP Standard

The intermediate hardware that aggregates one or more readers, makes the local access-grant decision, drives the door strike / mag-lock, and reports events upstream. Panels are the "brain" of the PACS in the field — even when the central PACS server is unreachable, the panel can still authorize a known credential against its local cache (called "offline mode" or "stand-alone mode"). Different vendors expose panels at different levels of abstraction. CCURE 9000 exposes panels and door controllers as discrete objects via Software House's intelligent controller line (iSTAR). Pro-Watch panels include Honeywell's PW6K and PW7K series. Lenel uses LNL-series intelligent controllers. PACOM uses 8000 / 8003 series Network Access Modules. AE Guardian reconciles panel definitions as part of asset reconciliation for [[soc-insights]] coverage — important because a panel going offline is one of the most operationally critical PACS events to detect and surface in SOC dashboards.

• AE Panel / Controller (in Guardian Asset model)
• lenel Panel (LNL-series controller)
• ccure Panel (iSTAR controller; objects in ACVSCore.Access)
• honeywell Panel (PW6K / PW7K series)
• pacom NAM (Network Access Module)

The edge hardware that physically reads a credential — typically mounted at a door, turnstile, or elevator call panel. Readers come in many wire protocols ([[osdp]], Wiegand, IP-native, RS-485) and credential modalities (proximity, smart card, BLE, NFC, biometric). Modern enterprise readers support several modalities at once via configurable transcoding profiles. PACS systems model readers as first-class objects keyed by an internal ID and referenced from doors, access groups, and reader groups. CCURE models doors with `InReaderID` and `OutReaderID` distinguishing entry from exit. AMAG groups readers into Reader Groups for floor/area-based access. Pro-Watch encodes reader state via a numeric code (67=Card Only, 80=CARD+PIN, 78=CustomerCode No Store, 83=CustomerCode Store).

• AE Reader (in Guardian)
• lenel Reader (incremental reconciliation supported via SOC Insights)
• ccure Reader (`ACVSCore.Access.Reader`; InReaderID / OutReaderID on each door)
• amag Reader (`ReaderTable`; bundled into Reader Groups)
• honeywell Reader (state-encoded via numeric value)

The legacy one-way reader-to-controller protocol that dominated PACS deployments from the 1980s through the 2010s. Wiegand is unsupervised, plaintext, and uses a simple two-wire (Data0 / Data1) signaling scheme — making it easy to install but trivially vulnerable to wire-tapping attacks. The most common variant is **26-bit Standard Wiegand** (8-bit facility code + 16-bit card number + parity bits); higher-security variants use 35-bit, 37-bit, or Corporate 1000 (48-bit) formats. Wiegand readers don't support encryption, mutual authentication, tamper reporting, or remote firmware updates. They also have no return path — the reader can't acknowledge whether the panel received the bits. The protocol is being actively deprecated in favor of [[osdp]] in security-conscious sectors (federal, financial services, healthcare). AE Guardian sees Wiegand only indirectly — via PACS connector reader / card-format metadata. Card numbers provisioned by AE must respect the reader's Wiegand bit-width; provisioning a 35-bit card number to a 26-bit reader will fail at the panel.

• AE Wiegand (in reader-protocol metadata)
• ISO 26-bit Wiegand (most common; 8-bit facility + 16-bit card)

How the receiver verifies a webhook came from the vendor. Wavelynx uses a static x-api-key header (with optional mutual TLS pinning). HID lets the partner pick: Basic Auth header or an API Key header with a custom header name + secret.

• Wavelynx x-api-key (static) + optional TLS pin
• HID v3.x Basic Auth OR API Key (custom header name + secret)

How many events ship per HTTP request. Wavelynx fires one event per POST with retry-on-failure semantics. HID batches multiple events per POST and stores undelivered events server-side for partners to poll-recover.

• Wavelynx One event per POST
• HID v3.x Batch — multiple events per POST

What happens when a webhook delivery fails. Wavelynx retries on 5xx and timeout, with a deduplicating message_id. HID does not retry — failed events are persisted in HID's Event Management API for the partner to fetch on their own schedule.

• Wavelynx Retry on 5xx/timeout, message_id for dedup
• HID v3.x Persist to Event Management API for poll-recovery

The wire-format spec a vendor's webhooks conform to. Wavelynx ships a custom JSON envelope; HID adopted CloudEvents (the CNCF spec) and delivers events in batches.

• Wavelynx Custom JSON
• HID v3.x CloudEvents — application/cloudevents-batch+json

How partners register interest in events. Wavelynx uses one static URL plus a key per partner. HID uses filter-based subscriptions — partners register URL + filterId, where filterId references which event types they want.

• Wavelynx Static URL + key per partner
• HID v3.x Filter-based — register URL + filterId

Apple's role definition under the Apple Wallet Access Program (UAP) for the entity that provisions credentials to Apple Wallet. The Credential Provider is the technical counterparty that holds the signing keys, formats provisioning bundles, and integrates with Apple Pay directly. In the LEGIC topology, LEGIC operates the Apple Credential Provider service (combined with LEGIC Orbit for key management) and AE (the "Client Backend") takes the companion Credential Manager role — managing user-side workflows, assembling and delivering the wallet pass reference (credentialProviderId, environmentId, walletCardId) to Apple Wallet Service, and managing credential lifecycle by calling LEGIC's Apple CP API. The walletCardId is LEGIC's per-credential identifier — minted by the Apple CP when the credential record is created and passed through the provisioning flow as the key reference between the Client Backend, Apple Wallet Service, and LEGIC's Apple CP. Distinguished from the Apple Credential Manager (the partner-facing role that handles user onboarding, lifecycle requests, etc.). One CP may serve multiple CMs.

• Apple UAP Apple Credential Provider
• Apple Credential Provider

Apple's proprietary contactless protocol that adds a control-channel layer above standard ISO 14443 / NFC tap interactions. ECP lets the reader signal to the Apple device which credential type and which authentication mode (Express, TRA, biometric) the reader expects before the credential is presented. Operationally, ECP is what enables 2FA-at-reader scenarios in Apple Wallet — the reader can require Two-factor Reader Authentication (TRA) or biometric confirmation as a condition of credential presentation, while still supporting Express Mode for low-friction flows. Wavelynx, HID, and other reader manufacturers must implement ECP to support Apple Wallet credentials. Different ECP frame variants signal different credential families (transit, access, identity).

• Apple Enhanced Contactless Polling

Apple's program for credential providers and credential managers participating in Apple Wallet–based access control. UAP defines the technical roles (Credential Provider vs. Credential Manager), the provisioning bundle format, the signing-key ceremony, and the Apple Pay API surface that credential providers integrate with. AE participates in UAP both directly (Wavelynx CP topology — AE acts as Credential Manager and talks to Apple via the Apple Pay API) and indirectly (HID CP topology — HID Origo Integration Service is the Apple-facing entity and AE consumes downstream). Distinct from the Apple Credential Manager role (partner-facing, user-onboarding-focused) and the Apple Credential Provider role (cryptographic-counterparty, Apple Pay API–facing). Both roles participate in UAP; one CP can serve multiple CMs.

• Apple UAP UAP
• Apple Apple Wallet Access Program

Apple's proprietary extension to ISO/IEC 14443. Lets readers broadcast configuration and capability information in the polling loop before any back-and-forth communication, so an Apple device can route to the right credential applet automatically. Required for Apple Wallet access-control deployments.

• Apple Enhanced Contactless Polling

Apple device feature that allows the credential to authenticate without the user unlocking the device or opening Wallet. Tap-and-go. Disabled when TRA is configured on the reader. iPhone-default-on, Watch-default-off.

• Apple Express Mode

When the iPhone or Apple Watch enters low-battery shutdown, recent devices keep enough reserve power to authenticate stored credentials for up to ~5 hours. Critical for after-hours access scenarios where the user has a dead phone but still needs to enter the building.

• Apple Power Reserve Mode

Reader-side configuration that forces the Apple device to require user authentication (Face ID, Touch ID, or passcode) before the credential is presented. Used to enable a 2FA enforcement model on high-security doors. Configured per-reader, not per-credential.

• Apple Terminal Requested Authentication

Identifier the NFC reader transmits to the Android device on each Smart Tap. The device looks up the corresponding Redemption Issuer ID to decide which credential to present.

• Google Collector ID

LEGIC's Google Wallet integration service — analogous role to their Apple Credential Provider service, but for Google Wallet Corporate badges. Paired with LEGIC Orbit for key management. Operates as a direct integration with Google's Access Platform (no external mediator like the NXP MIFARE2GO path Wavelynx uses). In the LEGIC topology, LEGIC operates Google Access Hub & Orbit Service and the Client Backend (AE's system) drives the provisioning flow by: (1) requesting credential preparation and receiving a provisioning token, (2) delivering that token to the user's registered mobile app, and (3) managing lifecycle changes by calling LEGIC's Google Access Hub API. The Google flow requires a LEGIC Mobile SDK running inside the mobile app. The SDK speaks Google's Access Platform protocol on-device — initiating the add-to-Wallet sequence, requesting the credential bundle, and handling installation into Google Wallet. No equivalent SDK is needed for the Apple flow (iOS handles the wallet protocol natively). Card format for Google Wallet credentials is chosen at project onboarding: neon (LEGIC's proprietary NFC format) or DESFire (NXP MIFARE DESFire). This choice determines reader compatibility at the customer site.

• Google Access Hub (LEGIC)

Structural feature gap vs. Apple Wallet. Google Wallet does not support user-initiated provisioning — every credential must be pushed by an admin who issues a token the user redeems. Same gap applies to suspend / resume from the wallet UI: those user-initiated paths don't exist on Google.

• Google admin-only token redemption

Google's proprietary NFC protocol for delivering data from an Android device's wallet to an NFC reader. Encrypted via keys negotiated at channel-establishment. Counterpart to Apple's ECP/VAS ecosystem.

• Google Smart Tap

AE's mobile-native client (iOS, Android). Optional in the integration topology — web-based provisioning can substitute for it, but the app provides the smoother in-device "Add to Wallet" experience.

• AE AE Wallet App

Browser-based provisioning surface. Used when the AE Wallet App isn't installed — typically for first-time provisioning to a device the user opens via an emailed invitation link.

• AE AE Web

AE's cloud orchestration layer between Guardian and the credential providers. Hosts per-vendor connectors (HID, Wavelynx, LEGIC), the webhook receiver, and the Mobile Credentials Service. Multiple AE diagrams refer to this layer by other names — this is the canonical one.

• AE AE NFC Cloud / Guardian Mobile Cloud Service / Mobile Cloud Service

AE's PIAM (Physical Identity & Access Management) platform — the source of truth for identities and access rights. Initiates mobile credential requests based on user identity, role, and access policy. Self-service request UI lives here.

• AE Guardian

LEGIC's cloud platform for issuing and managing mobile credentials. Operates the Apple Credential Provider service (for Apple Wallet) and the Google "Access Hub" service (for Google Wallet) on behalf of customers. AE's role in this topology is the Credential Manager (Apple) or third-party partner (Google). LEGIC Connect handles credential delivery, post-provisioning updates, and lifecycle events. Paired with LEGIC Orbit for HSM- backed key management.

• AE LEGIC Connect

OSS Association standard companion to OSS-SO, specifying the data interface between credential-management systems and access control hardware. Frequently asked about together with OSS-SO when evaluating offline/online lock interop in EU deployments. LEGIC's support status for OSS-SID was asked but not directly addressed in LEGIC's email response — see Wiki — Open Questions for the follow-up.

OSS Association standard for offline-capable electronic access control. Defines a vendor-neutral data layout that lets credentials issued by one vendor interoperate with locks and readers from another, without requiring online communication between them at authentication time. Two reference parts are typically asked about — OSS-SO Part II (data layout) and OSS-SO Part III (cryptography). A separate "Wallet extension" defines how OSS-SO payloads are carried inside Apple / Google Wallet passes. Common in EU access control — customers in that market frequently ask whether a credential provider supports OSS-SO interop. LEGIC Connect supports payloads formatted per the latest OSS-SO Wallet extension; Parts II/III specifically were asked but not separately confirmed (see Wiki — Open Questions).

Personal Identity Verification (PIV) — the federal standard for identity credentials, defined in **FIPS 201** by NIST. PIV credentials are smart cards combining PKI certificate-based authentication, biometric verification, and physical access credentials in a single token. **PIV-I** (PIV-Interoperable) is the related standard for non-federal organizations that want PIV-grade trust. For PACS deployments serving federal customers or federal contractors: - The credential carries a **[[fasc-n]]** identifier inside a **[[chuid]]** structure - Readers must support ISO 14443 / NFC contactless plus contact smart-card modes - Cardholder enrollment must capture biometric (fingerprint) templates - Lifecycle events trigger CRL / OCSP revocation publication AE Guardian's role in PIV-bearing environments is provisioning the cardholder + badge metadata into the PACS in a way that respects the PIV identifier structure; AE doesn't itself act as a PIV issuer (the federal agency or PIV-I issuer does).

• ISO NIST FIPS 201