Teams and delegations
Team membership
Select a profile and open Team at /account/{bapId}/team. The UI lists members and invitations and supports role management through Better Auth organizations. Roles include owner, admin, and member. Invitation recipients use /accept-invitation; an email invitation is not a transfer of the organization's private key.
Organization APIs live under /api/auth/organization/*; use the generated API reference for invitation, membership, role, and permission schemas. The profile/organization association and membership checks determine which team a caller can manage.
Signed delegations
The Delegations page at /account/{bapId}/delegations manages a separate certificate lifecycle. Membership alone is not a signed BRC delegation, and a delegation cannot bypass account or wallet checks.
- The principal wallet creates and signs a delegation certificate for the member's bound wallet key.
- The owner submits the certificate and subject keyring through the wallet-authenticated intake route with the owner account session.
- Sigma stores encrypted fields in
awaiting_revelation; this state authorizes nothing. - The member takes wallet custody and reveals the required field keys to Sigma using the revelation endpoint.
- Sigma validates the revealed terms and lifecycle before treating the delegation as usable.
The server does not hold the principal's signing key. Do not ask the owner to upload it. A principal's keyring cannot substitute for the member's required revelation step.
API surfaces
| Route | Access and purpose |
|---|---|
GET /api/organizations/{bapId}/delegations | Members; owners see all organization delegations, other members see their own |
POST /api/organizations/{bapId}/delegations | Owner session plus principal BRC-103/104 wallet proof; record an already-signed certificate |
GET /api/organizations/{bapId}/delegations/mine | Member's custody/revelation workflow |
POST /api/organizations/{bapId}/delegations/{serialNumber}/revelation | Required member wallet proof and revelation |
POST /api/organizations/{bapId}/delegations/{serialNumber}/revoke | Authorized revocation workflow |
POST /api/brc169/delegations/verify | Verify submitted delegation evidence under the route's contract |
Intake requires memberId, certificate, subjectKeyring, and wildcardConfirmed; use the first-party wallet flow to construct these correctly. Do not manufacture certificate ciphertext or treat a serial number as proof.
Scope, expiry, and revocation
Use the narrowest supported scope and finite expiry. Review wildcard authority explicitly. Removing a member or changing their role invalidates the applicable delegation lifecycle; wallet revocation can still require follow-through. A pending revocation is not the same as a chain-confirmed spend, and revocation cannot erase previously shared data.
Wallet custody and deployment prerequisites can leave actions unavailable. See wallet credentials for certificate boundaries and agents for agent-specific identity binding and enforcement.