Re: [PATCH BlueZ 1/4] doc/gatt-api: Add encryption flags

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Luiz,

> On Thu, Apr 23, 2015 at 12:21 PM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote:
> Hi Arman,
>
> On Thu, Apr 23, 2015 at 10:14 PM, Arman Uguray <armansito@xxxxxxxxxxxx> wrote:
>> Hi Luiz,
>>
>>> On Thu, Apr 23, 2015 at 7:20 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote:
>>> From: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx>
>>>
>>> This add encryption flags which can be used when registering a service to
>>> require encryption when accessing a characteristic.
>>> ---
>>>  doc/gatt-api.txt | 4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/doc/gatt-api.txt b/doc/gatt-api.txt
>>> index 088d285..8db35f2 100644
>>> --- a/doc/gatt-api.txt
>>> +++ b/doc/gatt-api.txt
>>> @@ -148,6 +148,10 @@ Properties string UUID [read-only]
>>>                                 "authenticated-signed-writes"
>>>                                 "reliable-write"
>>>                                 "writable-auxiliaries"
>>> +                               "encrypt-read"
>>> +                               "encrypt-write"
>>> +                               "encrypt-authenticated-read"
>>> +                               "encrypt-authenticated-write"
>>
>> So I guess you decided not to go with a "Permissions" property? I
>> guess that's fine but we need to handle this for descriptors as well.
>> So probably add a "Flags" property to GattDescriptor1 also. There
>> we'll want read, write, encrypt-*, and encrypt-authenticated-*.
>
> Sure, will do that in the next set. What is more important now is
> getting feedback if the API is good enough, I have been debating in
> using secure instead of encrypt, what do you think?
>

I'm fine with encrypt, I think staying closer to the GATT spec lingo
will be less confusing for developers. "secure" is somewhat unclear
whereas encrypt is very explicit and it has a matching ATT protocol
error that a developer can immediately associate this permission with.

Looking through some of the other platform APIs, I see these:

iOS:

typedef enum {
    CBAttributePermissionsReadable = 0x01,
    CBAttributePermissionsWriteable = 0x02,
    CBAttributePermissionsReadEncryptionRequired = 0x04,
    CBAttributePermissionsWriteEncryptionRequired = 0x08,
} CBAttributePermissions;

and Android has READ_ENCRYPTED, READ_ENCRYPTED_MITM, etc as you
already know. So "encrypt" should sound familiar to developers.

>>>                 array{object} Descriptors [read-only]
>>>
>>> --
>>> 2.1.0
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> Can you also update test/example-gatt-server with new characteristics
>> and descriptors that demonstrate the permissions feature? You can add
>> them as new vendor-specific test characteristics (there's a
>> vendor-specific test service in there) and/or modify one of the other
>> two example services (HR and Battery). Let's get that into this patch
>> set so we know we have some way to test it.
>
> Yep, I was thinking about that just now, will add this in the next version.
>

Cool, thanks.

>
> --
> Luiz Augusto von Dentz

-Arman
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux