feat(dgw): subkey tokens

[CBenoit]

No description provided.

[awakecoding]

Au lieu de scope_ids, on devrait utiliser un nom comme gateway ids, ou une forme en abbreviation. Aussi, je me demandais si on faisait pas juste un id au lieu d'une liste? Genre "gwid"

[CBenoit]

Au lieu de scope_ids, on devrait utiliser un nom comme gateway ids, ou une forme en abbreviation. Aussi, je me demandais si on faisait pas juste un id au lieu d'une liste? Genre "gwid"

On pourrait en effet se permettre de ne pas supporter plusieurs Gateways via les sous clés si ça nous intéresse pas. En plus de gwid, j'ai aussi pensé à dgw_id ou dw_id. As-tu une préférence ?

[awakecoding]

Au lieu de scope_ids, on devrait utiliser un nom comme gateway ids, ou une forme en abbreviation. Aussi, je me demandais si on faisait pas juste un id au lieu d'une liste? Genre "gwid"

On pourrait en effet se permettre de ne pas supporter plusieurs Gateways via les sous clés si ça nous intéresse pas. En plus de gwid, j'ai aussi pensé à dgw_id ou dw_id. As-tu une préférence ?

après réflexion, je pense qu'on est mieux d'y aller pour un seul id au lieu d'une liste, je pense pas qu'on veut s'embarquer dans un système de subkeys utilisable pour plusieurs gateways à la fois. quand on arrivera au concept de "gateway farm" on pourrait régler le problème avec un "gateway farm id" unique partagé par tous les mêmes de la même "ferme" de gateways. Dans les deux cas on aurait quand même juste un id, pas une liste.

Pour le nom du claim, on peut p-e préfixer de jet_ comme pour plusieurs autres private claims:

• jet_gw_id
• jet_farm_id

Ignore tout ce qui est gateway farm pour l'instant, on est pas rendus là, mais au moins ça donne une idée de comment régler le problème de load balancing dans le futur. le "farm" serait un scope regroupant plusieurs gateway, et on pousserait le meme farm id à tous les gateway membres de la meme ferme.

[CBenoit]

Bonne idée, je vais faire comme ça ! 👍

[awakecoding]

LGTM