Cross-vendor terminology reconciliation. Each concept has a canonical name plus per-vendor aliases — hover or scan to map terms across HID, Wavelynx, Apple, Google.
44 concepts · 10 categories
template-or-sku
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.
pppu
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.
provisioning-payload
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.
provisioning-unit
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.
user-invitation
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.
correlation-id
Request-scoped identifier carried in HTTP headers (or payload) for cross-system tracing during support investigations and asynchronous callback correlation.
device-credential-id
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.
eligible-user-data
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.
federated-identifier
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.
pass-id
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.
user-model
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.
state-active
Credential is provisioned, present on the user's device, and authenticatable at readers. The default operational state for a healthy credential.
state-failed
Issuance or revocation could not complete. Causes include offline device, expired auth tokens, or unrecoverable wallet errors.
state-pending
Initial state after issuance request, before the wallet has acknowledged receipt. Some vendors don't expose this state to partners.
state-provisioning
Issuance has begun and the wallet is processing the credential. Transient state — typically resolves to active within seconds.
state-revoked
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.
state-suspended
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.
credential-format
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.
seos
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.
tsm
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.
master-key-store
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.
key-diversification
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.
wrapped-key-material
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.
application-id-tps
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.
partner-auth
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.
required-headers
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.
system-account-format
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.
tenancy-id
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.
webhook-auth
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.
webhook-shape
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.
webhook-failure-handling
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.
webhook-spec
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.
webhook-subscription
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.
ecp
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.
express-mode
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.
power-reserve-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.
tra
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.
collector-id
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-no-user-init
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.
smart-tap
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.
ae-wallet-app
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-web
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.
guardian-nfc-cloud
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.
guardian-platform
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.