# Checklist Provedores

Um provedor que deseja se integrar tecnicamente ao ecossistema do BR-UTM pode utilizar os checklists abaixo como balizadores para o desenvolvimento das suas soluções.

Os checklists estão dividos em três. O primeiro, de autenticação, é obrigatório para todos o provedores e deve ser completado por primeiro, visto que todos os outros checklists dependem da autenticação. O checklist de desconflito visa guiar o desenvolvimento para provedores que desejam criar liberações de espaço aéreo para seus operadores, em alternativa à liberação obtida através do SARPAS. Já o checklist de identificação guia o desenvolvimento de aplicações que provêm em tempo real a posição dos drones via internet. A obrigatoriedade da identificação durante a operação ainda está em debate pelo grupo. Orienta-se que provedores tenham essa capacidade para todos os voos.

<details id="bkmrk-autentica%C3%A7%C3%A3o-ao-rece"><summary>Autenticação</summary>

O protocolo de autenticação utilizada no ecossistema no BR-UTM segue a arquitetura definida em ASTM F3548-21 Anexo X1.1 "*<span class="fontstyle0">Base Deployment: Access Tokens with Audience </span><span class="fontstyle0">Claims</span>*", baseado no padrão de tokens JWT: I<span class="fontstyle0">ETC RFC 7519</span>.

Checklist:

- [ ] Obter apikey
- [ ] Realizar autenticação
- [ ] Validar autenticação de outro USS

Os detalhes técnicos podem ser obtidos abaixo. A referência técnica da etapa de autenticação pode ser encontrada em [Autenticação Service Provider](https://servicos2.decea.mil.br/br-utm/wiki/books/documentacao-tecnica/page/autenticacao-service-provider "Autenticação Service Provider")

</details><details id="bkmrk-desconflito-%C2%A0"><summary>Desconflito</summary>

Para ser um provedor de desconflito, o provedor deve seguir a especificação ASTM F3548-21. Os detalhes técnicos estão em: [\[Desconflito\]\[Autenticação\] Roteiro Etapa 1](https://servicos2.decea.mil.br/br-utm/wiki/books/documentacao-tecnica/page/desconflitoautenticacao-roteiro-etapa-1 "[Desconflito][Autenticação] Roteiro Etapa 1")

Checklist

- [ ] OIR Isolada
- [ ] OIR próxima a constraint
- [ ] OIR com conflito
- [ ] Endpoints de coordenação
- [ ] Ativação de OIR
- [ ] Exibição da OIR no viewer do ICEA (Entrar em contato com a equipe técnica)

</details><details id="bkmrk-identifica%C3%A7%C3%A3o-%C2%A0"><summary>Identificação</summary>

Para ser um provedor de identificação, o provedor deve seguir a especificaçao ASTM F3411-22a. Os detalhes técnicos estão em: [\[Remote ID\] Onboarding Service Provider.](https://servicos2.decea.mil.br/br-utm/wiki/books/documentacao-tecnica/page/remote-id-onboarding-service-provider "[Remote ID] Onboarding Service Provider")

O protocolo de comunicação entre DRONE &lt;-&gt; USS não é escopo do BR-UTM, ficando cada USS livre para implementar da melhor maneira possível. É esperado que o provedor atualize a posição de seus drones no mínimo a cada 4 segundos

Checklist

- [ ] Criação ISA sem subscription
- [ ] Criação ISA com subcription
- [ ] Exibição da posição do drone no viewer do ICEA (Entrar em contato com a equipe técnica)

</details>---

## Autenticação

<details id="bkmrk-autenticar-se-%C2%A0"><summary>Autenticar-se</summary>

A URL base é GET [`http://montreal.icea.decea.mil.br:64235/token`](http://montreal.icea.decea.mil.br:64235/token)

A requisição deve conter as seguintes *query\_strings*

<table border="1" style="border-collapse: collapse; width: 99.9786%; height: 106.033px;"><colgroup><col style="width: 50.0471%;"></col><col style="width: 50.0471%;"></col></colgroup><tbody><tr style="height: 46.5167px;"><td style="height: 46.5167px;">intended\_audience</td><td style="height: 46.5167px;"><span style="color: rgb(0, 0, 0);">USS de destino da mensagem (Vem na OIR ou Constraint no campo *manager*)</span>  
</td></tr><tr style="height: 29.8px;"><td style="height: 29.8px;">scope</td><td style="height: 29.8px;"><span style="color: rgb(0, 0, 0);">escopo da requisição. Ex.: utm.strategic\_coordination.</span>

<span style="color: rgb(0, 0, 0);">O scope esperado de cada endpoint está definido no OpenAPI  
</span>

</td></tr><tr style="height: 29.7167px;"><td style="height: 29.7167px;">apikey</td><td style="height: 29.7167px;"><span style="color: rgb(0, 0, 0);">chave recebida do ICEA. Pode-se optar em enviar esse campo no Header da requisição  
</span></td></tr></tbody></table>

</details><details id="bkmrk-validar-autentica%C3%A7%C3%A3o"><summary>Validar autenticação de outro USS</summary>

Ao receber uma requisição de outro USS em seu servidor, é necessário validar o token de autenticação fornecido pelo outro USS. O payload do token contém as seguintes informações:

<table border="1" style="border-collapse: collapse; width: 99.9786%; height: 249.384px;"><colgroup><col style="width: 33.3333%;"></col><col style="width: 33.3333%;"></col><col style="width: 33.3333%;"></col></colgroup><tbody><tr style="height: 46.5167px;"><td style="height: 46.5167px;">aud  
</td><td style="height: 46.5167px;">Nome do provedor destino da requisição  
</td><td style="height: 46.5167px;">"core-service"  
</td></tr><tr style="height: 63.3167px;"><td style="height: 63.3167px;">exp  
</td><td style="height: 63.3167px;">Timestamp epoch do horário de expiração do token. O token não deve ser aceito a partir desse horário  
</td><td style="height: 63.3167px;">1719777868</td></tr><tr style="height: 29.7167px;"><td style="height: 29.7167px;">iss  
</td><td style="height: 29.7167px;">Nome do provedor emissor do token  
</td><td style="height: 29.7167px;">ICEA  
</td></tr><tr style="height: 80.1167px;"><td style="height: 80.1167px;">scope  
</td><td style="height: 80.1167px;">Scope autorizado pelo token. Cada endpoint deve aceitar apenas determinados scopes, conforme definido no OpenAPI  
</td><td style="height: 80.1167px;">utm.strategic\_coordination  
</td></tr><tr style="height: 29.7167px;"><td style="height: 29.7167px;">sub  
</td><td style="height: 29.7167px;">Nome do provedor origem da requisição  
</td><td style="height: 29.7167px;">"USS1"</td></tr></tbody></table>

Os passos para verificação são

1. Verificar assinatura do token 
    1. Deve-se validar a assinatura do token utilizando a chave pública do ICEA
2. Verificar a validade do token 
    1. Deve-se validar que o campo "exp" não seja menor do que o horário atual
3. Verficiar audiência do token 
    1. Deve-se validar que o campo "aud" seja o seu nome, ou seja, o nome do provedor que está recebendo a requisição
4. Verificar o scope 
    1. Deve-se validar que o campo "scope" contenha o scope necessário para requisitar o endpoint. Um token pode possuir mais de um scope separados por espaço em branco.

</details><details id="bkmrk-eco-utm-autenticator"><summary>Eco-UTM Autenticator Public Key</summary>

```
-----BEGIN PUBLIC KEY-----
MIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKBgHkNtpy3GB0YTCl2VCCd22i0rJwI
GBSazD4QRKvH6rch0IP4igb+02r7t0X//tuj0VbwtJz3cEICP8OGSqrdTSCGj5Y0
3Oa2gPkx/0c0V8D0eSXS/CUC0qrYHnAGLqko7eW87HW0rh7nnl2bB4Lu+R8fOmQt
5frCJ5eTkzwK5YczAgMBAAE=
-----END PUBLIC KEY-----
```

</details>