BringPass
Fewer things to carry
One credential set across participating organisations. Your choice of carrier.
Same you. More places.
Bring your own
Bring your own
credential.
Your gym. Your library. Your workplace.
Fewer cards to carry. Less for organisations to issue.
Open concept. Gradual adoption. No central identity hub.
One credential set.
Familiar places.
Gyms
Libraries
Workplaces
Clubs & loyalty
A smaller everyday burden
Less to carry.
Less to carry.
Less to administer.
Keep the account. Change who brings the credential. The organisation keeps its data and access rules; the person chooses a compatible carrier.
The case for bring-your-own
Less issuing. Less replacing.
Reduce avoidable media and fulfilment work—not the checks that keep access safe.
Separate relationships
Provider-specific identities in the native design. No global personal-data hub.
Adoption at your pace
Start where existing systems permit. Keep issued cards as a fallback.
Change one step, not everything
A route in.
A route in.
Not a rip-and-replace.
From a familiar scan at the front desk to a provider-bound cryptographic proof. Each route has a clear boundary.
C0
Reuse the existing credential
Select an authorised issuer code or compatible physical card. The provider need not know BringPass.
No native awareness
C1
Adapt on the token side
Match the approved value format or existing application. Enrol through the normal workflow.
Provider software unchanged
C2
Cooperate natively
Both peers implement authenticated proof and lifecycle messages. No mandatory web API.
Both sides implement
X
Recognise a blocked path
A missing medium, key or enrolment option is a real boundary. Ask for cooperation or use other media.
Not a silent fallback“No changes” only applies when the reader, backend and enrolment policy already accept the credential. A new protocol always needs integration.
Explore transition routes & processes
Choose the carrier
A card today.
A card today.
Your phone, too.
A token, one day.
No single device has to do everything. Combine familiar media with a future path to stronger authentication.
See the compatibility matrix
Barcode & QR
Existing technologyApproved formats for existing scanners. Static codes remain copyable.
Reusable smartcard
Compatibility-dependentTap compatible readers. Secure applications need a matching protocol.
Mobile wallet
Integration targetSelect codes and manage credentials. NFC is platform- and reader-specific.
Electronic token
Future concept · not availableA pocket display, physical controls and a secure element. No phone at every door.
One set of devices. Separate relationships.
Read the protocol draft
Associate a key or approved value with the existing account.
Link the credential.
Associate a credential with the provider’s existing account.
Present the expected value or native proof; the provider checks permission.
Present. Prove. Check.
Show a provider-specific value where the chosen medium supports it.
Disable the lost or replaced credential without breaking the others.
Retire one credential.
Verify possession against the enrolled key and a fresh challenge.
Withdraw this BringPass relationship, not the underlying account.
Withdraw the enrolment.
Keep the relationship. Revoke and replace its credentials.
The everyday scenarios
Familiar moments.
Familiar moments.
A different credential.
The exceptions matter as much as the first tap.
Same desk. A different question.
“Do you already have a compatible credential?” becomes part of enrolment.
Read the full process
01
Establish the account
Staff locate or create the local account and apply the existing identity checks.
02
Present your credential
Scan or tap a supported medium. Check the format and enforce uniqueness.
03
Link & test
Assign it, test a real transaction, and record what was enrolled.
C0/C1 need no provider software change only when the existing enrolment accepts the medium and value. C2 native proof requires implementation on both sides.
Add a credential from your account.
The organisation’s existing account remains the starting point—not an unverified QR code.
Read the full process
01
Sign in first
Use an authenticated account session, with step-up verification when required.
02
Prove & pair
Legacy: use the portal’s existing add-credential function, if available. Native: bind the registration challenge and new-key proof to the verified account session.
03
Confirm & notify
Show the account and credential; confirm the link, notify the user, and test.
No software change only if the portal already supports this enrolment. Otherwise use the service desk or add integration. An unverified code must never choose an arbitrary account.
Lose a device. Keep the relationship.
Device-specific keys make selective revocation possible in the native design.
Read the full process
01
Recover access
Use an already enrolled alternative or the provider’s verified recovery process.
02
Revoke exposure
Disable the lost credential at every affected provider, including queued offline readers.
03
Enrol a replacement
Bind a new credential, test access and issue confirmation through a trusted channel.
Shared legacy codes or copied keys cannot distinguish lost and retained copies. Replace all exposed copies; offline revocation is not instant.
Start with the card you already have.
Distinguish carrying an existing code differently from enrolling a new, user-owned credential.
Read the full process
01
Check the route
Ask whether authorised re-display or a new external value is permitted and technically supported.
02
Copy or enrol
Re-display an allowed optical code, or register a distinct compatible medium through staff.
03
Test & retire
Keep the old credential during testing where possible, then retire it deliberately.
Re-displaying the same value is consolidation, not cryptographic ownership. Revoking that value also revokes every copy. No protected-card cloning is proposed.
A shared lifecycle, not a new web service
One internal model. Two external paths.
Keep existing readers unchanged where they already accept the credential. Use the native protocol when both sides participate.
Protocol draft 0.3
13 languages · both sides
Four operations: register, use, revoke and retract. Transport and existing reader commands remain separate concerns.
Legacy · token-side only
PROFILE.IMPORT(approved_profile)
PROFILE.SELECT("library")
PROFILE.PRESENT()
// Existing scanner receives only:
00481720Native · both peers
provider → token: CHALLENGE(operation, context, nonce)
token → provider: PROOF(challenge, credential)
provider → token: RESULT(request, outcome, revision)
// REGISTER · USE · REVOKE · RETRACT
Future option · design study
A little less phone.
A little less phone.
A little more freedom.
A dedicated token could carry changing codes and native credentials—without becoming another general-purpose screen.
Selectable codes
Compatible NFC
Secure element
Explore the hardware concept
Not a product announcement. No prototype, price or release date.
Does it work with the readers we already have?
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.
Does everyone need a smartphone?
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.
Is BringPass one number that follows me everywhere?
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.
What happens when a card or phone is lost?
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.
Can we continue issuing our own cards?
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.
Is the special electronic token available?
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.
Start with a familiar reader.
Find one compatible workflow. Test it. Keep a fallback.