JWT Profile Meeting

Europe/Zurich
Description

Proposed agenda (suggestions welcome):

  • Each author gives a *very* short overview of their part 
  • We identify differences and commonalities 
  • Next Steps

In preparation for the call I’d encourage everyone to read the document -> https://docs.google.com/document/d/1XQvh2dxDivUstjQaS3K6tkpLyvXlEOR4QU8YtTzDqg4/edit?usp=sharing

Registration
Participants

Notes JWT Call 15th Feb

 

Attendees: Andrea, Brian, David, Hannah, Linda, Maarten, Marina, Miguel, Mischa, Nicolas, Romain

 

  • ALICE
    • 2 types of token
      • services, repurposed x509
      • storage, encrypted xml bundles, xrootd
  • dCache
    • macaroons
    • like JWT but with caveats and autonomous delegated with attenuation
    • tokens issued by the target service, only understood by service
    • JWT and macaroons are not necessarily mutually exclusive, could have a hybrid approach
    • All services must issue macaroons
  • EGI
    • Groups included in URN
    • Assurance profiles being worked on by AARC and REFEDS
    • OIDC flow to get authentication
    • OAuth2 endpoint for introspection extended for custom claims
    • Custom claim for group information in OIDC
    • x509 certificate provisioning through separate service, Master Portal, clients to master portal use OIDC
      • ssh to specific machine to get the proxy certificate
    • Delegation is planned
  • INDIGO
    • OIDC and OAuth2, more native use
    • Delegation supported by token issuer
    • Moving towards putting user info in token itself to become more self contained
      • Could support the same schema as EGI
  • Sci Tokens
    • Signed with issuer’s pub key, slightly different trust mechanism
    • Standard usage of JWT
    • Scope claim, not as prescriptive as caveats but getting there -> need a common scope language 
    • Path matching is not necessarily standard, reference library provided
    • This is purely authorisation, made to integrate with e.g. CiLogon
    • Have managed an FTS transfer purely with tokens

 

Q: What requirements from a group management system would SciTokens require? 

Proof of concept is simple web server, authenticate with GSI or VOMS proxy, returns coarse grained authZ of who is able to access which namespace.  

 

Additional points

  • Autonomous chaining/delegation of JWTs is not standard (have to return to issuer)
  • Perhaps we also want a hybrid JWT and macaroon setup, would need to consider availability of token issuer

 

Q: Does the token issuer need to support SciTokens & EGI or would OSG be willing to accept alternative tokens 

  • Some services need Identities 
  • Some services need Authorisation (from SciTokens perspective, some flexibility)
  • OSG storage side is willing to do JWT tokens
  • Suspicion that we won’t have a single schema across infrastructures, but perhaps one schema for WLCG
  • Web services mostly OIDC (very standardised so good)
  • Other services JWT and need to be specific with schema

 

Q: Work started through AARC?

Yes, already started. Will be taking this work into account. Timeline is April 2019. We need to stay in sync.

 

Q: Need to get agreement from Token Issuers (Checkin and IAM) and Infrastructures (EGI, OSG, dCache, STORM, xrootd, DPM, etc) that they will adopt schema. Do we have the right people in the WG?

 

Q: Could EGI checkin try interoperating with SciTokens? 

Willing. Token translation service there to compare between technologies 

 

Next Steps:

  • Hannah set up some google docs
  • Start to define Identity schema
    • Based on OIDC (Andrea to bootstrap)
  • Start to define Authorisation schema
    • Strawman (Brian to bootstrap)
  • Common aspects
    • Token validation
  • Hannah set up next call Middle of March
There are minutes attached to this event. Show them.
The agenda of this meeting is empty