FP Authorization and Authentication
This discussion originated in 7 points put down in the meeting of 2010Feb03#Authorization_and_Authentication
See also whiteboard drawing from the meeting:
Problems: Provenance, malicous uses.
Network level: Need to elucidate some scenarioes to make sure that the network design isn't precluding any desirable authentication/authorization/security issues for production FP systems.
Web client: Goal is to be able to specify the provenance of annotations created through the web client.
Requirement for client: Ability for users to authenticate to the client, authorizing them to retrieve their customizations of the client.
Requirement for the demonstration client in the prototype: low burden for users to provide the provenance of their annotations (their names, or anononymyous source).
In demonstration in the client in the prototype, no requirement for authorization to interact with the network.
Probably not a consensus: people need to discuss: Demonstration web client for prototype can:
(1) allow anonymous users to view FP data
- On this point I heard concensus in the meeting. --Bob Morris 03:34, 4 February 2010 (UTC)
(2) allow anonymous users to inject FP annotations
- This is a central point of disagreement. We discussed distinguishing authentication (e.g. login) from anonymity (e.g. requiring authentication but allowing optional anonymity. My strong feeling is that anonymous annotations---for whatever reason they are anonymous---are not per se useless e.g. for provenance, nor unfit for all conceivable (or inconceivable) purposes. A consumer can decide for itself whether an anonymous record is of interest. If there are scenarios in which a user wishes to query only against non-anonymous records, our query agents should support that. But this is no different from any other filter, e.g. "Subscribe to any messages about Quercus except those launched by Bob Morris". Once it is agreed that anonymous annotations are supported, solutions that require authentication but permit an authenticated user to anonymous annotations impose several additional burdens of design, implementation, and use: (a)the user must authenticate to no purpose other than to fit the implementation design (rather than the requirement to support anonymous annotations); (b)we have to analyze what motivations users have for making anonymous annotations and design to meet those. For example, a user may wish the system to record no indication anywhere of the connection between their identity and the anonymous annotation they launched. There may be other expectations that users have about anonymity and the resources to analyze and act on them have very little to do with our main goals.--Bob Morris 03:34, 4 February 2010 (UTC)
- Some people are worried about spam. I agree with Jonathan Rees, who visited the meeting, that spam is a small problem on platforms or topics that attract little attention. It's just not worth the spammers effort to tailor software to be an FP client. --Bob Morris 04:14, 4 February 2010 (UTC)
(3) allow anonymous users to assert who they are in annotations.
- I think this is fine, but perhaps unnecessary. It also introduce another level of trust that clients interested in provenance have to consider. Possibly it is an acceptable burden that users who wish to sign their assertions do so by authenticating themselves. Possibly without much engineering, a request by the user to authenticate themselves can be done at any time in annotation construction and launch, without loss of current data. (Maybe not so easy in an http connection environment). --Bob Morris 03:45, 4 February 2010 (UTC)
(4) allow users to authenticate to the client.
- Does this entail clients being authenticated to the network? Do we have to issue user GUIDs so that if a user annotates from two different clients, provenance efforts can establish that it is the same annotator? Is this different from any other form of authentication delegation? If not, it is delegation we should analyze, not this special case. --Bob Morris 04:14, 4 February 2010 (UTC)
(5) authorize authenticated users to customize UI elements in the client.
- I don't see why this is a requirement about a filtered push network, but what it might gain us is that encouraging users to authenticate will enable us to better track how people or machines are using our software in general and the particular demo network in particular. There are other possibly related encouragements. For example, users who authenticate can have a usage history available to themselves for convenience. For example, see the default bash history mechanism, together with Ctl-R <string> for searching through previous commands containing <string>, together with command editing in situ. --Bob Morris 04:14, 4 February 2010 (UTC)
(6) authorize authenticated users to store a default person name to be provided with annotations messages injected into the network.
- This speaks to my suggestion in (5) that we think about inducements ot authenticate. This is yet another good one. We should probably think about what we want to store and report in the identity of an annotator (which might, by the way, be a program, not a human). --Bob Morris 04:14, 4 February 2010 (UTC)
(7) allow authenticated users to redact their person name from annotation messages to be injected into the network and thus make anonymous annotations even though they are authenticated to the client.
- Here we need to analyze what someone redacting their name---or any thing deducible from their authentication---expects. For example, are we guaranteeing privacy under all circumstances. (Besides an engineering, configuration, and maintenance burden irrelevant to the FP project, complete pricacy is not even feasible for us. Any of the servers we would expect to deploy on will give law enforcement and the server owners substantial ability and right to examine the authentication data, or any other data held on the machines.--Bob Morris 04:14, 4 February 2010 (UTC)