DRAFT: Account Profiles Specification #782
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -126,6 +126,17 @@ These features are mandatory and must be implemented by wallet endpoints. Dapp e | |
| - [`solana:signMessages`](#sign_messages) | ||
| - [`solana:signAndSendTransaction`](#sign_and_send_transactions) | ||
|
|
||
| #### Account Profiles | ||
|
|
||
| Account profiles are identifiers that are used to decribe an authorized account's capabilities. These are defined as feature identifiers for compatibiblity with the wallet-standard account features API. | ||
|
|
||
| - `solana:readOnly` | ||
| - A read-only account. These accounts should not be used as writeable accounts in transaction. These acounts may contain assets, but dapp endpoints should only expect to read from these accounts and prove ownership via a message sign. If a dapp requests a transaction signature from a readonly account, the wallet should reject the transaction. Read-only accounts are limited to the following features: [`solana:signMessages`](#sign_messages), `solana:signInWithSolana`. | ||
| - `solana:readWrite` | ||
| - An account that can be used as a writeable acount in transactions. Read-write accounts support, at a minimum, the following features: [`solana:signMessages`](#sign_messages), [`solana:signAndSendTransaction`](#sign_and_send_transactions). | ||
| - `solana:payer` | ||
| - An account that will be used to pay for transactions. Payer accounts support, at a minimum, the following features: [`solana:signAndSendTransaction`](#sign_and_send_transactions). | ||
|
There was a problem hiding this comment. Is this related to the concept of a fee payer (in the transaction sense), or to the concept of an account that should not be allowed to sign arbitrary messages? |
||
|
|
||
| #### Optional Features | ||
|
|
||
| These features are optional, wallet endpoints may choose to implement these features. Dapp endpoints can check if a wallet supports these features by calling [`get_capabilities`](#get_capabilities). | ||
|
|
@@ -416,6 +427,7 @@ where: | |
| "display_address_format": "<display_address_format>", | ||
| “label”: “<label>”, | ||
| "icon": "<icon>", | ||
| "profile": "<account_profile_id>", | ||
|
There was a problem hiding this comment. caveat here: adding this parameter to the account struct deviates from the wallet-standard Wallet Account API. To support this on the web we will need to map this profile id into the Alternatively, we could do the opposite. We could drop this new parameter in the spec, and instead use the existing There was a problem hiding this comment. I'd put it into the |
||
| "chains": ["<chain_id>", ...], | ||
| "features": ["<feature_id>", ...] | ||
| }, | ||
|
|
@@ -442,6 +454,7 @@ where: | |
| - `features`: (optional) a list of [feature identifiers](#feature-identifiers) that represent the features that are supported by this account. These features must be a subset of the features returned by [`get_capabilities`](#get_capabilities). If this parameter is not present the account has access to all available features (both mandatory and optional) supported by the wallet. | ||
| - `label`: (optional) a human-readable string that describes the account. Wallet endpoints that allow their users to label their accounts may choose to return those labels here to enhance the user experience at the dapp endpoint. | ||
| - `icon`: (optional) a data URI containing a base64-encoded SVG, WebP, PNG, or GIF image of an icon for the account. This may be displayed by the app. | ||
| - `profile`: the [account profile identifier](#account-profiles) for this account. Defaults to "solana:readWrite". | ||
| - `wallet_uri_base`: (optional) if this wallet endpoint has an [endpoint-specific URI](#endpoint-specific-uris) that the dapp endpoint should use for subsequent connections, this member will be included in the result object. The dapp endpoint should use this URI for all subsequent connections where it expects to use this `auth_token`. | ||
| - `sign_in_result`: (optional) if the authorize request included a [Sign In With Solana](https://siws.web3auth.io/spec) sign in payload, the result must be returned here as a value object containing the following: | ||
| - `address`: the address of the account that was signed in. The address of the account may be different from the provided input address, but must be the address of one of the accounts returned in the `accounts` field. | ||
|
|
||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WDYT about "should reject" -> "will reject"? This will restrict wallet behavior, to ensure uniformity amongst implementations.