Consider a dedicated read scope for Network Access Device retrieval (least-privilege)

[clundie-CL]

Problem description

The Network Access Devices API (network-access-devices.yaml) defines a single scope, network-access-devices:reboot, and uses it to guard both the read-only device-retrieval operations and the reboot-management operations:

• Read-only: GET /network-access-devices, GET /network-access-devices/{networkAccessDeviceId}
• Write / lifecycle: POST /reboot-requests, GET /reboot-requests, GET /reboot-requests/{id}, PATCH /reboot-requests/{id}, DELETE /reboot-requests/{id}

The limitation: there is no way to grant a consumer read-only visibility into a subscriber's Network Access Devices without also granting the ability to create and cancel reboots. A consumer that only needs device inventory/status — e.g. a monitoring dashboard or an asset/topology view — must be issued network-access-devices:reboot, which over-privileges it: a leaked or compromised token can reboot the subscriber's gateway(s), a disruptive action. This breaks least-privilege and enlarges the blast radius for read-only integrations.

This is pre-existing behavior surfaced by the #152 split: in the monolith the device GETs were mis-tagged under Reboot Requests; the split correctly re-tagged them as a first-class Network Access Devices capability, which is what makes the missing read tier visible. Raised in review of #153.

Possible evolution

1. Add a dedicated read scope — e.g. network-access-devices:read guarding the two device GETs, leaving :reboot for the reboot lifecycle (reboot operations would still imply the ability to read the devices they target). This lets a provider issue read-only device tokens and is consistent with the CAMARA <api>-<resource>-<action> scope convention and least-privilege.
2. Document the bundling as intentional — if standalone device retrieval is considered only a helper for the reboot flow, state explicitly in the scope docs that device read is intentionally bundled into :reboot, so consumers and providers know there is no read-only tier.

Option 1 favors least-privilege; option 2 is documentation-only.

Additional context

• Touch points: the security blocks on the two device GETs in code/API_definitions/network-access-devices.yaml, plus the scope documentation in code/API_definitions/network-access-devices.yaml (info.description) and code/modules/NAM_Common.yaml (openId description).
• Related: Overly complex scope hierarchy #78 (overly complex scope hierarchy) — any change here should be weighed against the overall scope model rather than added in isolation.
• Both specs are version: wip (0.x), so introducing a scope is non-breaking at this stage.
• Not blocking the Split API: Reboot Requests/Network Access Devices vs Trust Domain and Device Registration #152 split or the r3.1 RC — this is a scope-model design refinement for a later cycle.

[clundie-CL]

The same least-privilege gap exists on the domains side: GET /trust-domains/capabilities (read-only provider discovery) and the Trust Domain read operations are gated by the manage scope network-access-domains:trust-domains. If we add read variants for devices, we should consider them here too (e.g. capabilities discovery shouldn't require write capability).