Update SEP-6 flow to delegate getting KYC fields to SEP-12 #1432
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
Ifropc
commented
Jan 27, 2024
| `fee_fixed` | float | (optional) If there is a fee for withdraw. In units of the withdrawn asset. `fee_percent` | float | ||
| | (optional) If there is a percent fee for withdraw. `extra_info` | object | (optional) Any additional data needed as an | ||
| input for this withdraw, example: Bank Name. | ||
| asynchonously. |
There was a problem hiding this comment.
Changes below fixes formatting
philipliu
reviewed
Jan 29, 2024
JakeUrban
reviewed
Jan 29, 2024
philipliu
reviewed
Feb 8, 2024
| @@ -102,6 +102,7 @@ Name | Type | Description | |||
| `memo` | string | (optional) the client-generated [memo](https://developers.stellar.org/docs/glossary/transactions/#memo) that uniquely identifies the customer. If a memo is present in the decoded SEP-10 JWT's `sub` value, it must match this parameter value. If a muxed account is used as the JWT's `sub` value, memos sent in requests must match the 64-bit integer subaccount ID of the muxed account. See the [Shared Accounts](#shared-omnibus-or-pooled-accounts) section for more information. | |||
| `memo_type` | string | (**deprecated**, optional) type of `memo`. One of `text`, `id` or `hash`. Deprecated because memos should always be of type `id`, although anchors should continue to support this parameter for outdated clients. If `hash`, `memo` should be base64-encoded. If a memo is present in the decoded SEP-10 JWT's `sub` value, this parameter can be ignored. See the [Shared Accounts](#shared-omnibus-or-pooled-accounts) section for more information. | |||
| `type` | string | (optional) the type of action the customer is being KYCd for. See the [Type Specification](#type-specification) below. | |||
| `transaction_id` | `string` | (optional) The transaction id with which the customer's info is associated. When information from the customer depends on the transaction (e.g., more information is required for larger amounts) | | |||
There was a problem hiding this comment.
nit: Should we specify what type of transaction this refers to? i.e. it refers to the "action" mentioned in the type specification section.
There was a problem hiding this comment.
It's up to the anchor implementation. However, in Platform implementation we will require type to be specified, that matches appropriate SEP (so client application should pass both transaction_id=abc and type=sep24 for example) so we know which table to lookup, and to avoid ambiguity when different protocols have transactions with the same id
JakeUrban
previously approved these changes
Feb 9, 2024
# Conflicts: # ecosystem/sep-0012.md
# Conflicts: # ecosystem/sep-0006.md
JakeUrban
previously approved these changes
Feb 21, 2024
philipliu
previously approved these changes
Feb 21, 2024
# Conflicts: # ecosystem/sep-0006.md
philipliu
approved these changes
Feb 21, 2024
philipliu
approved these changes
Feb 21, 2024
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.
Background
Current SEP-6 flow for working with KYC is quite complex from the anchor standpoint: it requires to pass the same set of information (required KYC fields) via both SEP-6 and SEP-12. This proposal aims to simplify the flow for both anchor and wallet. This proposal logically separates SEP-6 and SEP-12, and all work with KYC is done via SEP-12.
Proposed flow
The process of providing information to the anchor looks as follows:
GET /transactionand verify transaction status ispending_customer_info_updateGET /customerrequest. Note, that you must passtransaction_idas part of therequest.
PUT /customerendpoint to transfer the dataACCEPTEDGET /transactionshould transition to the next status (pending_user_transfer_start)Proposed change
This proposal includes multiple changes in order to simplify the flow.
SEP-6:
pending_customer_info_updaterequired_customer_info_messageandrequired_customer_info_updates. This field have not being adopted yet, so it's safe to remove them. Instead, transaction in statuspending_user_transfer_startshould use existingmessagefield to indicate that additional input is required, and use [SEP-12]PUT /customerendpoint (with transaction id)SEP-12:
Add
transaction_idfield toGET /customerandPUT /customer, allowing to fetch/update fields required in the scope of specific transaction