The useful questions.
Including the awkward ones.

Sometimes. An existing scanner must read the format, and the backend must accept and enrol the presented value. UID-only readers need compatible physical media; proprietary secured systems need vendor cooperation. A native protocol requires integration. Check the compatibility boundaries.

No. A compatible physical card can remain the everyday credential, with an organisation-issued fallback. A phone is useful for selecting different barcodes, managing relationships and recovery. The dedicated display token is only a future concept.

Not in the proposed native design. Each provider receives its own relationship identifier and credentials. Legacy reuse can still expose the same barcode, NFC UID, or other lower-layer identifiers. That trade-off must be explicit; pairwise keys alone cannot erase all tracking metadata.

Recover account authority through an enrolled alternative and the provider’s management policy, or through verified recovery. Revoke the lost credential at every affected provider. Offline readers may update later. The reference demonstrates local revocation; it does not implement real account recovery or a global revocation service.

Yes. Mixed operation is the intended transition: accept suitable user-supplied credentials and keep issuing cards when needed. Multiple concurrent credentials depend on the backend; a one-card field may require a cutover rather than parallel use.

No. It is an industrial-design concept, with no prototype, supplier, price, battery-life claim or release date. A low-power display, secure element, physical controls and NFC are design directions, not validated specifications.

A bilingual static website, faithful editable SVG artwork, a transport-independent protocol draft and paired examples. Python and JavaScript include local executable references; eleven other languages provide explicit integration ports. No production wallet, NFC driver or electronic token is supplied.

No. A static barcode remains a copyable bearer value. Re-displaying an authorised existing code may reduce physical cards, but does not change ownership, cryptography or the original provider’s rules. Only an integrated verifier can validate a new dynamic proof.

No. NFC is a family of technologies, not a universal emulation mode. Android HCE uses supported application protocols and should not be treated as a stable, programmable card UID. Apple access depends on platform eligibility and entitlements. See mobile limits.

They first authenticate to their existing provider account, then complete a provider-bound registration ceremony and confirm the new credential. A pairing code alone is not proof of the right account. This needs a supported account portal or an integration; it is not a zero-change feature.

The provider retains its local account, relationship data and authorisation policy. The user brings a presentation medium or authenticator. A valid signature proves key control, not an active membership, civil identity, payment, employment or permission to enter.

Some devices allow importing the same key, but sharing it means the provider cannot revoke only one copy. Separate device keys linked to a stable local relationship are the safer default proposed here. A global root or attestation identifier must not silently become a tracking number.

Static media can work wherever the existing system supports them. Native offline verification needs trusted reader keys, cached entitlements, replay protection, time or counter policy, and a bounded revocation delay. That profile remains open design work; no offline security is claimed by this preview.

Possibly. Count avoided media, fulfilment and genuinely avoided staff work, then subtract integration, licences, support and recovery costs. Membership checks and revocation do not disappear. The illustrative cost model uses editable assumptions, not measured results.

The native concept could authenticate an access or export request. A bare identifier must not authorise disclosure. A provider still checks the request, applicable rights and third-party data, and uses an authenticated or separately encrypted delivery channel. No data-rights API is implemented here.

No. The initial scope is membership and access credentials, not legal identity assurance, payment authorisation or a replacement for regulated identity systems. Future interoperability would need separate technical, commercial and legal work.

The concept does not require a global identifier registry or a central personal-data service. Providers retain their own records. Optional hosted services would need clearly defined responsibilities, export and exit routes; none is operating in this preview.

No. Protocol draft 0.3 includes executable Python and JavaScript references plus paired scaffolds in eleven other languages. Hardware, real account authentication and durable deployment remain separate work. Compatibility needs a named reader, firmware, backend and enrolment policy. No certification or security audit has been completed.

No. C0/C1 preserve the existing scanner or NFC exchange. Only the token-side profile changes. Native C2 specifies message semantics for both peers, not mandatory HTTP endpoints. Ordinary provider enrolment and revocation work still remain.

Not by itself. Local removal affects this wallet only. Revocation must disable the provider’s binding; retraction withdraws the entire BringPass relationship there. Wait for remote confirmation, and account for offline readers.

Not reliably. A plain scan or shared NFC application identifier is not an authenticated provider identity. Explicit selection is the fallback. A fixed card UID cannot become a different per-provider value through software alone.