# BringPass — bring your own credential

## One line
Your gym. Your library. Your workplace. Fewer cards to carry; less for organisations to issue.

## 30 seconds
BringPass proposes a transition from organisation-issued tokens to user-supplied
credentials. At a compatible front desk, the first step can be as simple as
registering a card someone already owns. Organisations keep their accounts, data
and access rules. People choose a compatible carrier; issued cards remain a fallback.

Native integrations could later add provider-specific identifiers, cryptographic
proof and device-level revocation. A dedicated electronic token is a future design
option—not an available product.

## For organisations
Reduce avoidable media, personalisation and fulfilment work without replacing the
account system just to test the idea. Cost savings depend on compatibility,
integration costs, adoption and the staff work actually avoided.

## For individuals
Carry a smaller credential set. Keep the option of a passive card or a phone.
Separate relationships by default in the native model, with explicit legacy
limitations instead of a hidden universal tracking identifier.

## Compatibility, not security levels
C0: reuse an accepted credential or authorised optical code; no native awareness.
C1: an owner-side profile matches the approved value or existing application;
ordinary provider enrolment remains, but provider software need not change.
C2: both peers implement a reviewed native exchange and lifecycle integration.
X: that medium, reader, application or enrolment policy is blocked; do not promise
zero-change support. A bridge is an optional integration, not a compulsory stage.

## Protocol in one sentence
Local profile commands stay with the owner; legacy readers see their unchanged
standard/application exchange; native peers exchange signed challenges, proofs
and results for REGISTER, USE, REVOKE and RETRACT, without a mandatory web API.

## The honest boundary
No universal NFC emulation. No promise that every scanner accepts a phone screen.
No security upgrade from copying a barcode. No zero-change deployment unless the
existing enrolment workflow already permits the medium and value. No released
wallet, native identity backend, reader driver or token firmware is included.

## First experiment
Choose one reader, one provider workflow and a reversible pilot. Measure read
success, staff work, replacement, revocation and avoided issuances. Keep a fallback.