[Dev] Tizen 3 services: use case for multi user

Von Dentz, Luiz luiz.von.dentz at intel.com
Fri Sep 5 08:01:09 GMT 2014

Hi Patrick,

'UserA requests to pair with DeviceR
an authentication popup appears on UserA default screen (from DeviceL)
and DeviceR allowing pairing
UserB requests to pair with Device
an authentication popup appears on UserB default screen (from DeviceL)
and DeviceR allowing pairing
UserA and UserB are paired with DeviceR'

This is currently impossible, if a second user attempts to pair it
would invalid the first link key that is generated both locally and
remotely, this could only work if each User has access to different
local Adapter. My personal take is that Bluetooth settings should be
restricted by a security policy, the application that pairs then has
to set which users have access to that device which can be checked by
e.g. dbus-daemon and it probably only make sense to restrict profiles
that can access personal data, such as PBAP and MAP.

On Thu, Sep 4, 2014 at 6:23 PM, Patrick Ohly <patrick.ohly at intel.com> wrote:
> Adding Luiz.
> Luiz, any comments on how Bluez might support the multi-user Bluetooth
> use cases referenced below?
> On Thu, 2014-09-04 at 16:04 +0200, Dominig ar Foll wrote:
>> Hello,
>> we had in the recent days many discussion on the consequences of
>> activating multiuser in Tizen 3 services.
>> In order to help the developers who have to integrate Multiusers
>> concepts in their services we have created a few pages which describe
>> some use cases.
>> Currently we have created pages for:
>>     Multi-user PackageApplicationManagement
>>     Multi-user Bluetooth
>>     Multi-user WINET
>> And will will had more entries over the time.
>> See:
>>    https://wiki.tizen.org/wiki/Multi-user_Architecture#Multi_User_use_cases
>> Thanks in advance for your feedback.
> --
> Best Regards, Patrick Ohly
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.

More information about the Dev mailing list