Present: Tom, John, Maarten, Dave D, Enrico, Federica, Adrian, Mine, Matt, Jacopo, Petr, Berk, Roberta, Anders, Francesco, Donald, Stephan

Apologies: Linda

Agenda: 

• Client_Credentials Scope Definition for host authentication workflows (NONE)
• Risks associated with systems remembering consent

Updates:

IAM:

• Two release candidates created for IAM in the last week, nearing final one. 
• Currently fixing minor issues, but no big changes anticipated
• Should be ready before the end of April - 1 or 2 weeks
• Testing image to be provided to CERN, including work from recent Hackathon.
• Berk / Anders to look to test next week.
• Potential good news next meeting!

Agenda:

Client_Credentials Scope Definition for host authentication workflows (NONE)

• Dave working to switch on using a host certificate to authenticate as a client - this capability will go due to certificate changes within browsers
• Switching to using Client_Credentials, as all is needed is the authentication of the host
• Currently this uses the scope of NONE, however it has been suggested that a dedicated scope should be used for verification purposes, or at least as a way to show what purpose the token is intended for
  • the "sub" and "issuer" claims will in any case be decisive for the actual AuthZ
• Scope of NONE may not be specific enough - but defining a precise scope fits the rest of the infrastructure, and keeps things more tight (and avoids potential regret!)
• If we are defining a new scope, what format is needed - host.auth could be a simple option
• Could make that scope privileged to control this, and what matters is the correct sub alongside this scope
• Francesco asks about replacing this, and checks it's only for HTTPS services. Here an access token would be presented instead of a certificate. Here it would be a case of checking the Issuer, Subject, and then adding a Scope
• For Dave's case, the service already had a Subject mapping, and so adding host subjects was easy
• A concerned service would need a list of accepted issuers for accepting such tokens, as usual
• Francesco suggests we may want to consider taking RFC 9449 into account for this use case.
• Action: Dave will make a profile PR with initial suggestions following this discussion. Done: 110
• Maarten: that new feature may be sufficient to warrant the release of v1.3 of our profiles

Risks associated with systems remembering consent

• The OpenBao project has released a CVE on code associated on Vault: https://app.opencve.io/cve/CVE-2026-33757 
• Security risks associated with the direct flow, as it did not have the user approval prompt - therefore vulnerable to Cross-site scripting
  • Requires fooling a user into clicking an arbitrary link
• Direct flow this is managed by OpenBao, but for Device flow - or other callbacks - this is on the responsibility of the issuer to prompt the user to release this information
• CILogon has an option to configure this, and has configuration available for a user to remember this prompt
• Francesco isn't clear on the direct flow described, and asks if it applies to confidential clients as well as public clients?
• Dave confirms it does apply to confidential clients (but later realized that's only in cases where the confidential client is shared such as with Vault or MyToken)
• Francesco asks for a written summary of the direct flow
• For the device flow with IAM, you either have a public client or with a command line with OIDC agent or equivalent - and with the OIDC agent flow, you do get the prompt
• The issue is a result of IAM remembering the consent step, allowing potential for Cross-site issues
• OpenBao has added a confirmation step to verify to prevent issues with the direct flow
• IAM will enforce mandatory consent for public clients, but Francesco cannot see issues with private clients. 
• Issue seems to be associated directly with Vault, due to Vault's API client
• Each new OIDC agent has its own unguessable client ID + secret, preventing an attacker from easily hijacking an existing client
• IAM can switch the default to NOT remember the consent, to instead be "Prompt next time". Should reduce the timeout on the device flow in order to mitigate as well
• Can also have a client configurable option to always prompt
• Action: issues to be made for IAM to update as per above agreements. Done: 1200, 1201
• Maarten asks how urgent those changes in IAM are?
• Dave suggests only CMS would potentially be concerned in the near future
• Stephan thinks the CMS IAM instance is already configured with the safe behavior that consent is asked every time
• Berk will check and let us know
• Hopefully the desired changes can be postponed to the 2.x series of IAM, to avoid spending more effort on the legacy codebase

AOB

Stephan asks if consensus was reached on two items discussed via e-mail:

• An option to disable token lifetime extensions currently allowed in token exchange workflows.
  
  • Per client, with a sensible default, as some clients (e.g. FTS) may need the current behavior.
• A way to limit a client to specific audiences.
  
  

Francesco and Enrico agree with those requests. Action: IAM issues need to be opened for them.