links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Croquet Security Requirements Suggestions
Last updated at 12:39 pm UTC on 17 January 2006
(initial draft by Marc Stiegler)

David Reed's observation that "I'd like people to understand that we don't know what the word security means for Croquet" has left me aware that, in the absence of a little more shared perspective on security requirements, the upcoming presentation by Mark Miller and myself about security will take place in a vacuum where the quality of our suggestions cannot be assessed.

Below is a draft list of security requirements that seem reasonable to me for Croquet. This is not a proper requirements document. It drills down into architecture from time to time, where the requirements make certain architectural choices likely. It also wanders into philosophies of security. The goal is not a pure requirements document. Rather, the goal is to establish some basis of mutual understanding, or perhaps to establish the areas of clear disageement.

Some of requirements are also "anti-security" requirements. I.e., these are requirements imposed by Croquet usability goals (and other goals). The anti-security requirements allow us, I believe, to quickly reject many traditional security mechanisms.

Security Requirements Suggestions

Some Scenarios

It may help the discussions to have some example scenarios specific to Croquet. Here are a few that seem both relevant and have impact on how security is achieved.


The efforts to eradicate authentication in the course of normal activity seems good (the car key analogy is excellent!), but also note that it is very valuable if a Croquet user can determine that they are talking to the person they think they are talking to. For example, it would be desirable if Croquet allows people to schedule a private business meeting to take place in a Croquet room. A conclusion is that trustworthy identification would be valuable to support at the borders of the system. -Lex

Perhaps authentication at the borders is appropriate. Keep in mind the following factors before drawing that conclusion, however:

Remind me in the meeting to discuss this, if it remains an issue.


A concept that I'd like to make sure is present is the idea of auditability or history-keeping. - dpr
Separating access control from identity doesn't prevent using identity in an audit trail. – Alan Karp

Lex is almost right. I want to make sure I'm conducting business with someone authorized by the other company. That's more important that knowing the identity of the person. (Are you sure he wasn't just fired?)

When you want to talk to a specific person, you use a series of questions. (Who was our second grade teacher? Where did you live when we met?) Of course, if this conversation is ongoing, you can share a secret. You can still fall back on questions if you think the secret was stolen or given away.

Alan Karp

Think pet names with authority rather than identity, and I still believe you have a simpler system. Pet names with authorities and more traditional identities can both meet the new Auditing requirement, see above. This new requirement includes deterministic replay, which feels excessive for Croquet's requirements, but I have a dim memory of having read (in one of the TeaTime docs?) a statement suggesting this is a requirement. Is it? On the flip side, is full-up nonrepudiability, which I do not propose, a requirement?


I think the Cronies scenario, just added, is a little more concrete. An acceptible solution, for example, would be if I hand Andreas a key in person that he then uses to get access to my room. That works well if we have set up themeeting in advance, or if we have set up a general-purpose Cronies-only room (and key) in advance. However, it is no good if it is a surprise meeting. In such a case, it would be nice to appeal, not necessarily to the Croquet Central User Database, but perhaps to the HP Employee Database. That in fact may be a pet names solution, but since this is all starting to hurt my head I will stop now!

Oh, just one more comment: it is perfectly fine to redefine identity, meetings, authentication, and so on for an online context, but it needs to be done in a way that average joe's can use the concepts automatically. Members-only meetings just seem like something that Joe's will frequently want to do. (Lex Spoon)

One approach to the "members only" goal is to use brands. Brands could be represented in Croquet visually and conceptually as badges (for example). If you go to a conference or an sf convention, you get a badge; it does not have your ID on it necessarily, but having the badge proves your right to enter the convention rooms. In cyberspace, we can make those badges truly unforgeable and unspoofable (not the visual representation, of course, just the underlying brand...actually, I think we can make the visual representation unforgeable too, but that is really funky, using a "pet pattern" for the badge). So there could be an HP badge or a Croquet Cronies World Domination badge. We use brands in DonutLab, specifically the mints have brands so you can tell which kind of money you're getting paid. Ask and I shall show you how it's done.