Token protection (enforced TLS)

by design for HTTPS protocol
- never redirect to HTTP with WLCG JWT token
- probably fine for dCache that use internal token (do I remember this correctly?)?
xroot client behavior
- token is opaque cgi data for client and it can be sent on unsecured channel
- everybody should always use xroots:// when they use tokens
  - basically exactly same requirement as in https:// case

we have to move to xroots (TLS) everywhere before we start to use token
- in future (timeline not yet defined) we must organize campaign where we'll ask sites to provide additional xroots:// protocol
minimum xrootd client / libraries version 5.x
- older experiment software releases may be built with 4.x
- impossible to access storage directly from job payload that use older releases
experiments should think (now) how to support older workflows once we move to tokens => xroots

Status

ATLAS
- use directIO only for specific jobs
- jobs can be forced to use copy2scartch for older releases
  - technically we are "ready" for xroots:// except transferring whole files can dramatically increase network bandwidth (+ storage utilization)
  - should be OK by the time we will be ready to move to tokens
    - new software releases built with XRootD 5.x
ALICE
- everything (read/write) is directIO
- old releases probably still use even XRootD 3.x libraries
- it may be very difficult to move legacy software to use 5.x
CMS
- reading is always directIO
  - hope that use of legacy releases will go down (to zero) over time
- writing done outside main job
  - easy to replace xroot version
LHCb
- ???

Token configuration for WLCG sites

prepare configuration for each experiment and each storage implementation
- may not always cover very complicated sites
- these sites have sufficient local expertise to understand requirements
prepare testsuite to validate site storage configuration
- not just operation that should succeed but also operation that should fail
- test regularly
  - CMS use SAM tests for protocol compliance
  - standard way to communicate issues with sites
organization
- start with friendly sites to come with reference configuration for each experiment and each implementation
- be ready before winter 2022/23 shutdown
  - good opportunity for wider deployment of "token compliant software and configuration"

documentation update (dCache, XRootD -> results)
does dCache configuration for prometheus supports also X.509(?)
recent tests for EOS and Echo
- most probably just incorrect mapping for "protected" area
xrootd storage.create
- open email thread with developers about XRootD 5.5 release plans
- necessary for compliance testbed
  - people plan to configure their XRootD flavor storage properly only once they have XRootD release that have a chance to pass tests