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?

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

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?