---
# System prepended metadata

title: STAN/Keyless API

---

# STAN/Keyless API 

## 1. Введение
Для общения с сервис-работником, задача которого генерировать и верифицировать ЭЦП необходим протокол, который будет совместим с WebPayments API, через который реализован **vault.keyless_one**(то что называется handler) - защищенный, обладающий персистентной памятью и глобальным контекстом вызова компонент приложения `keyless_one`. Демо, реализованная **Стасом => [тут](https://santalov.github.io/), Алером => [тут](https://github.com/keylessone/l2a-payment-handler)**. Ранняя спека на этот компонент, описывающая **модель взаимодействия всех компонентов keyless_one => [тут](https://hackmd.io/fMn8KVOqToaMWEzy8mA-0w)**. 

В качестве референса для хендлера - используем протокол **[TrezorConnect v8](https://github.com/trezor/connect/blob/v8/docs/methods.md)**  /// проверить в начале роботоспособность используя Trezor(подробнее в dev guide, в разделе 1)
![](https://i.imgur.com/zu5BoPC.png)

## 2. Важные ссылки 

1. Конфиг монет **[TrezorConnect/coins.json](https://github.com/trezor/connect/blob/v8/src/data/coins.json)** в нем эндпоинты провайдеров исторических данных и мастер-данные, необходимые для коректной генерации адресов/ключей для каждой из поддерживаемых монет.
2. Введение в принципы работы и организацию **[TrezorConnect dev guide](https://wiki.trezor.io/Trezor_Connect_API)**
3. https://connect.trezor.io/8/trezor-connect.js

## 3. API
В целях экономии времени за основу берем интерфейс trezor connect - он интегрирован везде где можно интегрировать, разработчики d-app's умеют с ним обращатся - на текущий момент это лучшее решение для быстрого старта. 
Главаная дока для разработчиков => **[тут](https://github.com/trezor/connect/blob/v8/docs/index.md)**


### 3.1. API аутентификации(login) в дашборд/сторонние ресурсы.


| Метод | Референс | Описание |
| -------- | -------- | -------- |
| getPublicKey     | [TrezorConnect.getPublicKey](https://github.com/trezor/connect/blob/v8/docs/methods/getPublicKey.md)     | Метод предоставление публичного ключа      |
| requestLogin | [TrezorConnect.requestLogin](https://github.com/trezor/connect/blob/v8/docs/methods/requestLogin.md) | Авторизацния в панель управления |
| cipherKeyValue | [Trezor.Connect](https://github.com/trezor/connect/blob/v8/docs/methods/cipherKeyValue.md) | Реализуем во второй фазе |
| wipeDevice | [Trezor.Connect](https://github.com/trezor/connect/blob/v8/docs/methods/wipeDevice.md) | Реализуем во второй фазе |
| resetDevice | [Trezor.Connect](https://github.com/trezor/connect/blob/v8/docs/methods/resetDevice.md) | Реализуем во второй фазе |

### 3.2. API авторизации платежей(pay)
#### 3.2.1. Для блокчейн-реестров на основе модели UXTO
> Нужно имплементировать все методы UXTO(btc)

 **📑[Оглавление](https://github.com/trezor/connect/blob/v8/docs/methods.md)** со списком методов доступа 
Методы:

* [TrezorConnect.getAddress](methods/getAddress.md)
* [TrezorConnect.getAccountInfo](methods/getAccountInfo.md)
* [TrezorConnect.composeTransaction](methods/composeTransaction.md)
* [TrezorConnect.signTransaction](methods/signTransaction.md)
* [TrezorConnect.pushTransaction](methods/pushTransaction.md)
* [TrezorConnect.signMessage](methods/signMessage.md)
* [TrezorConnect.verifyMessage](methods/verifyMessage.md)

## ---- Конец актуальной спеки. Дальше черновик

### Блокчейны на основе модели счета
### ETH
> Нужно имплементировать все методы:

TrezorConnect.ethereumGetAddress
TrezorConnect.ethereumSignTransaction
TrezorConnect.ethereumSignMessage
TrezorConnect.ethereumVerifyMessage



---
> В случае достижения успеха с первой частью, дальнейшее развитие подразумевает развитие API в более дружественную SDK для не-крипто разработчиков для интеграции на сторонние ресурсы. 

## Фаза 2.

Цель: Обертка API в библиотеку высокого уровня, на основе EOS UAL

### EOS

> название компонента - в процессе обдумывания, варианты => `bridge.keyless_one`,  `connect.keyless_one`,  `gate.keyless_one`, `auth.keyless_one`
## 0. Подготовка
* Нужно изучить возможность интеграции **[EOS UAL](https://medium.com/eosio/eosio-labs-release-the-universal-authenticator-library-ual-increasing-the-accessibility-of-8e2bd62a78a5)** при вызове модалок. 
* **[Либа](https://github.com/EOSIO/universal-authenticator-library), [Туториал](https://github.com/EOSIO/ual-authenticator-walkthrough), [Пример](https://github.com/EOSIO/ual-reactjs-renderer/tree/develop/examples)** Для использования скачать **[Scatter](https://get-scatter.com/)**, либо использовать Trezor, лежащий в офисе. 
* Уделите внимание стандарту **[EOS Ricardian](https://github.com/EOSIO/ricardian-spec)** - он регламентирует модель шаблонизации(язык разметки интерфейса, похожий на markdown) модальных окон, отображаемых при авторизации платежей пользователем. Если будет непреодолимых препятствий это можно перенести на keyless - авторизации платежей для них, генерация подписей к транзакциям состояний для нас - в конечном счете это все вызовы методов класса контракта процессинговой системы - они описаны **[тут](https://hackmd.io/1xGcx95nTteZYljIea6HLQ?view)**(это необязательное чтиво).


> **PS** После обсуждения вопроса EOS -> Будет решение относительно API(реализуем то что ниже, либо мимикрируем под EOS UAL)

