Problem description
The API design guidelines state that scopes should be represented as:

• API Name: address-management, numbering-information...
• Protected Resource: orders, billings…
• Grant-level, action on resource: read, write…

For explicit subscriptions, giving an example of device-status, this pattern results in

device-status:subscriptions:create

And with this subscription, any one of the below event types could be subscribed to:

org.camaraproject.device-status.v0.roaming-status,
org.camaraproject.device-status.v0.roaming-on,
org.camaraproject.device-status.v0.roaming-off,
org.camaraproject.device-status.v0.roaming-change-country,
org.camaraproject.device-status.v0.connectivity-data,
org.camaraproject.device-status.v0.connectivity-sms,
org.camaraproject.device-status.v0.connectivity-disconnected,

The scope device-status:subscriptions:create doesn't give any insights on the event types.

Expected behavior

• For explicit subscriptions, the scope should give some insights into which event types could be subscribed to.

For e.g.
device:roaming-status-sub:create

• The new pattern should be documented in API design guidelines for explicit subscriptions
• The subprojects who have implemented this pattern for explicit subscriptions should make changes as agreed in design guidelines.

Alternative solution

Additional context