Overview
Privy resources, such as wallets and policies, are controlled by a user, an authorization key, or a key quorum. These are known as owners.
Owners have the ability to update a resource, such as updating the rules for a policy or updating the policies assigned to a wallet. Owners can also update the owner for a resource they control, enabling transfer of control over resources.
With wallets, owners also have the ability to take actions with the wallet, such as signing messages or sending transactions.
Privy also enables custom configurations of owners, so that you can configure different owners to have different permissions over resources. You can additionally update these owner configurations over time, given authorization from an existing owner, allowing you to update controls over resources as needed.
Learn more about three types of owners: users, authorization keys, and key quorums.
Users
Users of your application can own and take actions with wallets, and are represented by the Privy user ID. Users can be assigned to resources or can take actions with wallets by passing the user ID in the API request.
You can create user self-custodial wallets by setting a user as the owner of the wallet, whether you use your own existing authentication provider or Privy as your authentication provider.
Authorization keys
Authorization keys are a P256 cryptographic key that allow any party that controls the key to take actions from wallets. You can assign authorization keys to a resource or execute actions with authorization keys by signing the request with the respective private key.
Common examples of authorization keys include:
- app keys, which are controlled by your app’s server, and allow your app to execute requests
- passkeys, following the WebAuthn standard, which allow users to easily sign and execute requests with a P256 key
Key quorums
Owners can also be composed of a mix of users and authorization keys. This is known as a key quorum.
Key quorums have an authorization threshold that defines how many entities in the quorum must sign a request for the aggregated signature to be valid. You can use key quorums to implement use cases such as:
- Allowing users or apps to sign requests from user wallets
- Requiring both users and apps to sign requests from user wallets
- Requiring a distributed set of authorization keys to sign requests from a wallet
Key quorums are an advanced integration. To determine if key quorums are right for your use case, please reach out.