Skip to main content
Each hop has its own credential. A credential authorizes that hop and no other. Identity providers are Keycloak-compatible OIDC: client credentials for services, and bearer tokens for callers of Token App. The token endpoint is {base}/realms/{realm}/protocol/openid-connect/token.
Ten messages in order. 1. Your service to Your identity provider: Client credentials. 2. Your identity provider to Your service: Token for the Token App audience. 3. Your service to Token App: Mint, Authorization Bearer. 4. Token App to Registry identity provider: Client credentials. 5. Registry identity provider to Token App: Token for the Registry admin audience. 6. Token App to Registry: Choice context. 7. Registry to Token App: Context. 8. Token App to Your identity provider: Client credentials for the ledger user. 9. Your identity provider to Token App: Ledger token. 10. Token App to Your participant: Submit as your admin.
Ten messages in order. 1. Your service to Your identity provider: Client credentials. 2. Your identity provider to Your service: Token for the Token App audience. 3. Your service to Token App: Mint, Authorization Bearer. 4. Token App to Registry identity provider: Client credentials. 5. Registry identity provider to Token App: Token for the Registry admin audience. 6. Token App to Registry: Choice context. 7. Registry to Token App: Context. 8. Token App to Your identity provider: Client credentials for the ledger user. 9. Your identity provider to Token App: Ledger token. 10. Token App to Your participant: Submit as your admin.
Wallets take a different path. A wallet calls the Registry public API with no credential, receives a choice context, and submits on the holder’s participant. The holder’s party authorizes that submission. The public API discloses the contracts the wallet needs. It does not grant the admin, the issuer, or the validator.

​
Credentials in the default deployment

GET /status uses the same bearer token as mint. History and marker queries do too.
Leave Token App authentication on. Turn it off only when the network path to the service is itself the trust boundary, and even then keep the service off the internet.

​
What your ledger user must be able to do

The ledger user is the identity the participant associates with Token App. It needs: The user is scoped to those parties. It is not granted a right to act as any party on the participant. Operators call Token App. They do not submit ledger commands themselves.

​
What the Registry credential does, and what it does not

The Registry checks the bearer token on /api/{prefix}/admin/**. A token whose audience is the configured admin audience is an admin caller. Token App presents that token and receives a choice context for the admin operation: mint, burn, pause, freeze, compliance burn, or seizure, wherever that operation needs a prepared context. The M2M token authorizes that fetch. Token App then submits the context on your participant, as the party you assigned, with the ledger user above. The Registry’s own ledger user reads as the observer and is not granted act-as on your parties. Public routes under /api/{prefix}/registry/** accept unauthenticated calls. They return instrument metadata and the contexts wallets submit. Health and the metrics endpoint are open for the operator of the Registry.

​
Three providers

When a party you control is hosted on a Cantor8-operated participant, the ledger provider may be Cantor8’s, and the client is still issued for your ledger user. You hold the key. Operating the node does not transfer it.

​
Keys

Your acting keys stay with you. Launch commands are handed to you to submit. A prepared command expires; sign the command you were sent for that step, and ask for a fresh one if the ledger has moved on.