Hi Inga, and all, On Mon, 2020-03-02 at 17:15 +0000, Stotland, Inga wrote: > Hi, > > On Mon, 2020-03-02 at 16:56 +0000, Gix, Brian wrote: > > On Mon, 2020-03-02 at 20:25 +0530, Anupam Roy wrote: > > > Hi Michal, > > > > > > > --------- Original Message --------- > > > > Sender : Michał Lowas-Rzechonek < > > > > michal.lowas-rzechonek@xxxxxxxxxxx > > > > Date : 2020-03-02 19:52 (GMT+5:30) > > > > Title : Re: Regarding OOB authentication method & action for Mesh > > > > provisioner > > > > > > > > Hi, > > > > > > > > On 03/02, Anupam Roy wrote: > > > > > Also, I would like to know, whether there is any plan to > > > > > Request > > > > > external provisioning Agent to choose Provisioning method & > > > > > specific > > > > > action? The reason being, some *application* may be interested > > > > > in a > > > > > particular Security level & Authentication action, depending on > > > > > its > > > > > own I/O capabilities. > > > > > > > > For the record, we also need this is functionality. One of the > > > > possible > > > > scenarios is having a provisioner who doesn't have a reliable > > > > Internet > > > > connection and might want to fall back to (less secure) OOB > > > > actions if > > > > it cannot obtain OOB public key. > > > > > > > > We've been planning to send a patch implementing a D-Bus API for > > > > that, > > > > but it's not ready yet :( > > > > > > Okay, that would be nice & and will it allow application to choose > > > both a) "OOB Pub Key(With/Without)" as > > > well as b)"OOB Auth Methods(IN/OUT/Static/No OOB) & > > > Actions(Blink/Beep/Vibrate/Num/alpha etc.)"? > > > > The original plan for this was that an Agent defines it's > > Capabilities d-bus properties to indicate the OOB > > methodologies it is willing to support *for that session*. If you > > *sometimes* want to support "static-oob" or > > "public-oob" (for instance, to do a Certificate lookup via a WAN) > > then for that session, those capabilities > > should be included in the Agent's Capabilities array... and if the > > WAN is offline, and Certificates can't be > > retrieved, then leave that capability out. > > > > Otherwise, yes... The *initiator* daemon then looks at the > > capabilities of the remote unprovisioned device, > > and the capabilities of the local agent, and chooses the highest > > security method that can be supported between > > the two devices. But the list of available methods is still under > > the control of the App. > > > > The daemon indeed is missing the dynamic acquisition of the > provisioner's agent capabilities. I think there is no need for a new D- > Bus method, the current API is sufficient. What is needed, is to add > call for GetProperty() request of "Capabilities" on the Agent interface > (in agent.c) prior to sending provisioning invite (in prov-initiator.c, > before or in prov_init_open()) Yes, after talking with Inga, this is absolutely correct: I think we have everything in our existing API to support full control by the Provisioner App as to what OOB methodology gets used... But the functionality in the prov-initator.c to use it is currently missing. > > Regards, > > Inga > >
