Skip to content

Latest commit

 

History

History
143 lines (109 loc) · 4.44 KB

icrc_27_accounts.md

File metadata and controls

143 lines (109 loc) · 4.44 KB

ICRC-27: Accounts

APPROVED EXTENDS 25

Authors: Thomas Gladdines

Summary

The purpose of the icrc27_accounts message is for the relying party to receive information about the identities managed by the signer.

Method

Name: icrc27_accounts

Prerequisite: Granted permission scope icrc27_accounts.

Scope (according to the ICRC-25 standard)

Scope: icrc27_accounts

Example Permission Request

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "icrc25_request_permissions",
  "params": {
    "scopes": [
      {
        "method": "icrc27_accounts"
      }
    ]
  }
}

icrc25_supported_standards

An ICRC-25 compliant signer must implement the icrc25_supported_standards method which returns the list of supported standards. Any signer implementing ICRC-27 must include a record with the name field equal to "ICRC-27" in that list.

Request Params

None

Example RPC Request

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "icrc27_accounts"
}

Result

accounts (vec): List of accounts.

  • owner (text): Principal (textual representation) used to derive the account identity.
  • subaccount (blob) (Optional): Subaccount bytes used to derive the account identity, this is 32 bytes as defined in the ICRC-1 ledger standard.

Example RPC Response

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": {
    "accounts": [
      {
        "owner": "gyu2j-2ni7o-o6yjt-n7lyh-x3sxq-zh7hp-sjvqe-t7oul-4eehb-2gvtt-jae",
        "subaccount": "FBEBG5Mrrn9HfX8UNL8pFwQV1hWz62YSCMxYAmNp8Sg="
      }
    ]
  }
}

Message Processing

  1. The relying party sends a icrc27_accounts request to the signer.
  2. Upon receiving the message, the signer first checks if it can process the message.
    • If the relying party has been denied the permission to invoke the method, the signer sends a response with an error back to the relying party. If the permission state is ask_on_use, the signer must prompt the user to either accept or deny this invocation. See permission states for more details.
  3. The signer MAY prompt the user to select which accounts to share.
    • If the signer prompts the user, it SHOULD do so for each request so that the relying party can offer the user the option to update / change the selection.
  4. The signer sends a response to the relying party with the list of accounts selected by the user.
sequenceDiagram
    participant RP as Relying Party
    participant S as Signer
    RP ->> S: Request accounts
    alt Scope `icrc27_accounts` not granted
        S ->> RP: Error response: Permission not granted (3000)
    else
        S ->> RP: List of accounts
    end
Loading

Errors

This standard does not define additional errors. See ICRC-25 for a list of errors that can be returned by all methods.

Supported token standards

To get a list of the token standards that the signer supports see the icrc25_supported_standards method in ICRC-25.

If a token standard is not returned in the icrc25_supported_standards method, the relying party SHOULD assume that the signer does not have the capability to show and transfer tokens of this token standard.

A relying party MAY only transfer unsupported tokens to a signer account if the relying party is at least able to offer the capability to show and transfer the tokens held by the signer account itself.