An employee replaces a lost badge, later gets a new phone, and uses another credential method at a second building. If each change creates another identity record, one person quickly becomes several records to manage.
The BluBØX Credential Framework, or AnyID Credential Fabric, gives BluSKY a common architecture for governing credentials around the person. Credential technologies can share one identity and policy model, while reader relationships, lifecycle activity, evidence, and history stay connected in the same system of record.
The person is the anchor. Credentials are ways to prove identity.
BluBØX describes credentials as replaceable evidence associated with one canonical BluSKY Person Record. Cards, phones, QR codes, PINs, and other authorized methods can all be associated with that person as identity evidence.
A replacement badge becomes another credential instance tied to the existing Person Record, where the employee’s relationships, access context, lifecycle status, and history remain connected. As access needs change, additional authorized credential methods can use that same record.
BluSKY remains the identity system of record while the credentials around the person evolve.
The Credential Framework covers several ways a person may present identity, including physical cards, BluID mobile credentials, BluREMOTE, temporary BluPASS credentials, Person Reader modalities, and provider-dependent wallet paths.
Availability depends on the credential path and deployment. Some capabilities are documented and available subject to configuration. Others rely on provider integrations, compatible readers, firmware, keys, licenses, agreements, certification, geography, or release status. Wallet and other provider-dependent routes vary with the specific hardware, integrations, and deployment requirements involved.
Across these methods, the Person Record remains the common point for identity, policy, lifecycle, and history.
A credential can be valid for the person and still be unusable at the intended portal if the reader route is not compatible.
Reader hardware is only one part of that route. Firmware, keys, controllers, output paths, portal policy, and local behavior can also determine whether a credential will work as intended. BluBØX includes those factors in the compatibility model used before it promises or issues a credential.
A mobile credential, for example, may rely on a different provider and reader path than a physical card. The Credential Framework connects the person and credential to the route and policy that will govern the access decision.
A replacement badge and an expiring temporary credential create very different administrative tasks. A role change, departure, or other change in a person’s relationship with an organization may call for suspension or revocation instead.
BluBØX defines a credential lifecycle that can include issuance, activation, suspension, resumption, revocation, expiration, replacement, and reconciliation. Each event can remain associated with the person and the broader access history.
The Person Record can also bring multiple credentials, access rights, exceptions, approvals, and lifecycle events into the same view.
Credential governance requires enough history to reconstruct what happened.
The Credential Framework connects credential activity with the Person Record, authorized readers, access policy, risk conditions, lifecycle state, presentation evidence, decision outcome, and audit history.
An access event can retain context about the person, the identity evidence presented, the reader or portal involved, the policy in effect, and the resulting decision.
Viewed over time, the same history can show which credentials were associated with the person, where approvals or exceptions applied, and how access reached its current state. Administrators and reviewers can reconstruct the credential, policy, and identity context surrounding an event.
The Person Record gives BluSKY a stable identity around which it can govern credential technologies, reader paths, policies, and lifecycle changes.
One Person. One BluSKY Record. Many governed credential instances.
