Skip to content
This repository has been archived by the owner on May 14, 2021. It is now read-only.

Onboarding Partners

Doody Parizada edited this page Aug 29, 2018 · 2 revisions

Client SDKs and Sample apps

App Identifier (app_id)

Each app in the ecosystem has an app_id. For example Kik has kik, Test app has test, Sample app has smpl. The app_id is used in 2 spots.

  1. as the issuer of the JWT messages that come from your server
  2. as an identifier attached to each transaction on the blockchain. Will be used in the future for the rewards engine. We will provide the app_id to the partner.

JWT public keys and exchange:

Our public keys are served as part of the configuration endpoint of the api: production: http://api.kinmarketplace.com/v1/config playground: http://api.kinplayground.com/v1/config

We prefer using a single JWT algorithm type as it’s more secure to limit the options of the algorithm. The keys should all be using the es256 algorithm. An example of how to create them: https://github.com/kinecosystem/marketplace-server/wiki/Creating-ES256-Keys

What we need from the Partner is a list of keys (preferably 5 or more) so you can rotate them. For each key we need a kid (key id) that will be declared in the header of the JWT message so we know which key was used to sign it.

you can see the above /v1/config endpoints as an example for our own keys, or here:

KID: "es256_0000" KEY: "----- PUBLIC KEY ----- SOME DATA0 -----"
KID: "es256_0001" KEY: "----- PUBLIC KEY ----- SOME DATA1 -----"
KID: "es256_0002" KEY: "----- PUBLIC KEY ----- SOME DATA2 -----"

A register message payload for example (viewable on jwt.io) has the following header:

{
  "alg": "ES256",
  "typ": "JWT",
  "kid": "some_id"
}

which states that the key id used is some_id.