SIP for Wallet Protocol #59
Conversation
|
A rpc style api makes sense because it would work also for a https provider |
Another benefit is that, with Web Extensions, it'll be easier to forward events when they go through the same method. For each new method, a new handler is needed in the forwarding script contexts. In page script context → Content script context → Background script context |
There was a problem hiding this comment.
Drawing parallels from Ethereum, currently this SIP encompasses:
- EIP-1102 Opt-in account exposure
- EIP-1193 Ethereum Provider JavaScript API
- EIP-1474 Remote procedure call specification
@friedger I wonder if we should scope this to be more specific about the format/API of the provider protocol, and less about about what methods/functionality it may support.
|
|
||
| # Abstract | ||
|
|
||
| Decentralized application do not handle private keys of users. Instead users have wallets that manage private keys, authentication, message signing etc. This SIP specifies a ways to exchange messages between applications and wallets and how to agree on one. |
There was a problem hiding this comment.
| Decentralized application do not handle private keys of users. Instead users have wallets that manage private keys, authentication, message signing etc. This SIP specifies a ways to exchange messages between applications and wallets and how to agree on one. | |
| Decentralized application do not handle private keys of users. Instead users have wallets that manage private keys, authentication, message signing etc. This SIP specifies a set of remote procedure call methods wallet providers must use. |
There was a problem hiding this comment.
Either text is fine with me. RPC is a form of message exchange, and there will almost certainly be apps that use the message-passing paradigm instead of the RPC paradigm for communication.
| It provides functions to handle | ||
|
|
||
| 1. authentication | ||
| 2. transaction signing |
There was a problem hiding this comment.
If using RPC methods, these should be deprecated. Wallet's can warn developers of this, to avoid breaking changes until the majority have migrated.
This section should include details akin to https://eips.ethereum.org/EIPS/eip-1193#supported-rpc-methods
| https://github.com/hirosystems/connect/blob/main/packages/connect/src/types/provider.ts | ||
|
|
||
| The function `authenticationRequest` expects the JWT of the authentication request as parameter and must return the authentication response as encoded JWT. | ||
|
|
||
| This transport protocol is implemented by the [Hiro Wallet web extension](https://github.com/blockstack/stacks-wallet-web/). Examples for client libraries are [Connect](https://github.com/blockstack/connect) and [Micro Stacks](https://github.com/fungible-systems/micro-stacks). | ||
|
|
||
| ### HTTPS | ||
|
|
||
| Authentication requests can be sent via HTTPS to a hosted authenticator. The encoded JWT of the request must be set as query parameter `authRequest` when calling the url of the authenticator. | ||
|
|
||
| The authentication request must contain a redirect url. The authenticator must open this url with the authentication response as encoded JWT in the query parameter `authResponse`. | ||
|
|
||
| This transport protocol is implemented by the Blockstack Browser and the Stacks cli. | ||
|
|
||
| ### App Links | ||
|
|
||
| On mobile devices, applications can use app links/deep links to send authentication requests and receive the response. They must use the same query parameters for the authentication requests and responses as the HTTPS protocol, i.e. `authRequest` and `authResponse`. | ||
|
|
||
| This transport protocol is implemented by the following authenticator apps: | ||
|
|
||
| - [Wise app](https://github.com/PravicaInc/wise-js) and client library[wise-js](https://github.com/PravicaInc/wise-js) | ||
| - [Circles app](https://github.com/blocoio/stacks-circles-app) for Android. |
There was a problem hiding this comment.
Aren't these details better suited to your other SIP?
Co-authored-by: kyranjamie <[email protected]>
Co-authored-by: kyranjamie <[email protected]>
|
|
||
| ## Transport Protocols | ||
|
|
||
| The communication between application and authenticator can happen in various ways. The subsections below define common transport protocols. |
There was a problem hiding this comment.
Is an authenticator different from a wallet here? If so, can you clarify the difference?
|
|
||
| ### Stacks Provider | ||
|
|
||
| The _Stacks Provider_ is a common interface exposed to dApps as a JavaScript object, often injected by a Web Extension. |
There was a problem hiding this comment.
Does the SIP require that the Stacks provider be a Javascript object, and does it require that there exists a Web extension to inject it? If not, can you clarify that this is an implementation example, as opposed to a design requirement? Thanks.
| 1. authentication | ||
| 2. transaction signing | ||
|
|
||
| https://github.com/hirosystems/connect/blob/main/packages/connect/src/types/provider.ts |
There was a problem hiding this comment.
I think this is describing a particular implementation. The SIP should describe the public interfaces and API contracts, as well as the transport protocol used to send and receive messages to interact with them.
This SIP specifies how applications and wallet should exchange messages and how applications and wallets agree on the protocol.
While writing "SIP for Authentication Protocol", it became clear that the communication should be handled in a separate SIP.