SEPs stand for the Stellar Ecosystem Protocol. They help to provide some standards to stick to for the ecosystem built on top of the stellar network.
SEP 12 deals with the KYC process between the wallet and the anchor. SEP 12 provides a standard to share KYC details between the wallet and the anchor who implement a non-interactive SEP 6 protocol.
SEP 12 aims to provide these features to the users.
(ii) When a user does the KYC process on one anchor, then the same information can be used on other anchors too. The user doesn’t have to worry about entering KYC details again and again manually.
(iii) Handles most common 80 % of cases related to KYC.
(iv) Handles binary and image data.
(v) Supports set of fields defined in SEP 9.
NOTE:- SEP9 is a standard way to implement the KYC process for Stellar anchors.
(vi) Support SEP 10 for authentication.
NOTE:- SEP10 is a standard for implementing web authentication for making endpoints secure.
(vii) Giving the ability to delete their data to the user.
(i) Anchors and wallets both must support SEP 10 protocol for authentication for all the SEP 12 endpoints.
(ii) Anchors compliant with SEP 12 must show the location of their KYC_SERVER or TRANSFER_SERVER in their stellar. toml file. This is so that the client app knows where to direct its requests for an anchor. A client app sends its KYC requests to KYC_SERVER of its specified in stellar. toml file for the anchor. Otherwise, the requests are sent to TRANSFER_SERVER.
The client should send the jwt obtained from the SEP 10 authentication flow. The JWT obtained should be used for authentication by including it in the header like this
Authorization: Bearer <JWT Token here>
If it is not possible for the client to include JWT in the request header, then JWT could also be included as a query parameter like this
To support SEP 12, the anchor acts as a server that provides API endpoints for the KYC process. The wallet implements a client that consumes the api. SEP 12 provides a standard the anchors and clients to follow so that any SEP 12 compliant anchor can interact with any SEP 12 compliant client.
The following are the endpoints that the anchor has to implement to be SEP 12 compliant.
(i) PUT /customer:- API endpoint for idempotent upload of user’s info.
(ii) DELETE /customer:- API endpoint for idempotent deletion of user’s info.
1.) PUT /customer endpoint:- This endpoint takes user KYC info and stores it on the anchor.
PUT [KYC_SERVER || TRANSFER_SERVER]/customer
Note:- KYC_SERVER and TRANSFER_SERVER should be mentioned in the stellar.toml file of the anchor. This is to specify to the client where to send the request to.
(ii) REQUEST BODY
The request body takes the following parameters with multipart/form-data encoding.
The wallet should also transmit one or more of the fields that are listed in SEP-9, binary type fields (typically files) should be submitted after all other fields. The reason for this is that some web servers require binary fields at the end so that they know when they can begin processing the request as a stream.
2.) DELETE /customer:- This endpoint deletes the info of a given user from the anchor.
DELETE [KYC_SERVER || TRANSFER_SERVER]/customer/[account]
(ii) QUERY PARAMETER
The [account] param mentioned in the request above is a valid stellar address belonging to the user whose data we want to delete.
CONCLUSION:- In this blog, we learned about SEP 12 and its endpoints.
For official documentation for SEP 12, you can look HERE.
For authentication for endpoints, implement SEP 10.