Re: [RFC] D-Bus API for out of band association model

[Johan Hedberg <johan.hedberg@gmail.com>]

Hi Andrzej,

It would be nice if you could use some empty lines in your replies. It
was quite hard to distinguish the quoted text from your own.

On Thu, Sep 16, 2010, Andrzej Kaczmarek wrote:
> In case of NFC I guess data will be coming from some application or
> perhaps a daemon which can understand data coming from lower layers,
> which I guess will rather process raw data. So these data will come
> from the same level as bluetoothd resides or above.

Agreed. It might also come from below if the plugin talks to some kernel
driver handling the OOB communication.

> This is something that agent can communicate freely with. Also from
> our point of view OOB data is used in the same way as i.e. passkey and
> this is what agent provides. We don't care how it will receive such
> data.

The same goes for the plugin approach. If we wanted to care about the
actual OOB mechanism the would be no need to abstract this and make it
pluggable.

> Also Jakiumar gave quite good example where NFC application receives
> some data which is identified as BT OOB data so it initiates pairing
> with device specific agent which will provide these data.

Agreed. I do see now that a D-Bus based approach might make more sense
in the end. On the other hand, we could still abstract this inside the
daemon for plugins, and then there'd simply be a special (default)
plugin that'd expose this over D-Bus.

> Do I understand correctly that also plugin or daemon should manage
> received data? Won't it make bluetoothd store unnecessary data, i.e.
> for devices we won't use anyway?

This would be completely implementation specific. It could be within the
daemon or delegated to some external component. The only certain thing
would be an interface for the core daemon to get the OOB data when it
gets an IO capability request.

> Also what in case we want to use several different secure channels?
> Multiple plugins?

Yes, that would be possible.

> In case of agent, we make single call and no need to worry where the
> data come from. Agent is platform dependent anyway so platform vendor
> can put required logic there.

Right, but at the same time it would also require you to multiplex all
potential available OOB methods through a single agent. So in that sense
the agent approach is more restrictive (with plugins we could at least
allow multiple of them).

One thing I'm quite concerned about is that I wouldn't want to add an
extra rountrip to an external process for every single IO capability
request that we get. This extra work should only be done if we know that
there's a non-zero probability for the existence of OOB data.

We could either have the agent tell bluetoothd about the OOB capability
somehow, or we could define some new sort of external "OOB data
provider" D-Bus object. The benefit of using a new object separate from
the agent is that we could allow multiple of them whereas there can only
be one agent right now. And only if there'd be one or more of these new
types of objects registered would bluetoothd make the extra roundtrip
when it gets an IO capability request.

Johan