An Introduction to SEP 12 on Stellar Blockchain

---

INTRODUCTION

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.

FEATURES

SEP 12 aims to provide these features to the users.

(i) Interoperability 

(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.

PREREQUISITES

(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.

AUTHENTICATION

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 

?jwt=<token>

API ENDPOINTS

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.

(i) REQUEST

PUT [KYC_SERVER || TRANSFER_SERVER]/customer

Content-Type: multipart/form-data

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.

(iii) RESPONSE

1. Success response:-  If the data in the request body is accepted and stored successfully, then the response should return status code 202 Accepted and the body should be empty.
2. Error response:- Any other response apart from the success response mentioned above should be considered as an error. The returned response should have the required error status code and the response body should contain the error message in a human-readable format describing the reason for the failure of the request.

2.) DELETE /customer:- This endpoint deletes the info of a given user from the anchor.

(i) REQUEST 

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. 

(ii) RESPONSE

1. ON successful deletion of user data, the response status code will be 200 OK success.
2. If the request is not authenticated as per the SEP 10 standards, the response will be 401 Unauthorized.
3. If the given user has no info on the anchor, the response should be 404 Not Found.

CONCLUSION:- In this blog, we learned about SEP 12 and its endpoints.

REFERENCE

For official documentation for SEP 12, you can look HERE.

For authentication for endpoints, implement SEP 10.