BringPass
Reader test
Scan a real sample. Capture the exact bytes or string, leading zeros, separators and terminator. Test the physical surface, including a phone screen.
What works, and under which conditions
Compatible is a test result.
Compatible is a test result.
Not a blanket promise.
The carrier, reader, backend and enrolment policy must agree. “NFC” or “QR” on a box is not enough.
This release is a website and design package.
No reader driver, wallet app or card firmware is shipped. “Existing technology” below describes a reuse route, not out-of-the-box BringPass product support.
| Technology | Possible starting point | Condition / boundary | Security and change |
|---|---|---|---|
| Static barcode / plain QR | Authorised code re-display, or enrol a user-owned value. | Scanner accepts the symbology and surface; backend accepts format, range and uniqueness. Some optical readers do not read screens reliably. | No-change may be possible. Still a copyable bearer value. |
| Code 128 / Code 39 / EAN-style fields | Use only a documented, provider-approved encoding. | Respect character sets, check digits, prefixes and field lengths. Do not invent externally assigned numbers or truncate silently. | Resolve collisions at enrolment. No global uniqueness promise for small fields. |
| NFC serial / UID lookup | Enrol a compatible physical card through the normal workflow. | Frequency, protocol, UID length and reader output must match. 125 kHz proximity cards are not NFC. | Same UID is linkable. Phone HCE is not a drop-in stable UID. |
| Protected smartcard application | Provider provisions a compatible application with authorised keys. | Reader protocol, application layout, key ownership and credential policy must align. | Configuration, provisioning or integration. No key bypass or universal clone. |
| Dynamic / signed QR | Continue using an issuer’s authorised output, or integrate a verifier. | Changing the picture is not enough; the backend must understand and validate the payload. | Custom rotating proofs cannot be read by a static-value backend unchanged. |
| WebAuthn / passkeys | Use a provider portal’s native browser ceremony. | Relying-party scope, verified origin, challenge and account binding remain essential. | Web integration required. Does not automatically replace a door-reader protocol. |
| Native smartcard / NFC profile | Possible future secure-element application. | Provisioning, authenticated provider context, APDU profile and supported chips must be specified. | Logical native messages are drafted; a hardware-specific NFC/APDU binding is not implemented or standardised here. |
| Future electronic token | Dedicated display + secure element + physical controls. | Prototype, radio/display tests, energy budget, provisioning and recovery are still open. | Concept only. No price, availability or battery-life claim. |
References: Android HCE · W3C WebAuthn · Apple NFC & SE .
Mobile is not a universal card emulator
Display flexibility.
Display flexibility.
Radio constraints.
A phone can show different optical values without changing a reader that already accepts them. NFC support is narrower: Android HCE exposes supported ISO-DEP/APDU application exchanges; the presented UID must not be relied on as a stable identity.
Apple’s secure contactless interfaces have eligibility, entitlement and platform requirements. Check the intended use case and deployment region before committing to an iPhone implementation.
A passive smartcard can receive power from a reader. That does not mean every NFC tag can sign, import keys, run arbitrary applications or be reprogrammed. Select a chip and provisioning model before designing around it.
References: Android platform documentation · Apple platform requirements .
Test the whole path
Download the compatibility worksheet
Backend test
Enrol, detect a duplicate, authenticate, replace, revoke and roll back. Check limits on credentials per account and offline cache refresh.
Policy test
Confirm external media are permitted, access assurance is sufficient, staff have a fallback, and no security claim exceeds the actual mechanism.