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()) Regards, Inga
