Minutes eduroam meeting, Part 1: task internal

State of play of sub-tasks. Where are we, what's blocking where, and how to resolve it?

ST1: eaaS (IdP and SP)

• concentrated on IdP function
• we have the eaaS road map
• eaaS IdP pilot planned to start in Jan 2017
• SW explains/demoes how the current admin and user interface works
• Do we consider e-mail as a safe method for sending token and import password to the user? Yes (conclusion after a long discussion). Alternatives:
  • Do not specify transport (current approach)
  • send via email (good enough for pilot phase, change implementation to allow sending to email recipient)
  • send via secure messengers (e.g. Facebook messenger). More secure than email! Would need to work out how to use third-party APIs for messenging.
• Token issuing and consumption: several approaches possible
  • one issued, one to use (current approach). Issue more if user has more than one device.
  • one issued, use for max. number of installs
  • one issued, use for max, amount of time, arbitrary installs
• We have a running prototype; pilot will be started in January 2017
  • will use real eduroam uplink
  • use pilot testers to validate assumptions and make wise choices in the above points
• We need a final name, ideally without "as-a-service" nor "Cloud" in it

ST2: End-User Diagnostics

• SW explained monitoring architecture, what we can already monitor, and what's missing
• none of this is currently visible or usable for end users
• new tool gathers info from the monitoring sources and presents in a "very simple" way to end users.
  • Tell them what they should do if they can do something themselves.
  • or tell them that they can't do anything but wait; but inform via backoffice channel the one who can do something
• development work did not start yet, eaaS currently consuming bulk of time
• plan is to develop throughout 2017, with a pilot available Jan 2018
• suggested changes to monitoring infrastructure: duplicate monitoring hosts (several countries, anycasted or with mutliple client/server RADIUS definitions?)
• Probes: suggestion to make hardware-independent; maybe better base platform is OpenWRT rather than Raspberry Pi?
• Action on MM: find out the hardware reqs for eduroam probes. Is the major limitation speaking against OpenWRT that the file system space on OpenWRT devices is typically too small?

ST3: CAT module updates

• can only react to industry as it happens
• possible candidates on the radar:
  • the new OS by Google that merges ChromeOS and Android (name not known yet)
  • Windows 10 on ARM

ST4: Let'sRadsec

• lead developer currently not available, so work stalled
• current idea: there are two distinct provisioning processes
  • one for IdPs who have their own private key on a EAP server: let'sRadsec "scripted" issuing of RADIUS/TLS certificate (original idea)
  • one for proxies: create web service where operator logs in with his federated ID - which was previously authorised for NRO-level access to eduroam Operations Support Services - and let him upload CSR, getting back cert

Minutes eduroam meeting, Part 2: Campus IdP and eduroam-as-a-service IdP

• Campus IdP in different stage of development than eduroam-as-a-service
• development on one should not hold back the other
• as soon as actual product exists, two possible paths for synergy
  • eduGAIN-centric: eduroam aaS becomes an SP to the Campus IdP; eduroam credentials are issued if end user can login with eduGAIN credential. Makes manual IdM on the eduroam side obsolete.
  • eduroam-centric: IdM is done on eduroam side; resulting client credentials are X.509 certificates. Create Campus IdP authenticates users with (eduroam) client cert in browser. Any attributes still need to be stored Campus IdP side (client cert doing only authentication, no attribs). Unclear if client certs installed for Wi-Fi purpose are usable in browser. SW to find out and report to Campus IdP people.