Overly complex scope hierarchy

[clundie-CL]

Problem description
Related to review comments included with PR #73

The API currently uses overly complex scope naming patterns for authorization, such as:

network-access-management:isolated-networks:wifi.auxiliary:write

This results in a 4-level deep scope structure (api:resource:subresource.role:action), which exceeds the typical 2-3 levels recommended by CAMARA. Such deep scope hierarchies are difficult to implement, manage, and audit.

Expected behavior
Scope names should be simplified to use no more than 2-3 levels, following the CAMARA pattern (e.g., api:resource:action). This will make authorization easier to manage and more consistent with other CAMARA APIs.

Alternative solution
If fine-grained access control is required, consider using explicit resource attributes or claims within the token, or separate endpoints for different roles/actions, rather than encoding all details in the scope string.

Additional context
This issue was identified during the CAMARA design review. Simplifying scope hierarchies will improve maintainability, reduce implementation complexity, and align the API with CAMARA security best

[caubut-charter]

Closing #13 in favor of this issue. Captured content but realistically needs a holistic review on scopes.

Problem description
CAMARA API guidelines do not have support fine-grained or role-based scoped.

Expected behavior
The API spec to follow the CAMARA API guidelines.

Alternative solution
While not preferred, we could add adjectives to the model names for roles, such as PrimaryIsolatedNework, and something like the following for fields: ServiceSiteWithLocation. Resources in the scope name would just need to reflect this. The problem is the potential number of permutations causing many more scopes.

Additional context
Fine-grained scopes are for privacy while supporting B2C, B2B2C, and B2B2B2C use cases.