Protocol · BringPass

Three boundaries. No universal middleman.

A

Local control

PROFILE.IMPORT → SELECT → PRESENT

The owner’s application manages profiles and key handles. These commands stay on the token side.

B

Legacy presentation

TOKEN → [existing value / exchange] → READER

Only the existing barcode, QR payload or NFC application exchange crosses this boundary. No BringPass envelope.

C

Native exchange

CHALLENGE → PROOF → RESULT

Cooperating peers authenticate the provider, prove control and confirm the exact lifecycle change.

The native exchange is optional. It does not sit between a legacy reader and its existing backend.

Who has to change something?

Class	Provider awareness	Token-side work	Provider-side impact
`C0` Existing credential	No native awareness	Select or reuse an authorised existing credential.	No provider software change. Existing policy still applies.
`C1` Token-side profile	Legacy reader stays unchanged	Match the approved format or existing application on the token side.	No provider software change. Normal enrolment and testing remain.
`C2` Native cooperation	Both sides understand the protocol	Exchange authenticated challenges, proofs and lifecycle receipts.	Both peers implement the protocol; reader hardware may be reusable.
`X` Blocked combination	No accepted credential path	Hardware, keys, application or enrolment policy do not fit.	Cooperation or different media required. Never silently claim C1.

These are compatibility classes, not security ratings. Report registration, use, revocation and retraction separately. “No awareness” is not the same as “cannot work”.

A profile chooses what to present.

The “internal protocol” is an owner-side contract between profile management, secure key storage and presentation drivers. It may be in one app or split between a management app and a card.

It selects a representation; it does not invent capabilities that the carrier lacks. Imported profiles are data, not arbitrary executable plug-ins.

PROFILE.SELECT("library")
PROFILE.PRESENT()

// Legacy scanner sees only:
00481720

PROFILE.IMPORT

Stage a bounded, owner-approved profile; validate format and provenance.

PROFILE.SELECT

Choose explicitly, or use a genuinely authenticated provider context.

PROFILE.PRESENT

Give the approved representation to the renderer or existing NFC driver.

PROFILE.SUSPEND

Stop local use. Other copies and a lost device are unaffected.

PROFILE.REMOVE

Forget locally. Do not report remote revocation without confirmation.

How does the token know which provider is asking?

Often it does not. A scanner supplies no authenticated identity; an NFC application identifier can be shared by many providers. Use explicit selection unless a binding really authenticates the provider. A fixed radio UID cannot become a different pairwise identifier merely because a profile changed.

Android HCE: application selection and UID constraints

Four operations. Different effects.


        REGISTER

Register a credential

Link a new key or approved legacy value to the provider’s existing account. Adding another device does not create another account.

USE

Use the relationship

Present or prove control. The provider still checks current membership and permission. A signature alone grants nothing.


        REVOKE

Disable one credential

Disable a lost, stolen or retired credential at this provider. Keep other distinct credentials and the relationship.


        RETRACT

Withdraw the enrolment

The holder withdraws the BringPass relationship at one provider. Disable its credentials, not the underlying account or unrelated issued cards.

Retraction is the proposed term for withdrawing this enrolment. It is not contract cancellation, account deletion or GDPR erasure. Local forgetting is a separate operation.

What actually crosses the boundary?

Compatibility Operation Management route

Message view · illustrative, no transaction is sent

OWNER → TOKEN    PROFILE.SELECT(library)
TOKEN → READER   00481720
DESK             Existing account checks, add-card, uniqueness, test.
                 No BringPass command reaches the reader.

Legacy registration still needs the provider’s normal enrolment step.

Native message contents

CHALLENGE  version · suite · operation · transaction · provider
           relationship · target · nonce · expiry · context

PROOF      same operation and transaction · relationship · credential
           target · hash(signed challenge) · new key only for REGISTER

RESULT     same operation and transaction · hash(signed proof)
           outcome · state · revision · effective scope

Authenticate the provider before revealing the relationship. Sign the whole challenge context. For use, verify the stored key—not a public key offered by the claimant. Bind the receipt to the exact request.

Same lifecycle. Two management routes.

Operation	Service desk	Self-service
`REGISTER`	Staff select and verify the account; read the value or start a native challenge; link and test.	Use an already authenticated account. Legacy enrolment works only if the existing portal already supports it; native enrolment binds the challenge to that session.
`USE`	Present the chosen credential; the provider performs the existing check or native proof verification.	No desk needed for normal use. Native user-presence or user-verification requirements follow the action’s policy.
`REVOKE`	Re-verify account authority, disable the precise lost binding and update readers through existing mechanisms. No signature from a lost card is required.	Use an independent enrolled credential plus management authority, or the provider’s verified recovery process. A USE-only key cannot authorise its own replacement.
`RETRACT`	Confirm the holder’s request and withdraw all BringPass bindings for this relationship. Preserve the account under existing rules.	Confirm the whole-relationship scope, wait for provider confirmation, then remove local profiles. An unavailable legacy portal means desk handling, not hidden automation.

Lost, exchanged or already issued?

Planned replacement: register a distinct new credential, test it, revoke the old one. Loss: first recover account authority and revoke exposure; then enrol a replacement. Existing optical card: authorised re-display may preserve its exact issuer value, but every copy shares the same revocation fate.

These steps repeat per affected provider. There is no central revocation service and no promise that offline readers immediately learn a change.

A readable contract, not a required web service.

Python and JavaScript include executable token and provider references for all four operations, real Ed25519 signatures and receipt/replay checks. Eleven further languages expose the same lifecycle through explicit verification and transaction ports.

Explore both sides Download the protocol draft Message schema Local profile contract

Security and implementation limits

The reference suite and byte encoding are experimental, not a universal smartcard profile. Pinning, account authority and local consent must come from trusted adapters. Production needs durable atomic state, reviewed device bindings, recovery and relay-risk controls. A signature is not proximity proof.

The samples acknowledge the authoritative online store only. They do not claim offline entitlement verification, instant revocation across readers, secure key erasure or completed hardware integration.

Cryptographic and platform references

One model inside. The reader’s language outside.