User:Infinity Linden/OGP Trust Model UseCases

We are gathering use-cases here, starting at the high "what the user actually does" level.

teleporting use cases

• User from one grid teleports to another, and her inventory comes along

The user wants as much of her stuff as possible to be accessible on the new grid, working and appearing just as it did on the old one, except that any (meta-)information in the inventory that should not be accessible to the new grid should not move. (Should it be replaced by generic 'blank' information, or just not arrive at all? Or should information that is restricted in this way always or optionally include a pointer to "what to show instead" information to substitute?) Similarly content creators may want to prevent certain of the objects that they create from getting to the new grid. (Or do content creators only care at the point where the object is actually rezzed on the new grid, or copied, or modified, or given/sold/loaned to someone else?)

None of this can happen at all unless there is some common way of representing inventory items. Are we going to attempt to design a common representation? At the very least there should be a negotiation phase where the grids determine that they do in fact share some common representation (or that they don't, in which case inventory won't be able to travel).

• User from one grid teleports to another, and her attachments come along

As for inventory, plus the fact that attachments are rezzed at TP arrival time. Things should work as in the old grid, except that any metainformation or actual information (including textures, prims, etc) that is forbidden to the new grid via access control should not move (see note above on substitution questions). Content creators may, again, want to prevent their objects from being rezzed in the new grid (this is (even) more likely a concern than with inventory).

Representing attachments (or rezzable items in general) is more complex than representing inventory items. Again, there needs to be a negotiation phase to make sure that the two grids / domains have some representation in common.

• User from one grid teleports to another, and rezzes an object from inventory there

Any differences here from the attachments case? The destination grid does of course have to make sure that the agent is allowed to rez things there according to its own local policies, but that's a local decision.

• User from one grid teleports to another, and gives something from her inventory to another user there
• User from one grid teleports to another, and sells something from her inventory to another user there
• User from one grid teleports to another, and rezzes a vendor that another user then buys from
• User from one grid teleports to another, and pays someone in that other grid some currency
• User from one grid teleports to another, and receives some currency from someone in that other grid
• User from one grid teleports to another, creates something, takes it into inventory, and returns home
• User from one grid teleports to another, creates something, leaves it there, and returns home

Some threat-model cases

• Attacker contacts RD1, attempts to masquerade as AD1
  • Known authentication problem; use two-way SSL, public and private keys, all that "messy but we know how to do it" stuff.
• Attacker contacts RD1, authenticates as an otherwise-unknown ADz (what should an unknown AD be able to do?)
  • Two points of view were expressed at the AWG meeting on 2008/08/12: Sai was very concerned that a rogue AD could claim to be logging in a person, but give an agent URL that was actually being monitored or proxied or used by the rogue AD, and thereby make copies of everything the agent got. Dale pointed out that even if we prevent this, the attacker can just _actually_ log in to a trusted AD and use a client-side copybot to make copies of everything he gets; so it seems like the untrusted-AD attack doesn't get the attacker anything that he couldn't already have gotten more easily elsewhere. This may ultimately be a grid-policy decision: how much trust does an RD have to have in an AD before it allows it to rez an agent in the region?
• Attacker contacts RD1, authenticates as an ADz trusted to rez agents, and then requests to rez (say) an avatar named "Dale Innis", even though the real Dale Innis's human is sound asleep and has never heard of ADz.
  • Consensus was that AVs would be differentiated by their AD (at least in the case of "foreign" AVs), so this Dale Innis would have "Dale Innis @ ADz" over their head instead of "Dale Innis @ SL" or whatever, and would not be allowed to access any things belonging to, or otherwise take actions as, "Dale Innis @ SL".

Transitive trust

• so i operate a public-facing "corporate" sim and an agent domain for our corporation.
  • how do i establish a "trust relationship" with Linden Lab's SL sims so agents registered by our corporate AD can rez on LL's sims?
    • 1. put into place the appropriate legal agreement, whereby i promise to Linden Labs that our corporate AD will behave itself, not forge logins, not proxy for AVs and steal assets, etc.
    • 2. install the relevant public keys / certificates at both ends so the corporate AD and the LL RDs can prove to each other who they really are.
    • 3. add the identity of the corporate AD to the LL list of trusted ADs
    • 4. when someone logged into the corporate sim wants to teleport to a LL region, the corporate AD contacts the LL RD, they mutually authenticate, the RD looks up the AD in the trusted list as in (3), and the teleport occurs as per current OGP TP spec
    • 5. remaining issues?
• so i operate a region domain for something like an industry group and i want to allow only agents registered through agent domains operated by each of our industry group members
  • how do i establish a "trust relationship" with each of our group members' ADs?
    • in the simplest case, just do the above steps for every group-member AD; but see next bullet
  • can we create a "trust bridge" so all i have to do is trust the bridge, and then the bridge trusts all the industry group members?
    • in this model, when the RD needs to know whether it should trust an AD, it goes out and asks the bridge if the AD is in the bridge's trusted list (modulo caching etc). All that has to be known at the RD in this case is the address and identity of the bridge