User:Latha Serevi/OGP trust proposal based on secure groups
Preamble
In an open grid, how can the participants know which hosts, services, and individuals to interact with, and do so safely? This can be a question of resource discovery, of defining and maintaining trust relationships, of authentication, and of communication security.
This proposal is aimed at the first two of these four subjects, resource discovery and trust relationships. Latha thinks that the last two, authentication and security, are easily understood and a bit boring, so she assumes them to be solved for the purposes of this discussion.
The kinds of trust questions being asked by the participants of the open grid include, "is this individual allowed to rezz an avatar here?", "do I accept communications from this Agent Domain?", "does avatar A have permission to move object B in region R?", et cetera. The list of such questions is long, and under discussion. This proposal puts forward a mechanism by which a wide variety of such questions can be answered by re-casting them in the form "is A a member of group G?"
Assumptions
1. Individuals, services, hosts, and other entities have a unique ENTITY ID. Perhaps it's a URN.
2. It is possible to AUTHENTICATE and to establish low-bandwidth secure communications with any entity. This verifies identity and provides a channel to exchange session keys or capabilities securely.
With these assumptions, Latha ignores authentication and message security, and moves on.
What's a group?
Eventually, the open grid world must define something like SL groups, for two general kinds of purposes: conveying of permissions (e.g. land management groups), and group chat. The former requires a high degree of security, since these permissions can control valuable assets. The latter, group chat, may sometimes want to be be equally secure, but we must also support insecure chat, as the very simplest and most lightweight interaction between wildly different virtual worlds.
This proposal discusses the former (highly secure) groups as a very useful building block once implemented, and explores the consequences of this. The latter (insecure) groups used for lightweight chat are important, but are not discussed further here.
Latha's secure group proposal
WHAT IF we were able to define a secure group mechanism? Then we could build the entire OGP trust apparatus on top of it quite straightforwardly. Let's do that!
Straw man secure group proposal 1
To get us started, here's the simplest secure group mechanism Latha can think of.
External group interface
1. Each group has a controlling entity called the CONTROLLER plus a character string GROUPNAME. A group may or may not be its own entity.
2. Recall that any ENTITY can be authenticated and securely communicated with, by assumption.
3. A group is defined as a set of (ENTITY, character string) pairs who are called the "members" of the group.
4. An embership in the group can be verified by querying CONTROLLER supplying GROUPNAME and the possible member entity CANDIDATE. Usually one of the two normal results TRUE or FALSE is returned along with an expiration date/time. Alternatively, the controlling entity can return the WILL NOT ANSWER or DON'T KNOW along with an expiration date/time. If no result is returned within a timeout, the answer is taken as TIMEOUT with expiration date/time of NOW. (If the expiration date/time is a while from now, you might want to cache this group membership value locally until then.) (The membership result query will probably become a CAPABILITY in some less half-baked form of this straw man.) (Perhaps more metadata could be returned with the result, too.)
5. The group member list can be queried from CONTROLLER supplying GROUPNAME. Result is a list of (ENTITY, character string) pairs plus expiration date/time, or WILL NOT ANSWER, DON'T KNOW, or TIMEOUT as above.
Internal group implementation
6. The straw man implementation keeps a local white list, a local black list, and a list of daughter groups.
7. If CANDIDATE is in our white list of (ENTITY, character string) pairs, return TRUE.
8. If CANDIDATE is in our black list of (ENTITY, character string) pairs, return FALSE.
9. For each member of our list of daughter groups, query that group's CONTROLLER. If TRUE or FALSE is returned, return that result; otherwise continue until no more daughter groups.
10. Otherwise Return DON'T KNOW.