Token Trust & Traceability WG
https://codimd.web.cern.ch/exFF5cZWREuJErpP9VGmFA?view
# TTT 27/10/2026
Attending: Matt, DaveK, Mischa, Maarten, DaveD, Linda
Apologies: TomD, Donald
## Actions, Since Last meeting
- Action on Matt to contact DavidG, asking:
-- If in his view Let's Encrypt provides sufficient assurance for an IAM (and if not, we'd appreciate the reasons)
-- enquiring about the feasibilty of a "token certificate CA package" - it's production and maintenance.
Email drafted but not sent yet.
Anything from EUGridPMA we should note?
https://indico.nikhef.nl/event/8167/
Notes doc shared among group
Some discussion, AAOPS self assessment - done at EUGridPMA
Peer review likely not happening, but self assessment possible
-simple checklist, regular review
Some form of list of trusted issuers considered a good idea.
ML notes doing things in an ad hoc way at the moment. Efforts to have things documented. Some VOs not sure of the official documentation.
MS - broader then WLCG
MD - would we want a broad acceptance of services like cilogon?
ML - reluctance to externally outsource trust
MS - but do this with CAs
ML- sites and VOs add to this list (whether for good reasons or not).
DK/MS - needs to find something trusted by everyone.
DK - was asked by UK where trusted list was?
discussion
ML - Document on how to run a token issuer. About running a service in a reponsible manner, credentials involved. Follow the checklist.
Some sort of list of issuers we have "interacted"/engaged with.
MS - [AARC G071](https://aarc-community.org/guidelines/aarc-g071/) document on how to run an authority.
DK - nothing X.509 specific, but may need updating
MS - should at least use this document as input
DK - can also update this document if needed, designed to be maintainable.
ML - reminds of polciy on running services. This (AARC) doc is a specific case, so could create a bridging document between the two for token issuers.
DK - this could also contain the checklist
ML - remember this discussion for the next JPWG chat
## Trust Assurance Policy Doc continuation
- Splitting of client and server assurance requirements
Need input from DavidG.
ML - update the text to be less X.509/voms flavoured.
DK - anything not suitable for tokens should be changed
ML - document very focussed on IGTF/CAs
Hopes for quiet time
Discussion of Service Operations Policy.
ML -Could add a issuer paragraph to this, nice way of avoiding YA document
Discussion of Assurance levels, and the split between servers and clients
MS- notes that no real assurance guarantees of users
ML - could detail assurance in tokens, but not something that is/will be implimeted any time soon
discussion of "logging in via facebook", and not allowing it
MS- notes ligo citizen science initiatives, so use case for some non-WLCG communities (but not for WLCG)
ML - opendata portal,
ML - postpone discussions here
MS - only dcvota relevent for the document (distringuishing between validations by CAs)
discussion of let's encrypt, and how they only do domain validation.
article shared about let's encrypt, example of issues
https://thehackernews.com/2026/10/attackers-hijack-gh-sl-and-as.html
ML- so it makes sense for us to not consider all CAs to be equal.
price to pay in maintanance.
Not done full assessment yet. Costs in terms of security or maintenance and support.
## AOB, next meeting
November meeting dates: 10th and 24th November
15.00 CET 10th works. DK sends apologies.
Note next JPWG call on the 11th of November.