User / group managed storage areas

IAM admin have full access to all VO data on all storage sites that give access to the particular issuer
it may be tricky to configure and use tokens for non-grid storage areas, e.g. ATLAS CERN group disk (ServiceX#507)
- access to whole namespace with storage.read:/ can't be revoked in the subdirectories
  - OK for CMS where all users have read-only access to the all CMS data
  - no private data for users / groups - everything readable by any VO user
    - not so clear for ATLAS
    - user can change permission on EOS mounted as posix filesystem
      - revoke access to subdirs
- site specific namespace would result in complicated IAM scope policies
  - e.g. "atlascerngroupdisk"
  - can't be fully enforced (no aud in IAM scope policy definition)
- it may be tricky for users to understand which scopes they are allowed to use
  - e.g. storage.read:/atlascerngroupdisk/phys-higgs/ for access to root://eosatlas.cern.ch//eos/atlas/atlascerngroupdisk/phys-higgs
it would be easier to use wlcg.groups for storage areas mounted also as a posix filesystem
- e.g. /eos/atlas/atlascerngroupdisk is mounted as a posix filesystem (different permission model)
- tricky / impossible to configure same access permissions with capability
- groups doesn't provide storage.create functionality => we can't limit damage done by rogue jobs / tokens stolen from jobs

ATLAS XCache & tokens

ATLAS just prepends XCache in the URL, e.g. root://xcache.example.com:1094//root://storage.example.com/path/to/file
it is not clear which tokens should be used for XCache and than for final storage
- storage.read:/root://storage.exmple.com(?)
- different scope necessary for final storage
used for job stage-in => not relevant for DC24, but we should try to identify all valid and problematic cases asap
- some xroot:// (protocol) features may not work properly without updates / improvements / changes

jobsub_lite uses SciTokens (https://scitokens.org) to authorize users to submit jobs, write to storage, etc.