Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signing flow explained in README #265

Merged
merged 1 commit into from
Aug 21, 2023
Merged

Signing flow explained in README #265

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -158,6 +158,14 @@ Check our integration tests to see how it works in practice.

Registered ID Token will be added to the persistent DB on each Signing node and saved until expiration. Registered Id Tokens are tied to the provided PK.

## Sign flow
The expected flow for the client is next:
1. Client uses `/user_credentials` endpoint to get the recovery PK.
2. Client fetches latest nonce, block hash using obtained recovery PK.
3. Client creates a delegate action with desired actions, such as add or delete key.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be nicer if we either link that contains what delegate action format looks like, or have a example code here

Copy link
Collaborator Author

@volovyks volovyks Aug 17, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Delegate actions are supported in NAJ and documented here: https://github.com/near/near-api-js/blob/e5570d07b19f618007253ba04b6df8e7af854972/packages/transactions/src/delegate.ts#L37

4. Client gets the signature from the MPC system using `/sign` endpoint.
5. Client sends the same delegate action to the relayer with obtained signature.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On step 5, is there a reason why FE need to sends the delegate action to relayer instead of endpoint handles it on its end?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We moved to the generic /sign endpoint to make the system more flexible and follow the single responsibility principle. Error handling is a nightmare if we need to pass errors from the relayer to the client. Also, we are designing multichain support now. That will make things even worse without this change.


### Client integration

There are several ways to get and use the ID token. The flow that we are using is called the "server" flow, you can find more info [here](https://developers.google.com/identity/openid-connect/openid-connect#authenticatingtheuser). The system will be able to process any token that is following the core OpenID Connect standard. In order to receive the ID token from OpenID provider you will need to include the `openid` scope value to the Authorization Request.
Expand Down