WLCG AuthZ Call

Thursday 8 Oct 2026, 16:00 → 17:00 Europe/Zurich

513/R-068 (CERN)

Notes:

Previous Actions:

•  

Proposed agenda:

• Validation of nbf, exp and iat 

 

Zoom meeting:

Link below, in the videoconference section. Please ensure you are signed in to Indico to see the meeting password!

Next Meeting: 

• TBC

Present: Maarten L, Petr V, Francesco G, Berk B, John SDS, Mine AC, Stephan L, David K, Roberta M, Tom D

Apologies: Linda C

News:

Francesco announces new VOMS releases, fixing various issues related to certificates (check the release notes):

• VOMS C++ client v2.1.4
• VOMS API Java v3.4.0
• VOMS Java client v3.4.0

Discussion:

Validation of IAT/EXP/NBF

Petr identified this issue due to failed tests, due to SciToken library validating against the Issued At (IAT), Expiry (EXP) and Not Before (NBF) claims.

Francesco shares that SciTokens has a pull request to allow for clock skew: https://github.com/scitokens/scitokens-cpp/pull/227. This allows a new configuration value to pass the clock skew back to the library used for checks. Francesco will investigate to see if this fixes the issues identified by Petr. Default seems to be 60s.

The validation done within SciTokens is always done by the underlying JWT-cpp's verifier, and so cannot be skipped, unless that underlying library is adjusted. Therefore, the skew is the best way to work around this issue today, while the consensus is that IAT must not be checked at all: it is just informational e.g. to help with debugging.

This has been an issue due to the time-sync daemon dying - this hasn't been observed at other sites as most of the time syncing likely works fine. Argument can be made that we should not need to correct for all possible problems at all sites - a set of basic requirements should instead be defined.

Do we need to push for this to be a 300s, or are we waiting to see the effect on operations?

Microsoft values are currently 5mns.

Status of "storage.poll" scope support in StoRM

Petr asks about support of that scope, introduced in v1.2 of our token profiles. Would like to make use of it for tape workflows in DC27.

Francesco will investigate and update.

Updates post Hackathon

Maarten asks do plans still look good? Is 1.15 release still aiming for Autumn.

Francesco says that they are aiming for the next few weeks, and not later due to internal deadlines needed for INFN.

Looking to include OPA features for potential tests in 1.15

Will have new effort available within StoRM shortly too.

Belle 2, DIRAC, and Certs

John asks if there are other DIRAC users having to do "strange things" with authentication. DIRAC is running daemons as clients with X.509 proxies, but this will be a problem with the EKU (web client) extensions being removed from host certificates by CAs - which is happening in the US (InCommon CA).

Maarten notes that this isn't an issue for IGTF only CAs - such as the CERN one - but this doesn't help the US InCommon activities. As of this month they are no longer issuing new host certificates usable as clients, while existing certificates can be used until they expire. 

The plan is to use real service certificates for client usage between services, but this will require implementation at the DIRAC level. Will look to make sure it's discussed and followed up at the upcoming DIRAC workshop in Prague, Oct 13-16.

IGTF-only certificates can still have long lifetimes (up to 400 days), while system-CA certificates will see their lifetimes shrink to 200 days (2026), 100 days (2027) and 47 days (2029).

StoRM and other MW

Petr raises when StoRM tries to validate tokens, it connects to the Well Known endpoint of IAM to download the public key set. Petr asks which trust store is used for this operation. See item 1 on this page listing major issues with MW. IGTF would like to be rid of the USERTRUST system CA that currently allows the CERN IAM web service certificate to be validated also in IGTF, and once that happens there would be a problem for token-aware services using IGTF CAs for those downloads. For example, the ARC CE (#4292). The question here is how Java services (StoRM and dCache) are handling that. The SciTokens library used by HTCondor and XRootD uses the system CAs (at least by default).

Francesco will look, and Maarten shares that the TTT WG will be discussing which sets of CAs are deemed OK for which purposes. System CAs must be used for downloading such key sets, e.g. via a cron job, i.e. independently of the code used to verify the tokens.

Tokens for users

Petr asks if there are experiments in which user workflows already make use of tokens? He would like to advance with that in ATLAS, after learning about experiences in other VOs. DUNE is known to have made tokens happen for users to some extent, because users in the US could no longer get certificates, but Maarten suspects those users are too much exposed to tokens: the idea is that tokens will be transparently handled by tools under the hood. Each user would just need to "log into the grid" once per day (like voms-proxy-init today). Progress with these matters may have to wait until after DC27.