Attendees: Andrea, Nicolas, Romain, Mine, Brian, DavidC, Hannah, AlessandroDS, Maarten
Notes:
- Group Syntax
- REFEDS work to define SAML - OIDC group mapping, eduperson attributes. Q whether we should be following this in a "SAML-mindset"
- Length of tokens does matter, use of groups varies by VO
- Groups should be sent either
- as claims in the ID token
- as claims in the access token
- neither of the above, but resolved, starting from an access token, leveraging the standard OpenID Connect userinfo endpoint or OAuth token introspection at the authorization server
- Organisation claim,
- it is also a group effectively so why separate? This is from a VOMS equivalence of having a root group for a VO. It is conceptually identical to the issuer (atm). Perhaps make the org claim optional. We need to be careful to consider the case that issuers are not tightly bound to VO.
- the main reason to have this claim was to provide a
short way of addressing the issuer of a token in policies at services,
something shorter than the iss claim. While having the org claim may be
crucial to support multi-tenant scenarios, where an issuer can issue
tokens for multiple organizations, it does not help much in the WLCG
scenario, where the iss claim is mapped to a single VO. Consensus that
the claim can be made optional.
- DECISION: tokens are scoped to a single VO (this has been fine historically and discussion so far has centred around this)
- Seems reasonable to have a concept of primary group, can this be the first in the list, e.g. primary fqan
- Q points for GDB:
- should groups be hierarchical or not?
- single VOs as token issuers?
- well-known URL https://docs.google.com/document/d/1UbbqK-0U0c_7F_MERWwzsMUV67XsdsSHscht52xav8I/edit#heading=h.x8ff4yqve2hk
- There are 2 standards that state how discovery should be done
- OAuth discovery (more recent but problem with multiple issuers in multi-tenant scenario)
- OIDC
- Proposal that we support OIDC because it is more widely supported
- Revocation https://docs.google.com/document/d/1xt6NYQSpImrZkrNCE2LvtwM-0HbqcXD8f9eb7Dl6fgo/edit?usp=sharing
- Proposal to create a document with flows, probably as a separate doc
- Revocation is described as an OIDC standard
- Should ensure that token consumers and issuers are able to trigger this flow, especially for long running credentials
- Could be too prescriptive atm and makes more sense to be in a separate document
- This is linked with the refresh token flow, maybe we need to start digging in to how refresh tokens would work for long running jobs
- Refresh tokens are bound to clients, cannot be presented to resource providers
- Outstanding questions
- which format to use for groups? something to bring up at pre-GDB perhaps
Actions:
- @Hannah follow up on outstanding actions
- @Mischa@DavidG trust brokerage
- @Maarten operational impact of token verification and validation (in https://docs.google.com/document/d/1xt6NYQSpImrZkrNCE2LvtwM-0HbqcXD8f9eb7Dl6fgo/edit)
- @Hannah make org optional
- @Brian check that we are consistent with saying token issuer is VO
- @Hannah send notes and schedule next call
- @Andrea to include discovery information in main document
- @Hannah add notion of revocation into requirements doc (if not there already)
- @Hannah ask Andrea and Condor people to present in the next call
There are minutes attached to this event.
Show them.
