add support for sending permission requests #24
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
if we want to add support for configuring the initial connection (e.g. permissions) we need to have a way to provide a config alongside everything else (e.g. `pubkey`, `origin`, etc.)
we could encode any additional stuff as JSON and add it as query parameters to the URL passed to `web5://`, as that's where the connect popup is created, but we'd potentially run into issues with the length of the URL (as well as it just not being the greatest design to encode everything into the URL)
we already are leveraging a `WebSocket` to listen for when the user does something with the connect popup (e.g. allow, deny, close, etc.), but we wouldn't want to send a separate message at the same time as the `web5://` request as that could be abused as a timing attack (e.g. the user accepts the connection request before a permissions message is received)
instead, slightly shift the order/placement of things such that we can guarantee the order of events between the `web5://` request and the `WebSocket`
1. the client opens a bunch of `ws://localhost:${port}/connections/${pubkey}`
2. the client requests `web5://connect/${pubkey}`
3. the server connects to the `ws://` from step 1 on one of the `port` and saves a reference to the `WebSocket` along with the corresponding `pubkey`
4. the server receives the `web5://` from step 2 and saves the `pubkey` for later use to verify that the originator did in fact request `web5://`
5. the server sends `{ req: 'request', res: 'received' }` through the `WebSocket` from step 1 to indicate to the client that the `web5://` was received (since there's no other way for the client to know when the the server has received (let alone finished handling) the `web5://` request)
6. the client receives the message from step 5
7. the client sends `{ req: 'connect' }` asking for the connection popup to be displayed (and this is where we'd include any permissions)
8. the server receives the message from step 7 and confirms that the `pubkey` associated with the `WebSocket` was previously saved in step 4 (thereby transitively affirming that the client did request `web5://` with that same `pubkey`)
9. the server generates a `pin` and `nonce` and etc. to show the connection popup
10. the server sends `{ req: 'connect', res: 'requested', pin, nonce }` (though the `pin` has been encrypted using the `pubkey`) using the data from step 9 for display in the page to allow the user to visually confirm the right page/connection
11. the user does something with the connection popup from step 10 (e.g. allow, deny, close, etc.)
12. the server sends `{ req: 'connect', res: '...', data } with the `...` being an enum representing the user's choice from step 11
13. the client receives the message from step 12 and handles the user's choice accordingly
this approach allows us to have even greater flexibility with what additional data to provide alongside the `{ req: 'connect' }` and decouples as much as possible from the `web5://` request since ultimately that is just a user interaction check (and may have disappear in the future depending on how true that user interaction guarantee is on all platforms)
…st:${port}/dwn/${pubkey}`
this allows the `desktop-agent` to ensure that the requester has called `connect`
provided as part of the `options = { }` given when calling `connect`
included alongside the `{ req: 'connect' }` sent to the `desktop-agent`
expected to be an array of <https://identity.foundation/decentralized-web-node/spec/#permissionsrequest>
… `permissionRequests`
dcrousso
force-pushed
the
dcrousso/permissions
branch
from
5c0eb0f to
be9c9db
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.