# Credential lifecycle playbook


Draft 0.3 — provider authorisation is always required.


## Register on-site

“Do you already have a compatible credential?” becomes part of enrolment.

1. **Establish the account.** Staff locate or create the local account and apply the existing identity checks.

2. **Present your credential.** Scan or tap a supported medium. Check the format and enforce uniqueness.

3. **Link & test.** Assign it, test a real transaction, and record what was enrolled.


**Boundary:** No-change route only when the existing enrolment workflow accepts the medium and value. Native proof is an additional integration.


## Self-register online

The organisation’s existing account remains the starting point—not an unverified QR code.

1. **Sign in first.** Use an authenticated account session, with step-up verification when required.

2. **Prove & pair.** Complete a provider-bound registration ceremony. Bind short-lived pairing codes to the session.

3. **Confirm & notify.** Show the account and credential; confirm the link, notify the user, and test.


**Boundary:** C0/C1 use existing portal functions only; no new provider software is needed when those already accept the credential. Otherwise use the desk or an explicit integration. C2 enrolment requires a native peer. Never let an unverified pairing code choose an arbitrary account.


## Lost or stolen

Device-specific keys make selective revocation possible in the native design.

1. **Recover access.** Use an already enrolled alternative or the provider’s verified recovery process.

2. **Revoke exposure.** Disable the lost credential at every affected provider, including queued offline readers.

3. **Enrol a replacement.** Bind a new credential, test access and issue confirmation through a trusted channel.


**Boundary:** Shared legacy codes or copied keys cannot distinguish lost and retained copies. Replace all exposed copies; offline revocation is not instant.


## Replace a device

A planned replacement should be quieter than a lost-device incident.

1. **Add the new device.** Authorise a separate new key or compatible identifier using an existing trusted session.

2. **Check continuity.** Verify that the new credential reaches the same local relationship and permissions.

3. **Retire the old one.** Remove it after a successful test; wipe or retire the old carrier securely.


**Boundary:** Parallel operation requires multi-credential support. A single-value backend needs a controlled switch and tested rollback.


## Use an existing card

Distinguish carrying an existing code differently from enrolling a new, user-owned credential.

1. **Check the route.** Ask whether authorised re-display or a new external value is permitted and technically supported.

2. **Copy or enrol.** Re-display an allowed optical code, or register a distinct compatible medium through staff.

3. **Test & retire.** Keep the old credential during testing where possible, then retire it deliberately.


**Boundary:** Re-displaying the same value is consolidation, not cryptographic ownership. Revoking that value also revokes every copy. No protected-card cloning is proposed.


## Temporary access

A forgotten device should not force a permanent replacement.

1. **Verify the request.** Staff confirm the account and why a temporary credential is needed.

2. **Set a narrow scope.** Issue time-limited access using the provider’s supported controls.

3. **Expire & audit.** Revoke or expire it and retain the appropriate audit record.


**Boundary:** Expiry must be enforced by the backend or reader, not merely printed on a card or shown on a phone.


## Without a phone

A smartphone cannot be the price of being a member.

1. **Choose a carrier.** Use an accepted passive card, a printed code where suitable, or the provider’s own token.

2. **Enrol with assistance.** Staff follow the same account-linking checks without requiring an app account.

3. **Keep a recovery path.** Explain lost-card handling, accessible alternatives and the limits of the chosen medium.


**Boundary:** A printed code cannot select different provider identities by itself. The future display token is not an available alternative today.


## Retract the BringPass enrolment

1. **Confirm the scope.** The holder requests withdrawal of all BringPass bindings at this provider, not cancellation of the underlying membership.
2. **Apply at the provider.** Existing staff/portal controls remove the bindings in C0/C1. A verified native RETRACT applies the equivalent change in C2. Retain unrelated credentials and the account.
3. **Confirm, then forget.** A verified result or independent legacy confirmation establishes the remote effect. A local delete alone does not.

**Boundary:** Copies of a shared legacy value cannot be distinguished. Full relationship retraction may require staff assistance when an existing portal has only single-card controls.

## End the underlying membership (separate from retraction)

Credential lifecycle and record-retention policy are separate decisions.

1. **Close the membership.** Apply the provider’s normal process for ending or suspending the relationship.

2. **Revoke credentials.** Remove access authorisations and synchronise reader caches as required.

3. **Handle retained data.** Process applicable access, deletion or retention duties using an authenticated channel.


**Boundary:** Deleting an entry from a wallet does not revoke provider-side access or erase the provider’s database.


## Operational invariants

Keep local account primary keys separate from credential values. A single-field backend may require a controlled cutover instead of parallel enrolment. Revocation must reach every relevant provider and offline cache. Deleting a wallet entry is not revocation. Shared copies of one legacy value or private key are not separately revocable.
## Retraction versus revocation

REVOKE disables one credential at a provider. RETRACT withdraws the holder’s entire BringPass relationship enrolment there, leaving the underlying account intact. Local PROFILE.REMOVE does neither. Service-desk and self-service paths, exact message fields and no-token recovery are defined in protocol.md.