UCTrust Wireless Notes - 2010-07-26

July 26, 2010, 10:00-11:00

Participants

Why Aren't We Doing Eduroam? - The Sequel

A Shibboleth-based solution does not seem where the world is going.  Should we reconsider that strategy?

• Not knowing who the user is causes extra work for host campus help desks in the event of infringement notices or to notify guests of vulnerabilities that are detected in their computers.  Shibboleth can send contact information (electronic mail address, name, a unique identifier, and perhaps an institutional contact). We believe Radius can too, but eduroam does not.
• 802.1x does not allow the hosting institution to present a web page with appropriate use policies and other information.
• Releasing identity attributes in eduroam will likely be a problem of interoperability with Europe, as 802.1x implementations will not generally be able to ask the end-user for permission to release the information.

We focused on three alternatives:

• Just join eduroam and accept the risks initially, but work within eduroam to add contact information.
• Create a ucroam using the same technology as eduroam, except that ucroam would pass the contact information.
  • The consensus was that successful authentication would indicate authorization by the home institution to be a guest elsewhere.
• Create UCTrust Wireless, based on Shibboleth and captive portals.
  • An explicit eduPersonEntitlement value would indicate authorization by the home institution to be a guest elsewhere.

Next Steps

• We will build a matrix of the three alternatives on the wiki, showing pros and cons, to facilitate selection of one or more alternatives in our next call.
  • See Comparison of Alternative Federated Wireless Authentication Strategies.
• Erik Klavon volunteered to research Radius's and eduroam's capabilities to send contact information.
• David Walker will contact the InCommon / eduroam-US people to discuss our concerns.