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.

Sign up for GitHub

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

DRAFT: Account Profiles Specification #782

Changes from 7 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
11341b4
add account profiles
Funkatronics Apr 10, 2024
2bd3057
Update spec.md
Funkatronics Apr 10, 2024
12a0d38
feedback/new ideas
Funkatronics Apr 15, 2024
6f3c3b3
tweaks
Funkatronics Apr 15, 2024
37489b3
remove whitespace
Funkatronics Apr 15, 2024
c5c462a
add identity label
Funkatronics Apr 15, 2024
8d6d975
switch to labels
Funkatronics Apr 15, 2024
181a169
feedback
Funkatronics May 7, 2024
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
17 changes: 17 additions & 0 deletions spec/spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -139,6 +139,21 @@ These features are deprecated, but can be supported by wallet endpoints to maint

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

## Account Labels

Account labels 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 labels. 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.
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd add some commentary here that wallets are encouraged to add labels, and that, when any labels are present, the wallet must fully label all returned accounts.


- `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.
- `identity`
- An account that contains the users preffered identity credentials. Identity accounts should be used for e.g sign in.
- `feePayer`
- Fee payer accounts, when present, should be used to pay for transaction fees. This profile is incompatible with the `immutable` profile, a fee payer account cannot be `immutable`.
- `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` and `feePayer` profiles, an immutable account cannot be `mutable` or `feePayer`.

## Transport

### WebSockets
Expand Down Expand Up @@ -416,6 +431,7 @@ where:
"display_address_format": "<display_address_format>",
“label”: “<label>”,
"icon": "<icon>",
"labels": ["<account_label>", ...],
"chains": ["<chain_id>", ...],
"features": ["<feature_id>", ...]
},
Expand All @@ -442,6 +458,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.
- `labels`: a list of [account labels](#account-labels) for this account.
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this mandatory or optional?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

should be optional, for backwards compatibility. will update

- `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