Attendees: DaveK, DavidG, Mischa, Hannah, Romain, Andrea, Maarten, Paul, Miguel

Notes:

• Comments in Doc
  • Proposal from Andrea that we stick to OAuth Jargon
    • Some dispute about what constitutes a client/bearer
    • Decision: overall try to use the RFC terminology
  • We should try and maintain the model for token issuer that we are used to with VOMS and identity tokens
  • Try and stick to general token verification definition
  • How do we want to establish trust in the client? How do we define who is able to get client secret? OIDC federation is relevant to this, could fulfil the role of test framework and will be well supported by standard libraries. Worth noting that when sites move to OIDC they will enable it for more than just WLCG, we need to make sure we don't form a silo. IGTF is playing the role of trust broker in simple OIDC federation cases, these are applicable to WLCG. 
  • Maybe we need to clarify the use of well-known url for both authorisation and OIDC approaches. Perhaps better to follow OIDC.
  • The verification workflow appears to be standard, not WLCG specific, so maybe we need to clarify 
  • Change to REQUIRED instead of MANDATORY 
  • Audience is often a ClientID but can also be a string that can target a set of services, we need to come back to this at some point
  • Short token lifetime means no need for revocation, at some point we should define precise maximum. We should discuss refresh tokens too, and their revocation. The impact of refresh on the services should be considered (general belief that this is a non-problem).
  • In a typical OIDC flow you get multiple tokens, identity & access. When this flow is used, the access token should contain groups as well
  • The "version" aspect is non-standard, discuss further.
  • **Key Point: Maybe we need to rethink whether we want pure capability authorisation tokens. General agreement that group based authorisation can be OK for certain services and would be in line with existing WLCG operations.**
  • * If sending scopes & groups there may be confusion at the client (here: a grid service) regarding which authorisation should be used.  Then again, some may just pick the scope, while others stick to the groups, if any, and there need not be any conflict*
  • * Any critical extension that is not understood should be refused - we need to find a balance between critical and optional attributes to avoid "needless" authorization failures.  A new critical attribute should imply a new version, which then would be refused by clients (grid services) that do not support that version yet.  Old versions can be phased out gradually per client (grid service).
• Identity Schema
  • Basically the standard from OIDC
  • We want to make the tokens as self contained as possible, for scalability reasons, so include certain claims in token
  • Non-standard claims = org (VO) and groups
  • Concept of group ordering and primary group (first one) - perhaps we want a separate primary group
  • AARC groups syntax seems to be too complicated and long (though benefit of being self contained). Should feed into JRA1 activity
  • Maybe we can use a shortcut that "/" means from issuer, and skip specifying urn? or use ":"
  • Do we want to stick with idea that a child groups implies membership in a parent group?
  • Importantly there are **no roles**
• Next Steps

Actions:

• @Mischa to check the RFC regarding Client definition
• @DavidG and @Mischa to add a paragraph on Trust Broker
• @Andrea to clarify use of well-known url 
• @Paul to add some clear overall text :)
• @Maarten to add some deployment considerations for token revocation and refresh
• @Andrea to add some text on revocation flow (flows currently not included in document) 
• @Hannah and @Mischa and @DavidG to speak with @Nicolas r.e. group syntax simplification
• @Nicolas provide a group syntax example with AARC guidelines
• ALL to comment on the document
• @Hannah schedule next call in May

Outstanding discussion points:

• Group syntax
• Versioning
• Token lifetime
• Standardised list of Audiences
• Identifier, where does this impact? Keep discussion in main thread
• Sending for consultation etc
• Refresh Token