Hi Michał, > On Sep 16, 2019, at 11:58 AM, Michał Lowas-Rzechonek <michal.lowas-rzechonek@xxxxxxxxxxx> wrote: > > Hi Brian, > >> On 09/15, Brian Gix wrote: >> DevKey operations require authorization on the part of the applications >> making the requests. Messages to state changing Servers should use keys >> from the local Key Database to demonstrate authority. > > Alright, so if I understand this correctly: > > 1. If the application would like to change Config Server states on the > local node, it would need to: > - call ImportRemoteNode, passing the address of a *local* node and > the device key obtained from provisioner > - call DevKeySend to a *local* address, with remote flag set to true > - receive responses via DevKeyMessageReceived from *local* node, > with remote flag set to true > > Essentially this means that talking to a local node using device > security behaves in the same manner as if the node was a remote one. > > 2. If the application would like to implement an external model that > uses device security, it would: > - receive DevKeyMessageReceived calls from remote nodes, with remote > flag set to false > - send responses by calling DevKeySend to a *remote* address with > remote flag set to false > > This means that calling DevKeySend to a *local* address with remote flag > false would be forbidden, in order to force the application to use > ImportRemoteNode first? I think that is all basically correct. I switched the Boolean bit-sense such that the boolean parameter is “remote” on the send and “local” on the receive. And most importantly, your last point is an emphatic yes.... you will need to import your own device key to the key ring if you want to talk to your own builtin servers. The one exception will be nodes that have called “Create()” which are generating brand new mesh networks with themselves as unicast 0001. > > -- > Michał Lowas-Rzechonek <michal.lowas-rzechonek@xxxxxxxxxxx> > Silvair http://silvair.com > Jasnogórska 44, 31-358 Krakow, POLAND
