RFA: Implementing HID spec recommendation for Keyboard PINs

RFA: Implementing HID spec recommendation for Keyboard PINs

[Scott James Remnant]

The Bluetooth HID profile recommends (4.1, p24) that rather than
prompting the user for a PIN on the host, which then needs to be
entered into the connecting keyboard, instead the host simply generate
the PIN and display it to the user instead. Part of this will be
implemented as a plugin, but since UI is involved, the Agent is
involved as well. As far as I can tell, there are two options:

 1) re-use the existing DisplayPasskey(object device, uint32 passkey) method

    Disadvantages:
    - this isn't a Passkey but a PIN, which means it would have to be
converted to a numeric before display. So the plugin would have to
generate a numeric, stuff it into a 0-padded 6-digit string for return
as the PIN but then we'd have to convert back to a numeric again for
sending to the agent.

    - the agent would not know that this isn't a Bluetooth 2.1 device,
but a 2.0 device following the HID recommendation - agents might want
to format the display differently, e.g. knowing that it will never get
keypress notification for these devices

 2) add a new DisplayPinCode(object device, string pin) method

    Disadvantages:
    - this adds a new method existing agents would have to implement,
but only in the cases where the plugin was enabled so hopefully the
distribution is at least aware of it - otherwise the important step of
what PIN to type would be lost

    - slightly larger code change.


My preference is for #2, but I wanted to request advice before proceeding.

Scott
--
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

Re: RFA: Implementing HID spec recommendation for Keyboard PINs

[Johan Hedberg]

Hi Scott,

On Wed, Jan 18, 2012, Scott James Remnant wrote:
> The Bluetooth HID profile recommends (4.1, p24) that rather than
> prompting the user for a PIN on the host, which then needs to be
> entered into the connecting keyboard, instead the host simply generate
> the PIN and display it to the user instead. Part of this will be
> implemented as a plugin, but since UI is involved, the Agent is
> involved as well. As far as I can tell, there are two options:
> 
>  1) re-use the existing DisplayPasskey(object device, uint32 passkey) method
> 
>     Disadvantages:
>     - this isn't a Passkey but a PIN, which means it would have to be
> converted to a numeric before display. So the plugin would have to
> generate a numeric, stuff it into a 0-padded 6-digit string for return
> as the PIN but then we'd have to convert back to a numeric again for
> sending to the agent.
> 
>     - the agent would not know that this isn't a Bluetooth 2.1 device,
> but a 2.0 device following the HID recommendation - agents might want
> to format the display differently, e.g. knowing that it will never get
> keypress notification for these devices
> 
>  2) add a new DisplayPinCode(object device, string pin) method
> 
>     Disadvantages:
>     - this adds a new method existing agents would have to implement,
> but only in the cases where the plugin was enabled so hopefully the
> distribution is at least aware of it - otherwise the important step of
> what PIN to type would be lost
> 
>     - slightly larger code change.
> 
> 
> My preference is for #2, but I wanted to request advice before proceeding.

3) Keep using RequestPinCode and have let the agent be responsible for
generating and showing a PIN to the user which is immediately sent as a
reply to the agent callback (while the UI prompt remains). The agent has
access to the remote device class through the device D-Bus object path
that's part of the agent callback parameters, so the UI should be able
to quite easily take this special action for keyboards.

	Disadvantages: (slightly) more code in the UI
	Advantages: less code in bluetoothd (and it's plugins)

As a variant of 3) we could also add a "hint" parameter to the
RequestPinCode callback to let the UI know that it'd be desirable to
show a fixed PIN (as opposed to a user-entered one) but let the UI
decide how it ultimately wants to interact with the user.

Johan

Re: RFA: Implementing HID spec recommendation for Keyboard PINs

[Scott James Remnant]

On Wed, Jan 18, 2012 at 2:56 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:

> Hi Scott,
>
Hi Johan,

> On Wed, Jan 18, 2012, Scott James Remnant wrote:
>> The Bluetooth HID profile recommends (4.1, p24) that rather than
>> prompting the user for a PIN on the host, which then needs to be
>> entered into the connecting keyboard, instead the host simply generate
>> the PIN and display it to the user instead. Part of this will be
>> implemented as a plugin, but since UI is involved, the Agent is
>> involved as well. As far as I can tell, there are two options:
>>
>>
> 3) Keep using RequestPinCode and have let the agent be responsible for
> generating and showing a PIN to the user which is immediately sent as a
> reply to the agent callback (while the UI prompt remains).
>

Marcel has specifically instructed me not to do that, stating that the
Agent is not supposed to be "smart" like this but only to directly
interact with the user.

See http://thread.gmane.org/gmane.linux.bluez.kernel/20391 yesterday

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

Re: RFA: Implementing HID spec recommendation for Keyboard PINs

[Johan Hedberg]

Hi Scott,

On Wed, Jan 18, 2012, Scott James Remnant wrote:
> > On Wed, Jan 18, 2012, Scott James Remnant wrote:
> >> The Bluetooth HID profile recommends (4.1, p24) that rather than
> >> prompting the user for a PIN on the host, which then needs to be
> >> entered into the connecting keyboard, instead the host simply generate
> >> the PIN and display it to the user instead. Part of this will be
> >> implemented as a plugin, but since UI is involved, the Agent is
> >> involved as well. As far as I can tell, there are two options:
> >>
> >>
> > 3) Keep using RequestPinCode and have let the agent be responsible for
> > generating and showing a PIN to the user which is immediately sent as a
> > reply to the agent callback (while the UI prompt remains).
> >
> 
> Marcel has specifically instructed me not to do that, stating that the
> Agent is not supposed to be "smart" like this but only to directly
> interact with the user.
> 
> See http://thread.gmane.org/gmane.linux.bluez.kernel/20391 yesterday

Well, it's what most BlueZ UIs do already now. They look for the
LegacyPairing property in DeviceFound signals, and if it's True they
will pre-generate and show a PIN to the user even before calling
CreatePairedDevice (for devices that can be assumed to have an
interactive PIN entering method).

One problem that you'll face is that it's not guaranteed that your side
will get the PIN request first or even at the same time as the other
side.  IIRC this depends on the controller manufacturer, who initiated
the connection, what security mode you're using (3 has some special
behavior), etc. I.e. in the worst case the user has already entered the
PIN on the remote side when you get the request on your side. Then when
you decide to auto-generate a PIN it's most certainly not going to match
what the user already entered on the other device.

For best interoperability with quirky devices I think the safest way
would be to make your best guess whether the user is able to enter the
PIN on the remote side (e.g. yes for a mobile phone, no for a headset
and yes for a keyboard) but still give the possibility to override this
if the user wants to enter the PIN by himself after all.

Johan

Re: RFA: Implementing HID spec recommendation for Keyboard PINs

[Marcel Holtmann]

Hi Johan,

> > > On Wed, Jan 18, 2012, Scott James Remnant wrote:
> > >> The Bluetooth HID profile recommends (4.1, p24) that rather than
> > >> prompting the user for a PIN on the host, which then needs to be
> > >> entered into the connecting keyboard, instead the host simply generate
> > >> the PIN and display it to the user instead. Part of this will be
> > >> implemented as a plugin, but since UI is involved, the Agent is
> > >> involved as well. As far as I can tell, there are two options:
> > >>
> > >>
> > > 3) Keep using RequestPinCode and have let the agent be responsible for
> > > generating and showing a PIN to the user which is immediately sent as a
> > > reply to the agent callback (while the UI prompt remains).
> > >
> > 
> > Marcel has specifically instructed me not to do that, stating that the
> > Agent is not supposed to be "smart" like this but only to directly
> > interact with the user.
> > 
> > See http://thread.gmane.org/gmane.linux.bluez.kernel/20391 yesterday
> 
> Well, it's what most BlueZ UIs do already now. They look for the
> LegacyPairing property in DeviceFound signals, and if it's True they
> will pre-generate and show a PIN to the user even before calling
> CreatePairedDevice (for devices that can be assumed to have an
> interactive PIN entering method).
> 
> One problem that you'll face is that it's not guaranteed that your side
> will get the PIN request first or even at the same time as the other
> side.  IIRC this depends on the controller manufacturer, who initiated
> the connection, what security mode you're using (3 has some special
> behavior), etc. I.e. in the worst case the user has already entered the
> PIN on the remote side when you get the request on your side. Then when
> you decide to auto-generate a PIN it's most certainly not going to match
> what the user already entered on the other device.
> 
> For best interoperability with quirky devices I think the safest way
> would be to make your best guess whether the user is able to enter the
> PIN on the remote side (e.g. yes for a mobile phone, no for a headset
> and yes for a keyboard) but still give the possibility to override this
> if the user wants to enter the PIN by himself after all.

I personally would prefer if we get this handling out of the UI code and
just do this for the UI. Do you think it is not possible to handle this
in a smart way one level down in bluetoothd?

Regards

Marcel