Problem description
When creating a resource-based subscription to information related to a device (such as location, roaming status etc) there is today in the POST /subscription subscriptionDetail a device object to indicate which device the subscription relates to.

In case a 3-legged access token is used it is assumed that “the device associated with the access token must be considered as the device for the API request. This means that the device object is not required in the request, and if included it must identify the same device.”

But how should the usage of a 3-legged access token be interpreted when used with GET /subscriptions, GET /subscriptions/{subscriptionId} or DELETE /subscriptions/{subscriptionId} in which the device is not part of the request parameters?

Possible evolution
Describe the expected behavior, in the API-design-guidelines Subscription chapter, when using a 3-legged access token when invoking

1. POST /subscriptions in cases when there is a device object in the subscriptionDetail
2. GET /subscriptions and GET /subscriptions/{subscriptionId}
3. DELETE /subscriptions/{subscriptionId}

Alternative solution
On one hand it would be natural to view device information in the access token as a filter. On the other hand it would be difficult for an application to get a list of all its subscriptions no matter which device it involves with less than having a separate 2-legged access token for that purpose.

Additional context