Attendees: Brian, DavidC, Tom, DaveD, Jeny, Linda, Mine, Paul, Maarten, Alex, Hannah, Enrico

Notes:

• User Info
  • After much discussion, seems like the data is reasonable and legitimate
  • It’s important to be able to get traceability information. This can be protected by only enabling certain trusted clients to request the “profile” scope that enables query of the UserInfo endpoint, and other clients must exchange tokens to be able to get the data
  • How can we get traceability for a token that has expired? No longer possible to query the UserInfo endpoint but we need to resolve the sub of the token to a user.
    • Subjects must be bound to an individual, but an individual can have multiple and it can change
    • Not expected that subjects will change often
    • If subjects change, history must be maintained
      • But can only be kept for the duration of data protection policy?
        • This is a general problem that traceability is lost over time (e.g. at Fermilab it is 6 months)
  • Should subjects be anonymous (opaque)?
    • No: DavidG (IGTF) thinks they should not be anonymous. Having information available, e.g. email, aids in access between infrastructures
    • Yes: Having identifiable identifiers encourages sites to "get into" VO business and directly contact users even if they shouldn't (if it's an email). Typically there has to be a cross reference from a robot to an actual user.
    • Perhaps this discussion is above this group's scope - should services have direct contact with users or should it always go through the VO?
      • VOs will decide whether to mostly use Robots or direct user tokens
        • Even storage access is moving away from end user certs
      • We need to make sure that we don't assume one way or the other
      • Believe that it's approved by the MB that services go through VO to resolve users
      • Sites are not involved so far, e.g. traceability might be a requirement for the sites for legal purposes. Understood that Robot certificates should contain some link to a user but often don't (?).
• Update on Vault
  • Update planned for next week. Incompatible update (dash not to be used as delimiter, will change to colon). Code flow that can call back directly to Vault, no need to use Device flow. Some changes in the API.
  • Users will need to update htgettoken 
• Update on LHC IAM instances
  • ATLAS instance to be deployed

Decisions:

• Personal data can be available in the UserInfo endpoint but permission to request the "profile" or "email" scope should be restricted to authorised clients. Non-authorised clients would need to exchange a token with an authorised client to get the information (requires authentication with client ID and secret).
  • Unclear how this works in practice and whether everyone would be exchanging tokens constantly (load on system).
  • Any service that wants to get personal information (e.g. a log service) must either
    • be a client that can exchange a bearer token without the profile/email scope, for another token with the "profile" or "email" scope (by using the token exchange flow to modify scopes)
    • possess a bearer token that contains the "profile" or "email" scope
  • Expected that this will evolve with time

Actions:

• Include guidance on subject opaque vs non-opaque content when talking to VOs (Hannah see with Andrea how this is configured)
• Maarten to find summary of agreements for traceability