# Near Wallet Flow 2 Details

<!--  -->

### Specification
**Function** (capability)
- Manage and secure implicit account's private key with web3auth
- Asign and remove Full Access Key (wallet) on implicit account (fee pay by foundation ?)
- List all asigned Full Acccess Key in implicit account
- Communicate to wallet

**Do not** reposible for
- manage access key of explicit account (public key is added to explicit account(named account))
- Signing transaction (except add or removing FAK)

**Optional** function
- Bridging transaction ( like wallet connect ) *mainly for app wallet*

<br />

Pros :
- Web3Auth manage implicit key (native key).
- Web3Auth remove any FAK from implicit account.
- Dapp could have separate `client-id` (different account for same oauth login) capability

Cons :
- Wallet have Full Access to the account which could transfer all the fund
- Wallet can remove web3auth key.
- No named accounts
- Needs a funding source
- Complex integration with different wallet flow - native app, browser (web) and injection (chrome-extension)

### Proposed Flow
Defination :
**Dapp** - Decentralise Near Application with wallet selector
**Wallet** - Web wallet or App wallet
**Web3Auth** - Web3Auth site that reconstruct private
**Broadcast Server** - Server that relay message on respective channel

#### Sign Up (new Wallet) Flow

<!--  -->

Flow Details
1) Redirect to web3Auth with Dapp details
2) Redirect to OAuth
3) Return from OAuth
4) Open Broadcast Channel with generated `unique id`
5) Open new window to wallet site with `unique id` -or- show qrcode of `unique id` for app wallet to scan
6) Open Broadcast Channel with `unique id`
7) Send public key to web3auth via broadcast channel
8) Send dapp details (and dapp public key) to wallet via broadcast channel
9) Confirm add Dapp's public key as Functional Access Key
10) Redirect to Dapp with wallet's details

<br/>

##### Broadcast Channel Server
Broadcast Channel relay message in respective channel

<!--  -->

1) Web3auth open bridging channel (Step 4 in Sign Up Flow)
2) Wallet post rest api request to server with channel id (Step 6 in Sign Up Flow)

<br/>

##### Proposed Alternative Step 7, 8 in Sign In Flow
To asign new wallet to implict account we have options below

- Default
- Web3auth generate a unique ID and pass the ID to wallet via new browser window's query param / qrcode or etc.
- Wallet generate private key pair
- Wallet post send public key, wallet name, wallet/app url via bridging server
- Web3auth got the request and add public key as FAK of the implicit account
- Return( or redirect) to dapp with the wallet details

- Pass Private Key via ECDH / Qrcode
- Web3auth generate a unique ID and pass the link to wallet via new browser window's query param / qrcode or etc.
- Wallet generate private key pair
- Setup ECDH between wallet and web3auth via broadcast channel
- Web3auth generate key-pair
- Web3auth add private-key as Full Access Key
- Web3auth send private-key to wallet via ECDH (encrypted)
- Return to dapp with the wallet details

<br/>

<!--
#### Access Key Management Flow
<!--  -->
<!--  -->

-->

<br/>

#### Sign Transaction Flow
- Sign Transaction is redirect to respected wallet
- For app wallet, deeplink or web with qrcode ( bridging server is an option (wallet connect) )

<br/>

### Proposed connect from wallet flow
<!--  -->

<!--  -->

<br/>

Flow :
1) Redirect to web3Auth with Wallet details
2) Redirect to OAuth
3) Return from OAuth
4) Open Broadcast Channel with generated `unique id`
5) Open new window to wallet site with `unique id` -or- show qrcode of `unique id` for app wallet to scan
6) Open Broadcast Channel with `unique id`
7) Send public key to web3auth via broadcast channel
8) Send Account Id and wallet details

<br />

### Proposed Bridging Server
- Using web3auth site as relay transaction to App Wallet via Broadcast Server (unique channel Id
- Mainly for web dapp to app wallet

<!--  -->
<!--  -->

Flow:
1) Dapp got and retain `unique id` after login send transaction details via bridging server
2) After confirm and send out transaction, send hash to dapp

<br/>

<!--  -->

Flow:
1) Dapp redirect to web3auth with transaction details
2) web3auth open websocket or ssr channel with bridging server. send transaction details on polling request.
3) Native wallet poll Bridging server for transaction. Native wallet send out transaction and send hash to bridging server
3-a) brigding server replay hash to web3auth
5) Web3Auth receive hash and redirect back to dapp

<br/>

## Key Deliverable

### Wallet-Selector
- API to open Web3Auth with provided details and wallet
<!-- - Api for redirect to web3auth with dapp details -->
### Web3Auth Site
- Redirect from Dapp/Wallet
- Reconstruct Key
- Add Full Access Key from Wallet -- or -- inject Full Access Key to the Wallet
- Send dapp's details and account ID to Wallet. This step is detemined on where the web3auth context live
- web + mobile
- send dapp details via bridging server or qrcode
- web + web
- send dapp details via redirect flow

- web + Chrome Extension
- send dapp details via `near provider`
- get public key via `near provider` and add it as FAK

### Wallet integration spec
Wallet responsible to generate key pair and send the public key to the
bridging server endpoint
- redirect flow params
- `query params` - `?web3auth_channel=<channel id>&account_id=<account_id>&<dapp forwarded data>`
- qrcode scan
- `data` - `?web3auth_channel=<channel id>&account_id=<account_id>&<dapp forwarded data>`

### Bridge Server API Spec
- POST `/channel/<unique-id>/register`
body :
- publicKey - string (hex)

<br/>

Description : API to register public key from wallet as Full Access Key on new Wallet flow.

- GET `/channel/<unique-id>/transaction`

Description: poll api to get pending `transaction`

- POST `/channel/<unique-id>/hash`
Body:
- hash - string

Description : Send transaction hash to web3auth which will redirect back to dapp ( for native app flow )

- POST `/channel/<unique-id>/ssr`
Description: subscribe to ssr or websocket

<br/>

### Multichain Wallet App

#### Problem statement
Multichain wallet integration with web3auth/torus would get the `main tkey` (private key) which is different from `near flow 2` where it add functional access key to the implicit account instead of giving implicit account private key (`main tkey`).

This will cost complexity for multichain wallet app to integrate `near flow 2` which reduce their interest.

#### Strategy
Below are some proposal strategy for multichain wallet app :

- Use default web3auth sdk with `near` endpoint which return (or accept) full access keys instead of private key for near
cons :
- wallet have manages 2 different keys

- Wallet integrated 2 web3auth sdk separetely
cons:
- complexity for wallet to integrate 2 sdk
- wallet have to manage 2 different keys

- ***Near will use web3auth key as full access keys on flow 2 account***
cons :
- near's flow 2 wallet address will be different from the other blockchain wallet address ( which use the same curve )

    web3auth key integrated in apps have existing - key A -> account A
    configure web3auth to enable near feature, key B (near) genearted -> Account B , add Full Access Key (key A) to Account B.
    wallet will get key A which have full access to Account B (near)

- Have the wallet get main tkeys or Fall back to `Flow 5`
cons:
- wallet will have the implicit account key