Credentials and application authorization

Credentials and application authorization

New applications pass an OperationAuthorizer to signing or decryption. The client does not hold a reusable logged-in session. Each callback receives the exact chain, registry, slot, action, payload, description and optional abort signal, and returns {token, verifierProofs} for that operation.

Create identities with tasra.identities.create(), issue holder-bound development credentials with tasra.credentials.issue(), and verify pins with tasra.credentials.verify(). Build the ordinary per-operation callback with:

import type {TasraClient, TasraIdentity, TasraWallet} from 'tasra-sdk/app'

export function authorizeHolder(tasra: TasraClient, creator: TasraWallet,
  identity: TasraIdentity, credential: string) {
  if (!tasra.verifierAgentUrl) throw new Error('Manifest lacks a verifier endpoint')
  return tasra.credentials.authorize({
    verifierAgentUrl: tasra.verifierAgentUrl, signer: creator.signer,
    identity, credentials: [credential],
  })
}

The SDK opens the operation-bound session, presents the credential and requires verifier membership proofs. Supply approve or presentation selection callbacks when the application needs a consent screen. Keep holder keys in the wallet context. The manifest’s endpoint is configuration, not proof of production provider approval.

Each invocation opens a new operation-bound session and presents the credential. The API does not promise that every token field changes between repeated operations: vp_hash is not a session identifier or a uniqueness check. When testing fresh wallet interactions, observe the session creation and presentation, alongside the SDK’s checks of operation binding and expiry; do not require unequal vp_hash values.

Use registeredWalletAuthorization when integrating an independently approved registered verifier agent or external wallet. It accepts the selected client, operation signer and present(session, signal) callback. Low-level OID4VP session helpers remain available for specialized integrations; do not rebuild their flow for an ordinary SDK application. Read tasra-oid4vp-wallet-and-verifier-agent.

Keep the identities separate

• The creator or approved delegate signs the operation request. Its EVM key is not the credential holder’s key and not the threshold slot’s signing key.
• The holder presents a credential using the key bound by its cnf claim. Alice’s presentation cannot supply Bob’s approval, even if both satisfy the same rule.
• The issuer signs credentials. A development issuer generated by the example is sufficient for local tests; Hovi/cloud enrollment is optional.
• Keepers jointly perform the authorized slot operation. Their threshold is not a number of required human approvals.

The application API requires a fresh holder_key grant bound to the expected slot and request hash. It checks identity binding for IBE, expiry and slot stability. The network still enforces cryptographic authorization. Never put presentations, grants, holder seeds or issuer keys in logs or a public verification bundle.

Expired authorization requires a fresh wallet flow. Refusal requires correcting the user’s policy/credential problem, not retrying with admin credentials or a legacy JWT. An already extracted IBE identity key outlives grant expiry; token revocation cannot erase that capability.

Existing sessions and other credential formats

If maintaining createTasraClient(...).openSession(...), read JWT sessions, renewals and holder proofs. Those capabilities remain available for deployments that support them. They are not the default deployment route and are never a fallback after a request-bound refusal.

OAuth/DPoP is a separate verifier-agent integration, not a SessionAuth variant; read the wallet skill’s advanced reference when that is the requested flow.