links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Higher Ed Security Scenario
Last updated at 12:40 pm UTC on 17 January 2006
A college may well be a locality in the Croquet universe for which authentication "at the border" is required, as Lex Spoon suggested. For the sake of the following discussion, let us assume a nightmare situation with all the usability issues that plague traditional security strategies. Then when we get together, we can talk about ways in which your needs are hopefully not this nightmarish, that allow us to regain some of the usability that we lose in the nightmare.

One of the key points to discuss will be the university's threat model. A curious but crucial aspect of the university threat model is identifying the aspects that cannot be achieved. In these cases, the goal is to become aware of the hopelessness so that you can focus your energy on solvable problems. The threat that comes to mind that a university will surely desire to prevent, but cannot, is allowing the student to forward his final exam to a separate exam-taker. If someone believes this can be prevented, we will have a very interesting discussion indeed :-)

So here's the nightmare scenario:

The general strategy described below is based on the idea, "go ahead and authenticate...but once you've tied authorities to the ID, do not use authentication for access control". See if the below fits your goals:

Sealers and unsealers are authority-based, not identification-based, means of exchanging authorities and data inside the context of a Croquet-like universe. They follow a pattern of implementation we refer to as "bundling authority with designation", which makes it straightforward to build friendly (and password free) user interfaces. By exchanging a pair of sealer/unsealers, the teacher and student open up an unbound collection of future authority exchanges in which each person knows where it came from and who it is going to.

Note that in the scenario I described above, all the usage of Verisign certificates is "out of band", i.e., it is not a part of the Croquet universe. Rather it is used outside the Croquet universe to establish initial Croquet relationships. Once those relationships are established, the certificates fade into the background.

Note also that, if you substitute for "Verisign certificate" the phrase, "a pattern of interaction that establishes identity to an extent adequate to meet your functionality requirements inside your threat model", there are solutions as diverse as the problems people face. My wife is a faculty member for a community college, her speciality is online courses. Inside the context of her college, instead of using Verisign certificates, they just use email addresses unencrypted: the student shows up physically at the college once, the college gives the person an email address, and emails that address to the professor. Once you get inside the Croquet world, her authorization mechanisms would be identical to the authorization mechanisms used in the nightmare scenario. The only difference is the initial setup, with a gentler threat model and physical interaction.