Modelo de socio registrado

Deribit desea crear un ecosistema de socios para beneficiarse de las sinergias creadas al combinar la experiencia individual y el valor agregado de cada parte. Se parte del supuesto de que el cliente puede abrir una cuenta en Deribit y dar derecho al socio registrado a enviar pedidos a

Proceso

Deribit ofrece a los socios un pago de reembolso automatizado para las operaciones generadas por el socio en nombre de sus clientes. Por ese motivo, todos los clientes deben tener una cuenta en Deribit, y el socio enviará los pedidos en nombre de sus clientes a Deribit. Como Deribit solo verá las ejecuciones de los clientes finales, el socio debe añadir una firma a estos pedidos para que Deribit los reconozca y les envíe descuentos en función de las comisiones generadas por sus clientes. Como alternativa, en el caso de REST y FIX, en el caso de los enfoques de «concesión implícita» y «código de autorización», la aplicación también puede utilizar un token de acceso especial, que Deribit utiliza a continuación internamente para identificar que

1.El socio confirma la cuenta de prueba (por ejemplo, partner@gmail.com), tras lo cual Deribit creará un ID de cliente y un secreto de acuerdo con las especificaciones deModelo de solicitud de socio registrado

2.El socio se conecta a Deribit en el entorno de prueba (test.deribit.com) de acuerdo con las especificaciones del Modelo de solicitud de socio registrado

3.El socio envía los pedidos en nombre de otra cuenta de prueba (por ejemplo, endclient@hotmail.com)

4.El socio verifica al día siguiente, a las 08:05 UTC, que ha recibido el pago en su cuenta de Deribit (registro de transacciones)

5.Una vez que se verifica la configuración de la prueba, el socio crea una configuración idéntica en producción (se requieren una identificación y un secreto nuevos)

6.Deribit envía las credenciales de producción y notifica al socio que, al utilizar estas credenciales, el socio reconoce automáticamente haber leído, entendido y aceptado los términos y condiciones del programa.

7.Deribit activa el reparto de ingresos en la producción

8.El logotipo y el enlace del socio se pueden agregar a nuestra sección de socios

9.Deribit y su socio anuncian la integración de socios a través de canales de marketing como el correo electrónico, los boletines informativos y las redes sociales.

Configuración técnica: descripción general de la autorización

Deribit ofrece dos flujos de trabajo para que las aplicaciones asociadas ejecuten solicitudes en nombre de los usuarios de Deribit. En primer lugar, se trata de adquirir un token de acceso especial que permita identificar el origen de la solicitud, por ejemplo, la aplicación asociada. Second es adecuado para aplicaciones que ya dependen de las claves de API proporcionadas por los usuarios; sin embargo, la aplicación debe incluir una firma adicional para que Deribit pueda identificarla como fuente de la

Solo se admiten la API REST/WebSocket APIv2 y la API FIX.

En la siguiente tabla se presenta una descripción general de los métodos de autorización y se explican más detalles adicionales:

1. Adquisición del token de acceso

Para que Deribit pueda crear esta configuración, necesitaríamos los siguientes requisitos:

Descripción general de la autorización

Hay tres métodos para adquirir tokens de acceso mediante aplicaciones externas que se pueden usar en REST y WS API:

Los dos primeros utilizan el punto final /app_authorization en el paso inicial.

Parámetros necesarios:

Parámetros opcionales:

1.1 Subvención implícita

Este método está diseñado para aplicaciones que no pueden almacenar su secreto de forma segura, como las aplicaciones web del lado del cliente. Es menos seguro que el método del código de autorización, por lo que se recomienda a las aplicaciones que utilicen el método del «código de autorización» si es posible.

Pasos:

Ejemplo:

https://test.deribit.com/app_authorization?client_id=oKtyW608&redirect_uri=localhost%3A83

21% 2FCB&scope=trade%3ARead_write%20account%3ARead&state=0&response_type=token

Redirigir después de que el usuario haya otorgado acceso:

localhost:8321/cb#state=0&access_token=1567681835306.1P66aopy.d5bP32TzVWySRWRJRCp8k12DTB2
XvD2kubl7KQYu7TH3W8DrQkbfhy3pkp-saoAJ3QOOOS6keArX2LdPtg_eMiVYhJkxcoYxmol-XMYPp7V5ooJ1f-Ti
9v-Ln2gMCdLcg6_c7eaPInZdjprozs0dPK5U3CBPSpUBgIXE4A_niTTeLamgQkrsQLpuF9OpLGhfAQxJbALMsr0F6
T81AWZ5heIOtiN4FU836iv0Wdrq3lLjC-MeoCJ-0fEWvz9XQ9D08LHUPoks&refresh_token=1568615874421.1
CL4Rqm5.UPCwi6aRYWHAq3h5dvx8vQCycC6Kr36P0d7cZ0gDzb3ofPK46Ka8U1RmLt_Wcsul4XA-e-O0m6QV_OMq9
9VySPxWfO-fZ0nIPktN5m0MjWqf9peSJ4ePzGEReogm2WR8pDb6THAanmUOFEzj1e-4Doa2krFL7oaifDMte5mbOg
ti-phudF8mRZodL9vrBqu6Za2RnTWT-nH0E2ZxYB0aPpu7MiG9BEoah9AzkVGbuv26r-iUfLue_SBppYIBVj5r9kR
3Z_JSu71On_CoEdrIlwtkr87ZAFY&expires_in=900&token_type=bearer

1.2 Código de autorización

Este método requiere el almacenamiento seguro del secreto del cliente recibido después del registro.

Pasos:

Se deben pasar tres parámetros al método/public/auth:

Ejemplo de cuerpo de solicitud (espacios en blanco añadidos para facilitar la lectura):

{
    "method": "public/auth",
    "params": {
        "grant_type": "authorization_code",
        "code": "99KCas2FyFs8miQnTqE6MzTxRkZGqkegJrycm5XWOHE",
        "redirect_uri": "localhost:8321/cb"
    }
}

La respuesta está en la misma forma que se describe aquí.

1.2.1 Recuperar el acceso: tipo de concesión app_user

En caso de que la aplicación pierda el token, o se invalide por cualquier motivo, para adquirir uno nuevo, sin necesidad de la interacción del usuario, la aplicación puede usar el user_id devuelto en la respuesta final del código de autorización flujo. Utiliza public/auth con

Ejemplo de solicitud:

{
    "method": "public/auth",
    "params": {
        "grant_type": "app_user",
        "user_id": "FIx_37_l"
    }
}

user_id es un identificador de usuario único de la aplicación, por lo que la aplicación debe estar autorizada para usarlo en el método public/auth mediante el encabezado APP-DERI-HMAC-SHA256.

1.3 Adquisición del token de acceso mediante la clave de API proporcionada por el usuario

Este método es diferente a los dos anteriores porque requiere que el usuario proporcione una clave de API a la aplicación, que luego la aplicación utiliza para adquirir el token.

Para adquirir el token de acceso, la aplicación llama al método /public/auth con el tipo de concesión app_user y los parámetros son los mismos que en el caso del tipo de concesión client_signature:

{
    "method": "public/auth",
    "params": {
        "grant_type": "app_user",
        "client_id": "WOQ7igCg",
        "timestamp": 1588771838265,
        "signature": "c6f6e812d473582d4023ac2584a94406f15c55b1a7f627b375a6a702ca388800",
        "nonce": "abcd",
        "data": ""
    }
}

Se describe la autorización de client_signature aquí:Método de autorización adicional: credenciales de firma (API WebSocket).

De manera similar a los métodos anteriores, la aplicación debe autorizarse mediante el método APP-DERI-HMAC-SHA256.

2. Autorización de firma

Los métodos siguientes utilizan las claves de API que proporcionan los usuarios, y el ID de cliente y el secreto proporcionados a la aplicación por Deribit después del registro, para generar firmas que deben enviarse con las solicitudes. Actualmente solo está disponible para REST y FIX

2.1 Encabezado de socio

Cuando el usuario está autorizado a utilizar el encabezado de autorización deri-hmac-sha256, se puede usar un encabezado de socio adicional para identificar el origen de la solicitud como la aplicación registrada en Deribit:

donde AppSig es una firma calculada como en el paso anterior (con el mismo valor de StringToSign), pero utilizando ClientID (AppID) y ClientSecret de la aplicación.

Alternativamente, en lugar del encabezado de socio, se pueden colocar AppID y AppSig en el encabezado de autorización deri-hmac-sha256 como valores appid y appsig.

Ejemplo de autorización:

deri-hmac-sha256 id=h4jakxW6F4,ts=1569934139312,nonce=abcd,
sig=53150ab0fd7ecfcee65e8d338232fbe527f066baE2e01bcf8b992757283fcc26,
appid=WOQ7igCg,appsig=ba610e2b1b2551a24a910a0e411e32aa3e19913177d2376399377167b2e3f232

Nota: Este método no se puede usar para adquirir el token de acceso como en los métodos anteriores: en cada solicitud, el usuario debe estar autorizado mediante el encabezado de autorización deri-hmac-sha256.

2.2 FIX - Etiquetas 9004 y 9005

Como alternativa al encabezado «partner» para las aplicaciones FIX, incluimos dos etiquetas personalizadas, 9004 y 9005, en el mensaje de inicio de sesión (A).