Progress with recommended storage configuration for X.509 + tokens

• CMS started with SAM tests using tokens (found by reading dCache-support#10437)
  • yes, started to commission EOS with tokens
  • XRootD sites are next, followed by dCache and StoRM
  • issues with tokens stored in a file with newline character(s)
    • not stripped by our clients (gfal2, xrd, ...) and break HTTP request headers
    • this may be very common mistake
      • CMS prefers if clients gets more "clever" and always strip newline from passed token content
      • client could also just report reasonable error message
• ideas how to use tokens for user / group storage areas
  • scopes - default vs. restricted vs. normal
    • CMS still rely on restricted storage.*:/ scopes + scope policies
  • discussion about client_credentials
    • currently any user can configure this grant type for a client
    • this grant type should be configurable only by IAM Admin (similarly to the token exchange grant type)
      • it may be "dangerous" to let random user create registration with client_credentials grant type
      • limited protection in OAuth for this grant type
  • IAM user can register arbitrary undefined scopes iam/issue#546
    • allows application developers to test their code with new scopes
    • IAM should always use some prefix for these user defined scopes, e.g. test:my_scope
• storage issuer basepath set to "" makes easier to understand which URL path can be accessed with given storage claim path restriction
  • URL $PATH & storage.*:$PATH would be same
  • e.g. https://se1.farm.particle.cz/atlas/atlasdatadisk -> reorganize namespace -> https://se1.farm.particle.cz/atlasdatadisk
    • basepath /atlas is stored in SE configuration for ATLAS issuer - make it completely hidden from clients
    • otherwise "user" needs to know what's stripped from URL and where storage.*:$PATH applies
      • e.g. how can user know that storage.read:/atlasdatadisk applies directly in https://se1.farm.aprticle.cz or https://se1.farm.particle.cz/arbitrary/prefix/for/atlas/vo
    • simplify - everything starts with "/"
    • easily configurable with dCache rootdir for mapped issuer identity
      • already used by some sites - same URL points to the different part of namespace for different identities (VOs)
  • full path would be still required for open access in case we would like to publish some data anonymously
  • CMS namespace can't be reorganized this way for shared TAPE & DISK endpoint
    • OPTIONAL - start VO namespace directly in "/"
    • low priority
  • complexity with possible different URL vs. storage.* path is hidden by tools like Rucio
    • changing namespace to start in "/" for each VO most probably not generally worth of effort