Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Pilot Phase Documentation and Instructions

Table of Contents

Product Description and Implementation Status

The product outsources the technical setup of eduroam IdP functions to the eduroam Operations Team. The system includes


 (you may want to look at the roadmap: roadmap-eaas.pdf)

User Account Liability

As an eduroam IdP administrator using this system, you are authorized to create user accounts according to your local institution policy. You are fully responsible for the accounts you issue. In particular, you


Failure to comply with these requirements may lead to the deletion of your IdP (and all the users you create inside) in this system.


With this product, we are not interested in and strive not to collect any personally identifiable information about the end users you create. To that end,

  • the usernames you create in the system are not expected to be human-readable identifiers of actual humans. We encourage you to create usernames like 'hr-user-12' rather than 'Jane Doe, Human Resources Department'. You are the only one who needs to be able to make a link to the human behind the identifiers you create.
  • the identifiers in the credentials we create are not linked to the usernames you add to the system; they are pseudonyms.
  • each access credential carries a different pseudonym, even if it pertains to the same username.
  • to allow eduroam Service Providers to recognise that the same user is using their hotspot (even if using multiple devices and thus different pseudonyms), TBD: we send a RADIUS attribute to allow this grouping ('Chargeable-User-Identity'). That value is sent only on request of the Service Provider, and different Service Providers get different values; even for the same access credential of the same user.

Pilot Phase Location, Feature Activation

The pilot is accessible via the web page That web page contains recent development snapshot which is considered usable enough to allow pilot testing. It may be updated throughout the pilot runtime for bug fixing, feature additions or UI changes as found during the pilot test.


The test site starts with an empty institution database. As an NRO admin, you invite participants as you usually do. Note that it is in principle possible to also test other features of the upcoming eduroam CAT 1.2 on this site, but this is not the focus and the developers do not assert that any of the other features function as designed. The focus of this deployment is exclusively eaaS.

Federation Administrator: enable and configure eaaS

With a click on the usual "Click here to manage your federations" you can now see that your federation has federation-level properties (which it did not have in CAT 1.1):


With a click on "Edit", you can enable the feature (note that it is not called Silver Bullet any more as the screenshot suggests). The default maximum number of users an IdP can manage in the system is 200; if you want to set a different maximum, you can do that by also setting the "max users per profile" option. The third option, "Do not terminate EAP" does not currently have any function.

IdP Administrator: enrollment

The initial IdP signup remains unchanged compared to CAT 1.1: federation operators send email invitations to new admins as usual; there is no distinction between future "RADIUS" IdPs vs. "eaaS" IdPs. The choice whether to become a RADIUS vs eaaS IdP is with the IdP administrator. Please report any issues with that choice as part of the pilot usage reporting.


For the purposes of this pilot, it is of course expected that administrators choose the eaaS option. After doing so, the IdP admin is presented with the Terms of Use screen. The product can only be used after the Terms of Use have been accepted:

IdP administrator: usage

There is only one screen from which new user accounts can be created or imported, credentials can be assigned, and existing credentials and users can be decommissioned.

Adding Users

There are two workflows for adding new users:


It is part of the pilot evaluation whether these two choices for adding users are sufficient, or if other means should be added. Please ask your pilot participants about their preference here.

Issuing access credentials

Once a user is created, it is displayed on the page along with Delete and New Credential buttons. Clicking on "New Credential" creates an invitation URL. The URL is then displayed on the administration page. It is up to the administrator how to get that URL to the user in question. We expect this to happen usually over email, but it is part of the pilot phase evaluation whether leaving the means up to the admin (as implemented now) is a good way forward; alternatives include allowing to send an email directly from the interface, allowing text messaging, send via popular messengers, etc.

Invitation links are valid for one week from issuance, for the generation of a single access credential. The validity for the pickup by the end user is displayed to the right of the invitation link. Invitation links can be revoked by clicking the corresponding button on the right.

Credential revocation and Deadman Switch

Once a credential has been picked up by the end user, the corresponding certificate details are displayed instead of the invitation link. The "Revoke" button, if pushed, then revokes the already issued access credential and makes the login with it unusable. We strive towards a delay of less than one minute between push of the Revoke button and actual discontinuation of service for the end user.


TBD: how often does this have to be done?



The interface to end users is as lightweight as possible. Upon visiting the invitation link, there is only a single download button along with basic instructions. The operating system is auto-detected and cannot be changed. Please report in the pilot evaluation whether this worked sufficiently well for your users.


The installation program is a CAT installer like usual, with the addition of a client certificate which is protected by the import password that is displayed on the screen. The addition of the import password provides a basic safeguard against credential sharing. Other safeguards (which could replace this UI-intensive step) such as maximum amount of MAC addresses are under consideration. Please report how well the import password method works for your users.

Ongoing status

Once the eduroam credential is issued, the invitation link turns into an access link to the current status of all access credentials of the user. The user can review the expiry date, whether a credential was revoked, which devices any of his invitation links was bound to, and the certificate details with which his eduroam login is done

TBD: Access to status page without token value should still work with the client certificate. Not implemented yet.

eduroam usage

The installer sets up everything. The user should not need to interact with his operating system at all (at least, not any more than with other eduroam accounts).

One invitation, one credential

There have been extensive discussions how best to implement the invitation and enrollment system for end users. The current implementation binds exactly one invitation link to exactly one eduroam access credential on one device. As a consequence, users who want to configure eduroam on more than one device need to request several invitiation links (or manually go through complex processes to export and import client certificates and eduroam configurations; our working assumption is that end users can't usually be bothered to do this).