DRAFT: Account Profiles Specification #782

Funkatronics · 2024-04-10T16:39:56Z

No description provided.

Funkatronics · 2024-04-10T17:21:02Z

spec/spec.md

@@ -416,6 +427,7 @@ where:
            "display_address_format": "<display_address_format>",
            “label”: “<label>”, 
            "icon": "<icon>",
+            "profile": "<account_profile_id>",


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 features parameter.

Alternatively, we could do the opposite. We could drop this new parameter in the spec, and instead use the existing features parameter. In the mobile SDKs, we could abstract this into an explicit profile parameter.

I'd put it into the features parameter.

sdlaver · 2024-04-10T23:34:20Z

spec/spec.md

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


WDYT about "should reject" -> "will reject"? This will restrict wallet behavior, to ensure uniformity amongst implementations.

sdlaver · 2024-04-10T23:38:55Z

spec/spec.md

@@ -416,6 +427,7 @@ where:
            "display_address_format": "<display_address_format>",
            “label”: “<label>”, 
            "icon": "<icon>",
+            "profile": "<account_profile_id>",


I'd put it into the features parameter.

sdlaver · 2024-04-10T23:45:44Z

spec/spec.md

+- `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).


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?

Funkatronics · 2024-04-15T20:17:24Z

spec/spec.md

@@ -139,6 +139,19 @@ These features are deprecated, but can be supported by wallet endpoints to maint

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

+## Account Profiles


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

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.

sdlaver · 2024-04-15T20:46:06Z

spec/spec.md

+  - 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. This profile is incompatible with the `immutable` profile, a fee payer account cannot be `immutable`. 
+- `mutable`


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

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.

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.

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

spec/spec.md

sdlaver · 2024-04-15T20:47:59Z

spec/spec.md

@@ -139,6 +139,19 @@ These features are deprecated, but can be supported by wallet endpoints to maint

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

+## Account Profiles


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.

sdlaver · 2024-04-16T02:56:57Z

spec/spec.md

@@ -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. 


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.

sdlaver · 2024-04-16T02:58:05Z

spec/spec.md

+  - 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. This profile is incompatible with the `immutable` profile, a fee payer account cannot be `immutable`. 
+- `mutable`


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.

sdlaver · 2024-04-16T02:58:29Z

spec/spec.md

@@ -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.


Is this mandatory or optional?

should be optional, for backwards compatibility. will update

Funkatronics added 2 commits April 10, 2024 10:39

add account profiles

11341b4

Update spec.md

2bd3057

Funkatronics commented Apr 10, 2024

View reviewed changes

Funkatronics requested a review from sdlaver April 10, 2024 18:18

sdlaver reviewed Apr 10, 2024

View reviewed changes

feedback/new ideas

12a0d38

Funkatronics commented Apr 15, 2024

View reviewed changes

Funkatronics added 2 commits April 15, 2024 14:19

tweaks

6f3c3b3

remove whitespace

37489b3

sdlaver reviewed Apr 15, 2024

View reviewed changes

Funkatronics added 2 commits April 15, 2024 15:51

add identity label

c5c462a

switch to labels

8d6d975

sdlaver reviewed Apr 16, 2024

View reviewed changes

feedback

181a169

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DRAFT: Account Profiles Specification #782

DRAFT: Account Profiles Specification #782

Funkatronics commented Apr 10, 2024

Funkatronics Apr 10, 2024 •

edited

Loading

Funkatronics Apr 10, 2024

sdlaver Apr 10, 2024

sdlaver Apr 10, 2024

sdlaver Apr 10, 2024

sdlaver Apr 10, 2024

Funkatronics Apr 11, 2024 •

edited

Loading

Funkatronics Apr 15, 2024

sdlaver Apr 15, 2024

sdlaver Apr 15, 2024

Funkatronics Apr 15, 2024

sdlaver Apr 16, 2024

Funkatronics Apr 16, 2024

sdlaver Apr 15, 2024

sdlaver Apr 16, 2024

sdlaver Apr 16, 2024

sdlaver Apr 16, 2024

Funkatronics Apr 16, 2024

		@@ -139,6 +139,19 @@ These features are deprecated, but can be supported by wallet endpoints to maint

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

		## Account Profiles

DRAFT: Account Profiles Specification #782

Are you sure you want to change the base?

DRAFT: Account Profiles Specification #782

Conversation

Funkatronics commented Apr 10, 2024

Funkatronics Apr 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Funkatronics Apr 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Funkatronics Apr 10, 2024 •

edited

Loading

Funkatronics Apr 11, 2024 •

edited

Loading