Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DRAFT: Account Profiles Specification #782

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions spec/spec.md
Original file line number Diff line number Diff line change
Expand Up @@ -139,6 +139,19 @@ These features are deprecated, but can be supported by wallet endpoints to maint

- [`solana:signTransactions`](#sign_transactions)

## Account Profiles
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this approach, I think it makes more sense to call these "Account Labels"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think account labels makes sense, adding context of when an account should be used. One potential one I see missing from this list is identity - an account that contains a users preferred identity credentials.


Account profiles are labels that are used to decribe an authorized account's capabilities and intended use. Each authorized account that is returned in [`authorize`](#authorize) request response can include a list of these profiles. The dapp endpoint can use these labels in combination with the account's list of [`features`](#feature-identifiers) to determine how each acount should be used.

- `primary`
sdlaver marked this conversation as resolved.
Show resolved Hide resolved
- The users primary account. This account will be used for sign in, and is expected to have the users primary assets.
- `feePayer`
- Fee payer accounts, when present, should be used to pay for transaction fees.
- `mutable`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need both mutable and immutable, or does the absence of one imply the other?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could go either way, I am not certain what is best. both have drawbacks I think

A) With both mutable and immutable, its more explicit. tho it also adds the incompatibilities (mutable and feepayer cannot also be immutable)

B) With only mutable, the absence would imply immutability. feePayer would imply mutable as well which makes sense. primary would not imply mutable, it would need to be specified.

C) With only immutable, the absence would imply mutability. feePayer would be incompatible with immutable as it would not make sense to have an immutable fee payer.

I am leaning towards option B here, only having mutable. primary (and identity) accounts imply immutability if not specified. feePayer and mutable would be allowed but redundant.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can think of one benefit for option C - if a wallet labels nothing. The default (and backward-compatible) behavior for an unlabeled account would be mutable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah thats a good point. gonna mull on this a bit more.

- A mutable account can be used as a writeable account in transactions and will allow transactions that change its state. This profile is incompatible with the `immutable` profile, a single account will never specify both `mutable` and `immutable` profiles.
- `immutable`
- An immutable account may be used as a read only account in transactions, but will not support transactions that attempt to change the accounts state. This profile is incompatible with the `mutable` profile, a single account will never specify both `mutable` and `immutable` profiles.

## Transport

### WebSockets
Expand Down Expand Up @@ -416,6 +429,7 @@ where:
"display_address_format": "<display_address_format>",
“label”: “<label>”,
"icon": "<icon>",
"profiles": ["<account_profile>", ...],
"chains": ["<chain_id>", ...],
"features": ["<feature_id>", ...]
},
Expand All @@ -442,6 +456,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.
- `profiles`: a list of [account profile](#account-profiles) labels for this account. Defaults to `[ "mutable", "feePayer" ]`.
- `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.
Expand Down