Introduction

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 NAME. A group may or may not be its own entity, in which case NAME is null; or perhaps NAME is a conventional group name and CONTROLLER is some domain or other.

2. Recall that as an entity, CONTROLLER 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. Often NAME is null.

4. A single membership in the group can be verified by querying CONTROLLER supplying NAME and CANDIDATE. Usually one of the two normal results TRUE or FALSE is returned along with an expiration date/time. Alternatively, CONTROLLER can return 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 NAME. Result is a list of (ENTITY, character string) pairs plus expiration date/time, or WILL NOT ANSWER, DON'T KNOW, or TIMEOUT.

Internal group implementation

6. The straw man implementation keeps a local white list, a local black list, and a list of daughter groups.

7. Single membership queries are answered as follows:

 if CANDIDATE is in our white list of (ENTITY, character string) pairs, return TRUE;
 else if CANDIDATE is in our black list, return FALSE;
 else for each member of our list of daughter groups,
    query that group's CONTROLLER;
    if TRUE or FALSE is returned, return that result; 
    else continue until no more daughter groups.
 Otherwise return DON'T KNOW.

8. Membership list queries are answered as follows:

 concatenate the lists provided by each daughter group;
 subtract our blacklist; add our whitelist; return the result.

9. If our group is "open membership", any entity can add itself to our whitelist via an add-me query.

10. All other edits to our whitelist, as well as our blacklist and daughter groups list, are maintained manually by the human behind the CONTROLLER.

How to use secure groups to wire together an open grid

This is a drastic oversimplification, but here we go, one bullet point per participant. Each participant is choosing from a menu of options that suits their security needs.

Define some groups to answer trust-related questions

Client -- we assume each client works with one avatar name and home-agent-domain at once. The client defines its own groups called CLIENT/friendly-rights-honoring-region, CLIENT/possibly-friendly-region, CLIENT/friendly-agent-domain, CLIENT/friendly-avatar, and CLIENT/my-groups. Normally, the client delegates these to home-agent-domain, but it may choose to maintain its own whitelist and blacklist.

Region Domain -- defines groups RD/fully-trusted-regions (manually maintained), RD/bordering-objectexchange-regions (manually maintained), RD/teleport-ok-regions (with daughter group OPENSIMULATOR.ORG/teleport-ok-regions), RD/friendly-avatars (with daughter group AD/friendly-avatars for each known friendly AD).

Agent Domain -- defines groups AD/friendly-rights-honoring-region, AD/possibly-friendly-region-domain, AD/friendly-agent-domain, AD/friendly-avatar, AD/local-group-list, for each local group AD/Group, and for each client AD/CLIENT/my-groups. As an example, the group AD/friendly-rights-honoring-region might have a list of daughter groups RD/fully-trusted-regions for each RD it has an explicit agreement with, and no others.

Define the OGP operations and what group queries are used to check trust

Client: "should I rezz my restricted object in R?" --> R member-of CLIENT/friendly-rights-honoring-region
Client: "should I rezz my totally-unrestricted object in R?" --> R member-of CLIENT/possibly-friendly-region
RD: "may client C teleport here?" --> C member-of RD/friendly-avatars
RD: "may client C rezz object in land L owned by group AD/Group?" --> L is rezz-ok || L is group-rezz-ok and C member-of AD/Group
AD: "may avatar A send restricted object O to avatar B?" --> B member-of AD/friendly-avatar
AD: "may avatar A rezz his AD-hosted restricted object O in region R?" --> R member-of AD/friendly-rights-honoring-region

How do we get rid of the straw man?

We might use an existing technology to implement the secure-groups interface, such as

Or maybe not.

User:Latha Serevi/OGP trust proposal based on secure groups

Contents