CAIP-282 - Browser Wallet Messaging Interface #282

pedrouid · 2024-05-30T17:53:05Z

Standardized messaging for wallet interface in browser environments.

update main

CAIPs/caip-282.md

Co-authored-by: Chris Smith <[email protected]>

…om/pedrouid/CAIPs into browser-wallet-messaging-interface

CAIPs/caip-282.md

Co-authored-by: Derek <[email protected]>

obstropolos

A number of feedback across the spec - nothing too deep other than just a few consistency items / etc.

CAIPs/caip-282.md

Co-authored-by: Gregory Rocco <[email protected]>

CAIPs/caip-282.md

pedrouid · 2024-06-24T22:21:47Z

Just sharing here some developments on this CAIP... after discussing it with several teams who gave very valuable feedback

The interfaces have been changed to follow a JSON-RPC structure to make it more agnostic and easier to use with multiple transports
Enforcing window.postMessage makes this CAIP not very future-proof as Chrome Extensions are slowly migrating to externally_connectable
This CAIP is more useful if it does NOT describe the actual transport and instead focuses on the discovery interfaces
The usage of window.postMessage without mentions of targetOrigin creates huge security concerns

What are the next steps?

a. Separate window.postMessage from discovery interface into two CAIPs
b. Create a new CAIP which uses the discovery interface with externally_connectable
c. Create a new CAIP which uses the discovery interface with window.dispatchEvent

What is the end goal?

This CAIP intends to provide the most agnostic and interoperable interface for wallet discovery and consequentally handshake and signing.

Since CAIP-25 and CAIP-27 already describe handshake and signing then CAIP-282 will focus purely on discovery

Why create separate CAIPs for each transport?

These additional CAIPs are important for Apps and Libraries to support multiple wallet transports... most importantly the following:

window.postMessage for embedded wallets with iframes
window.dispatchEvent for legacy browser extension support
externally_connectable for newer browser extension support

The combination of all JSON-RPC interfaces and different transport specs will any wallet to be discoverable, connect and sign with a decentralized application for all CAIP compatible chains

pedrouid · 2024-06-26T22:28:41Z

This PR now includes 3 proposals:

CAIP-282 -> Browser Wallet Discovery Interface
CAIP-294-> Browser Wallet Messaging for Extensions (window.dispatchEvent)
CAIP-295 -> Browser Wallet Messaging for Iframes (window.postMessage)

Still missing another standard to be included in this PR:

CAIP-296 -> Browser Wallet Messaging for Extensions (externally_connectable)

mcintyre94 · 2024-07-01T10:31:31Z

CAIPs/caip-282.md

+
+The parameters `name` and `icon` are used to display to the user to be easily recognizable while the `rdns` and `uuid` are only used internally for de-duping while they must always be unique, the `rdns` will always be the same but `uuid` is ephemeral per browser session.
+
+The only optional parameter is `scps` which is defined by CAIP-217 authorization specs that enables early discoverability and filtering of wallets based on RPC methods, notifications, documents and endpoints but also optional discovery of supported chains and even accounts.


Nit: I think this should be scopes

mcintyre94 · 2024-07-01T10:34:17Z

CAIPs/caip-282.md

+}
+
+
+// Example for wallet_prompt


Nit: I think this should be Example for wallet_announce

Good catch... fixed

mcintyre94 · 2024-07-01T10:36:20Z

CAIPs/caip-282.md

+
+## Privacy Considerations
+
+Any form of wallet discoverability must alwasys take in consideration wallet fingerprinting that can happen by malicious webpages or extensions that attempt to capture user information. Wallet Providers can abstain from publishing "Announce" messages on every page load and wait for incoming "Prompt" messages. Yet this opens the possibility for race conditions where Wallet Providers could be initialized after the "Prompt" message was published and therefore be undiscoverable. It is recommended that Wallet Providers offer this more "private connect" feature that users only enable optionally, rather than set by default.


Typo: alwasys -> always
Maybe also "always take into consideration"?

mcintyre94 · 2024-07-01T10:41:53Z

CAIPs/caip-282.md

+
+#### Discovery
+
+Both Wallet Providers and blockchain libraries must listen to incoming messages that might be published after their initialization. Additionally both Wallet Providers and blockchain libraries must publish a message to both announce themselves and their intent to connect, respectively.


Does this specific CAIP only deal with wallets that announce themselves after the blockchain library loads and can receive wallet_announce messages?

The wallet WILL announce itself in two instances:

when it loads

when it receives a wallet_prompt message

This prevents any async problems that might arise from wallet and library to load at different stages

This pattern is inspired by the work done by EIP-6963:
https://eips.ethereum.org/EIPS/eip-6963#window-events

mcintyre94 · 2024-07-01T10:53:41Z

CAIPs/caip-294.md

+// Blockchain Library starts listening on init
+window.addEventListener("caip294:wallet_announce", (event) => {
+  // when an announce message was received then the library can index it by uuid
+  wallets[event.detail.params.uuid] = {
+    params: event.detail.params,
+    eventName: event.detail.params.uuid
+  }
+});


Similar question here - how does this handle a wallet that has already announced itself before the page has loaded the blockchain library?

In wallet-standard we have a wallet-standard:app-ready event that the wallet attaches a listener for. This avoids the need for the wallet to re-announce itself every time a prompt is made.

I guess the tradeoff here is that you can do filtering in the wallet_prompt event with this design, instead of the app receiving all wallets and having to do its own filtering.

But I do think it's really important that an app can extremely quickly know all the available wallets. If an apps wants to eg autoconnect (or at least display data from) a remembered previously connected wallet, then any time you don't know if that wallet is available worsens the UX there.

mcintyre94 · 2024-07-01T11:06:08Z

CAIPs/caip-294.md

+
+#### Handshake
+
+After the wallet has been selected by the user then the Blockchain Library MUST publish a message to share its intent to establish a connection. This can be either done as a [CAIP-25][caip-25] request.


We've been questioning this a bit with wallet-standard. Generally a wallet will allow a user to authorise some set of accounts for a dapp. It'll then make those available as accounts on the wallet object (or here the scopes object mentioned in caip-282). From the dapp's perspective, the user selecting that wallet (or the dapp selecting it for them) decides which accounts/features/chains/etc are available to it. But for the wallet, it only needs to care about a connection when it needs to change those scopes. That doesn't necessarily have to happen every time the user selects the wallet in an app.

mcintyre94 · 2024-07-01T11:09:25Z

CAIPs/caip-294.md

+
+#### Handshake
+
+After the wallet has been selected by the user then the Blockchain Library MUST publish a message to share its intent to establish a connection. This can be either done as a [CAIP-25][caip-25] request.


Nit: I think the second part of the either is missing

mcintyre94 · 2024-07-01T11:36:36Z

CAIPs/caip-294.md

+        // prompt user to approve session
+    }
+  }
+});


Could a different wallet 'hijack' these events? Eg if I'm a wallet, can I send a wallet_prompt message in the app, capture the response, find the current UUID of Metamask, and then listen to its events to eg. also display my own popup?

With wallet-standard we don't use event listeners to send messages to the wallet after discovery. Each Wallet has its own code (exposed as features), and once a wallet has been chosen you're just calling functions of that object. No other wallet can see what's going on there or inject itself into the events.

kewde · 2024-07-02T09:57:43Z

CAIPs/caip-282.md

+
+#### UUIDs
+
+The generation of UUIDs is crucial for this messaging interface to work seamlessly for the users.


Can we explain why are uuid's crucial?

UUID is local and ephemeral

RDNS is global and permanent

The two identifiers together allow wallets to be identifiable but also de-duplicated if necessary

Either one by itself would not meet those requirements

kewde · 2024-07-02T11:13:00Z

CAIPs/caip-295.md

+
+## Simple Summary
+
+CAIP-295 defines a standardized messaging transport for browser iframe wallets.


Is there a demand for supporting iframes from the dApp side?

I'm not sure which wallets currently support iframes. I know there are some limitations on react-native-webview (typically used in mobile wallet dApp browser) that doesn't support injecting JS into the iframes on iOS.

I know this is common for session based wallets and believe gnosis safe uses this approach too. I think this is going to become more common as well where iframes are going to contain the DApp logic on web2 pages kind of like what we're seeing blinks do, so it makes sense to make this stuff work with iframes when possible.

CAIPs/caip-282.md

kewde · 2024-07-02T11:20:53Z

CAIPs/caip-282.md

+interface WalletAnnounceRequestParams {
+  uuid: string;
+  name: string;
+  icon: string;


Can we specify the allowed formats and URI?

export type WalletIcon = `data:image/${'svg+xml' | 'webp' | 'png' | 'gif'};base64,${string}`;

Is what wallet standard recommends, I think the data URIs should be the mandatory format.

Do we want to allow or specifically forbid remote images?

Actually yes... that is missing here!

We definitely want to forbid remote images

kewde · 2024-07-02T11:31:10Z

CAIPs/caip-294.md

+
+## Security Considerations
+
+TODO


I think it's worth noting that a malicious wallet may be eavesdropping on the traffic of the other wallets by using it's uuid and racing to reply, essentially hijacking/mimicking the wallet.

Legacy injection

As a wallet you could attach the object to the window in a permanent way, window.mywallet which would become irreplaceable and undeleteable, providing a stronger security guarantee that the wallet you're talking with is the same one. It, ofcourse, doesn't guarantee authenticity of the wallet but it's at least consistent.

Object.defineProperty(window, 'mywallet', { value: provider, writable: false, configurable: false; });

wallet standard

In wallet-standard, there are more guarantees at this level, since:

extension can create frozenWallet object, preventing tampering if done sensibly

once an extension announced its Wallet, the application is responsible for tracking the object collection

i remember @kdenhartog discussing at length the pros and cons (more like, limitations) of prototype freezing in the context of JS/ECMAScript/browser security over the years when EIP-6963 was being debated... it might still be worth mentioning that other cross-chain standards use a freezing approach, but i think it's a legacy thing anyways since a communication channel outside the page is what wallets are already migrating to which sidesteps the issue.

kewde · 2024-07-02T12:30:17Z

CAIPs/caip-282.md

+```typescript
+// for "wallet_prompt" method
+interface WalletPromptRequestParams {
+  chains?: string[]; // compatible with CAIP-2


The behavior for chains is undefined, should a wallet only reply if it has a chain in this list?

Well we can't guarantee that behavior ALWAYS

If the wallet announces itself before the library is able to send wallet_prompt message then it can't evaluate the chains

But if the wallet does receive the wallet_prompt and chains field is specified then it would make sense to not announce itself

Should we clear that up by putting it in the specification?

Would networks be a more generic and flexible term here?

I'm not sure networks would be helpful since everything is a network when we are talking about the internet

Here we are referring to Blockchain Networks defined by CAIP-2 identifiers

see next comment

Co-authored-by: kewde <[email protected]>

CAIPs/caip-282.md

kdenhartog

few comments, I need to do a couple of passes on this to make sure I'm fully digesting it but just wanted to get these comments in there early.

kdenhartog · 2024-07-11T22:21:18Z

CAIPs/caip-282.md

+
+## Motivation
+
+Currently, in order for Decentralized Applications to be able to support all users they need to support all browser wallet APIs. Similarly, in order for browser wallets to support all Decentralized Applications they need to support all APIs. This is not only complicated but also results in a larger bundle size of applications.


Currently, in order for Decentralized Applications to be able to support all users they need to support all browser wallet APIs.

This is unclear since not all DApps need to use all browser wallet APIs. Should it be that "...for all wallets to be able to support all DApps..."?

kdenhartog · 2024-07-11T22:25:14Z

CAIPs/caip-282.md

+
+```typescript
+// Defined by CAIP-217
+interface AuthorizationScopes {


Do we need to freeze these in some way to prevent privilege escalation attacks? E.g. it seems like we'd want this to be set and enforced wallet side and to not allow the site or other extensions to further escalate the authorization permissions defined here.

Yes but at the same time... is this something that should be defined on the CAIP-282 for the RPC spec or should it dependent on each transport spec such as CAIP-294, CAIP-295 or CAIP-296

Hmm, I'm not familiar with the delineation between the two or how we're splitting them. I hadn't caught those details when reviewing this. Do we expect to ever have a transport method that doesn't rely on browser JS ever to communicate between a page? If not, then it seems like a common point shared between the various transport methods would be useful and reinforced in the specs as well.

kdenhartog · 2024-07-11T22:30:26Z

CAIPs/caip-282.md

+
+A UUID can be re-used as a `sessionId` if and only if the [CAIP-25][caip-25] procedure has been prompted to the user and the user has approved its permissions to allow the application to make future signing requests.
+
+Once established, the UUID is used as `sessionId` for the [CAIP-27][caip-27] payloads, which can verify that incoming messages are being routed through the appropriate channels.


I think this might open the door to steal a UUID as an object capability to privilege escalate a page by using an incorrect UUID on a different page so that the new page can have the privileges of the UUID of the old page. It's hard to tell based on the spec, but is likely something we should be paying attention to in implementations so should have some form of wording for it on the spec if my understanding isn't off here.

Actually there have been discussions on the RPC working group to make this sessionId optional since it can be fixed for each wallet

Plus it's not necessarily required for all transports

When I wrote this I was thinking more along the context of WalletAnnoucementRequestParams.UUID property. I'm not following why a sessionId would be fixed either so I'm likely missing some context here.

kdenhartog · 2024-07-11T22:59:19Z

CAIPs/caip-294.md

+    sessionId: walletData.uuid,
+    scope: "chain:777",
+    request: {
+      method: "chain_signMessage",


I'm starting to wonder if we should move away from using RPC methods and RPCs as an interface here. More often than not RPCs are blockchain specific logic which doesn't necessitate it being accessible to the page. In many cases too, the RPC calls aren't actually "remote" in any way either because the wallet is handling them. Would it make sense to encapsulate logic here inside the wallet so that chain specific logic doesn't necessitate page specific logic based on the chain in use?

It depends on your definition of remote... because the idea of CAIP-282 is that it standarizes communication for all transports

That might be window.dispatchEvent, window.postMessage, externally_connectable, etc

Therefore there is always a concept of communication between a webpage and an external party that is remote to the webpage itself

I would not consider remote to be exclusively server-side or onchain

That makes sense, I wasn't thinking of them as exclusively as server-side/onchain either. Instead, I was thinking about it more within the context of the different software boundaries that exist and whether we should be leaking them/collapsing them and when.

For example, a page typically interacts with a remote client acting on behalf of the user (say for permission to sign or to retrieve their data) and needs some transport interface to perform that interaction. In most cases, we expect that the page will communicate client via this transport, but because we're utilizing RPCs that don't really align the permissioning model with this (since chains have different privacy models often) we end up in certain scenarios where the page may choose to bypass interacting with the client and retrieve information directly from the chain instead.

In my mind, this creates a more complex interaction model where it's not clear when the page-client interaction model is expected if the page can access the information itself via the chain which will probably produce odd side effects in a cross chain model.

For this reason, I think it be useful for us to not leak chain specific RPCs to the page and instead should be establishing an encapsulation pattern where the page uses the interface which encapsulates blockchain specific RPC logic away from the page rather than directly calling the RPC methods.

This encapsulation will help with creating a clear interface of reusable patterns to define application logic between the client and page across different blockchain ecosystems such that we can operate under the heuristic of "if the page wants the clients data it should go to the client to get it". Now, I can think of cases where this won't universally apply so I'm not sure it's the cleanest heuristic, but it does seem to be a good practice so that we can establish patterns of reuse between the client and page and make it easier for pages to interact.

kdenhartog · 2024-07-11T23:01:14Z

CAIPs/caip-295.md

+
+## Simple Summary
+
+CAIP-295 defines a standardized messaging transport for browser iframe wallets.


I know this is common for session based wallets and believe gnosis safe uses this approach too. I think this is going to become more common as well where iframes are going to contain the DApp logic on web2 pages kind of like what we're seeing blinks do, so it makes sense to make this stuff work with iframes when possible.

adonesky1 · 2024-07-17T20:44:49Z

CAIPs/caip-294.md

+window.dispatchEvent(new CustomEvent(
+  "caip294:wallet_prompt",
+  {
+    detail: {
+      id: 1,
+      jsonrpc: "2.0"
+      method: "wallet_prompt",
+      params: {
+        // optionally the Blockchain Library can prompt wallets to announce matching only the chains
+        chains: []  // optional
+        //  if the Blockchain Library supports CAIP-275 then it can include a name
+        authName: "", // optional
+      },
+    }
+  }
+));


Just a note I have a related CAIP that is specifically handling the case of discovery when the wallet's API is delivered via externally_connectable. Since in this case the dapp will need the extensionId in order to establish a channel of communication with the wallet, the extensionId is a critical piece of data for us to announce in this event. Perhaps it makes sense to merge this in as an optional param to this CAIP with some of the language from my CAIP to explain its use.

Should this new proposal be labelled as CAIP-296 which uses externally_connectable as a transport for CAIP-282 discovery??

#296

merged/addressed here: bc49428

shanejonas · 2024-07-29T16:11:06Z

CAIPs/caip-282.md

+```typescript
+// for "wallet_prompt" method
+interface WalletPromptRequestParams {
+  chains?: string[]; // compatible with CAIP-2


in caip-25 this is now called scopes

Suggested change

chains?: string[]; // compatible with CAIP-2

scopes?: string[]; // compatible with CAIP-2

good catch, i think it's chains in pedro's prod implementation 😅

bumblefudge · 2024-06-03T14:49:58Z

CAIPs/caip-282.md

+
+#### Connection
+
+After the wallet has been selected by the user then the blockchain library MUST publish a message to share its intent to establish a connection. This can be either done as a [CAIP-25][caip-25] request or [CAIP-222][caip-222] authentication.


This "can be either" as in MUST be one of? Or MAY be one, the other, some future third thing, or some fourth thing that already exists but we discourage? Probably worth being very explicit here.

Another complication that comes to mind is fallbacks, i.e. if a wallet prefers 222, but falls back to 25 after 222 times out or otherwise fails; probably worth expressing the intent to connect as a sequence of requests and responses eventually ending in success or failure rather than as a single message, if that sidesteps the enumeration of valid message types.

CAIPs/caip-282.md

bumblefudge · 2024-08-15T09:36:00Z

CAIPs/caip-294.md

+
+## Security Considerations
+
+TODO


i remember @kdenhartog discussing at length the pros and cons (more like, limitations) of prototype freezing in the context of JS/ECMAScript/browser security over the years when EIP-6963 was being debated... it might still be worth mentioning that other cross-chain standards use a freezing approach, but i think it's a legacy thing anyways since a communication channel outside the page is what wallets are already migrating to which sidesteps the issue.

bumblefudge · 2024-08-15T09:37:45Z

apologies, pedro, my june comments were sitting in github UI limbo waiting to be batched to a complete review 🙄

Add `extensionId` property to `wallet_announce` params object for `externally_connectable`

pedrouid added 3 commits May 28, 2024 14:38

Merge pull request #7 from ChainAgnostic/main

9ac3552

update main

add caip

8d509b6

add caip number, discussions and update created date

f0fe3c2

pedrouid changed the title ~~Browser wallet messaging interface~~ CAIP-282 - Browser Wallet Messaging Interface May 30, 2024

...

b051f62

chris13524 reviewed May 30, 2024

View reviewed changes

CAIPs/caip-282.md Outdated Show resolved Hide resolved

chris13524 reviewed May 30, 2024

View reviewed changes

CAIPs/caip-282.md Outdated Show resolved Hide resolved

chris13524 reviewed May 30, 2024

View reviewed changes

CAIPs/caip-282.md Outdated Show resolved Hide resolved

pedrouid and others added 4 commits May 30, 2024 13:34

Update CAIPs/caip-282.md

e41796a

Co-authored-by: Chris Smith <[email protected]>

Update CAIPs/caip-282.md

7a81a4c

Co-authored-by: Chris Smith <[email protected]>

update event names

9fe4147

Merge branch 'browser-wallet-messaging-interface' of https://github.c…

3ef35dd

…om/pedrouid/CAIPs into browser-wallet-messaging-interface

obstropolos requested review from obstropolos and bumblefudge May 30, 2024 20:15

arein reviewed May 30, 2024

View reviewed changes

CAIPs/caip-282.md Outdated Show resolved Hide resolved

bumblefudge reviewed Jun 3, 2024

View reviewed changes

CAIPs/caip-282.md Show resolved Hide resolved

pedrouid and others added 8 commits June 6, 2024 13:39

Update CAIPs/caip-282.md

6ac99d4

Co-authored-by: Derek <[email protected]>

Update CAIPs/caip-282.md

42c645c

Co-authored-by: Derek <[email protected]>

Update CAIPs/caip-282.md

4986b61

Co-authored-by: Derek <[email protected]>

Update CAIPs/caip-282.md

0869e0d

Co-authored-by: Derek <[email protected]>

add missing sections

f076f22

add test cases

eb13968

tweak

1cb66fd

Update CAIPs/caip-282.md

46c13a6

Co-authored-by: Derek <[email protected]>

obstropolos requested a review from bumblefudge June 6, 2024 23:21

obstropolos reviewed Jun 6, 2024

View reviewed changes

pedrouid and others added 3 commits June 7, 2024 15:40

Update CAIPs/caip-282.md

d2254ba

Co-authored-by: Gregory Rocco <[email protected]>

Update CAIPs/caip-282.md

9f5029f

Co-authored-by: Gregory Rocco <[email protected]>

Apply suggestions from code review

d0562ea

Co-authored-by: Gregory Rocco <[email protected]>

clean up and introduction of CAIP-217 scopes

2eb5f0c

Gudahtt reviewed Jun 17, 2024

View reviewed changes

CAIPs/caip-282.md Outdated Show resolved Hide resolved

Gudahtt reviewed Jun 17, 2024

View reviewed changes

CAIPs/caip-282.md Outdated Show resolved Hide resolved

shanejonas reviewed Jun 19, 2024

View reviewed changes

CAIPs/caip-282.md Outdated Show resolved Hide resolved

pedrouid added 2 commits June 21, 2024 19:05

WIP

19a443c

move to jsonrpc

f2389e8

pedrouid added 2 commits June 26, 2024 22:19

add separate caips for extensions and iframes

b6ced5c

dispatchEvent and postMessage

630a3e1

update dates

c2b6ff0

mcintyre94 reviewed Jul 1, 2024

View reviewed changes

kewde reviewed Jul 2, 2024

View reviewed changes

Update CAIPs/caip-282.md

3ea7bde

Co-authored-by: kewde <[email protected]>

pedrouid commented Jul 2, 2024

View reviewed changes

CAIPs/caip-282.md Outdated Show resolved Hide resolved

Update CAIPs/caip-282.md

374e710

pedrouid commented Jul 2, 2024

View reviewed changes

CAIPs/caip-282.md Outdated Show resolved Hide resolved

Update CAIPs/caip-282.md

0f17dd3

pedrouid commented Jul 2, 2024

View reviewed changes

CAIPs/caip-282.md Outdated Show resolved Hide resolved

Update CAIPs/caip-282.md

c1e833f

kdenhartog reviewed Jul 11, 2024

View reviewed changes

adonesky1 reviewed Jul 17, 2024

View reviewed changes

shanejonas reviewed Jul 29, 2024

View reviewed changes

add extensionId for externally_connectable

02f119f

bumblefudge reviewed Aug 15, 2024

View reviewed changes

bumblefudge mentioned this pull request Aug 15, 2024

CAIP-X - Browser Extension Wallet Discovery over externally_connectable #308

Closed

Merge pull request #8 from adonesky1/ad/caip-294-externally_connectable

bc49428

Add `extensionId` property to `wallet_announce` params object for `externally_connectable`


		The parameters `name` and `icon` are used to display to the user to be easily recognizable while the `rdns` and `uuid` are only used internally for de-duping while they must always be unique, the `rdns` will always be the same but `uuid` is ephemeral per browser session.

		The only optional parameter is `scps` which is defined by CAIP-217 authorization specs that enables early discoverability and filtering of wallets based on RPC methods, notifications, documents and endpoints but also optional discovery of supported chains and even accounts.


		## Privacy Considerations

		Any form of wallet discoverability must alwasys take in consideration wallet fingerprinting that can happen by malicious webpages or extensions that attempt to capture user information. Wallet Providers can abstain from publishing "Announce" messages on every page load and wait for incoming "Prompt" messages. Yet this opens the possibility for race conditions where Wallet Providers could be initialized after the "Prompt" message was published and therefore be undiscoverable. It is recommended that Wallet Providers offer this more "private connect" feature that users only enable optionally, rather than set by default.


		#### Discovery

		Both Wallet Providers and blockchain libraries must listen to incoming messages that might be published after their initialization. Additionally both Wallet Providers and blockchain libraries must publish a message to both announce themselves and their intent to connect, respectively.


		#### Handshake

		After the wallet has been selected by the user then the Blockchain Library MUST publish a message to share its intent to establish a connection. This can be either done as a [CAIP-25][caip-25] request.


		#### UUIDs

		The generation of UUIDs is crucial for this messaging interface to work seamlessly for the users.


		## Simple Summary

		CAIP-295 defines a standardized messaging transport for browser iframe wallets.


		## Motivation

		Currently, in order for Decentralized Applications to be able to support all users they need to support all browser wallet APIs. Similarly, in order for browser wallets to support all Decentralized Applications they need to support all APIs. This is not only complicated but also results in a larger bundle size of applications.


		A UUID can be re-used as a `sessionId` if and only if the [CAIP-25][caip-25] procedure has been prompted to the user and the user has approved its permissions to allow the application to make future signing requests.

		Once established, the UUID is used as `sessionId` for the [CAIP-27][caip-27] payloads, which can verify that incoming messages are being routed through the appropriate channels.

	chains?: string[]; // compatible with CAIP-2
	scopes?: string[]; // compatible with CAIP-2


		#### Connection

		After the wallet has been selected by the user then the blockchain library MUST publish a message to share its intent to establish a connection. This can be either done as a [CAIP-25][caip-25] request or [CAIP-222][caip-222] authentication.

CAIP-282 - Browser Wallet Messaging Interface #282

Are you sure you want to change the base?

CAIP-282 - Browser Wallet Messaging Interface #282

Conversation

pedrouid commented May 30, 2024 • edited Loading

obstropolos left a comment

Choose a reason for hiding this comment

pedrouid commented Jun 24, 2024

pedrouid commented Jun 26, 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

mcintyre94 Jul 1, 2024 • edited Loading

Choose a reason for hiding this comment

kewde Jul 2, 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

kewde Jul 2, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kewde Jul 2, 2024 • edited Loading

Choose a reason for hiding this comment

Legacy injection

wallet standard

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kewde Jul 2, 2024 • edited Loading

Choose a reason for hiding this comment

adonesky1 Jul 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kdenhartog left a 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

kdenhartog Jul 29, 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

bumblefudge commented Aug 15, 2024

pedrouid commented May 30, 2024 •

edited

Loading

pedrouid commented Jun 26, 2024 •

edited

Loading

mcintyre94 Jul 1, 2024 •

edited

Loading

kewde Jul 2, 2024 •

edited

Loading

kewde Jul 2, 2024 •

edited

Loading

kewde Jul 2, 2024 •

edited

Loading

kewde Jul 2, 2024 •

edited

Loading

adonesky1 Jul 16, 2024 •

edited

Loading

kdenhartog Jul 29, 2024 •

edited

Loading