User:Infinity Linden/OGP Trust Model UseCases

We are gathering use-cases here for the OGP Trust Model, starting at the high "what the user actually does" level. (See also AWG Use Cases.)

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

• Another sort of transitivity: a user TPs from one grid to another with some items in inventory, rezzes one on the ground, and sets "Allow Anyone to Copy", then later TPs home and logs out. The rezzed copy is now under the control of the foreign RD. Later someone from yet another AD comes by and attempts to take a copy of the rezzed object. The foreign RD should now verify that the rezzed object is allowed to enter the AD of the person doing the picking up. Should the foreign RD:
  • pass off that decision to the original AD,
  • consult the original AD in making the decision,
  • make the decision itself based on information in the asset data that specifies what domains the asset is allowed to travel to?

Some trust-policy styles

1. A commercial grid that has Second Life's c/m/t permissions system, a strong TOS about copyright violations and so on, and a commitment to preserving the IP of its content creators.

• In the TP scenarios above, no asset would be allowed to travel to an off-grid region unless:
  • The asset creator has implicitly or explicitly indicated willingness to allow that travel (many ways of indicating or gathering this indication can be written down), and
  • The target RD supports the set of permissions currently on the asset.
• So for instance a full-term object would be allowed to travel to a region that has no permission enforcement, as long as the content creator has indicated that such travel is allowed, but a no-copy object would not be allowed to travel to that region.
• Some other grid with similar concerns about protecting the intent of content creators, that additionally supported a "sticky permissions" flag (indicating that subsequent owners should not be allowed to alter the perms of the object), would not allow (for instance) full-perm objects with the "sticky perms" flag set to go to the SL-like grid when its users TP there, since the SL-like grid doesn't support the sticky permissions feature.
• Some other grid with similar concerns about protecting the intent of content creators, that additionally supported a "loanable" flag (indicating that subsequent owners should be allowed to loan the object to others), probably would allow objects with the "loanable" flag in either state to go to the SL-like grid when its users TP there, since although the SL-like grid doesn't support the "loanable" feature, that has no IP consequences: all objects are effectively "non-loanable" while in SL. Objects created in the SL-like grid and brought back into the loanability grid would come in with loanability set to some default value (probably 'false', although that's a local policy decision for that grid).

2. A noncommercial grid in which all objects are effectively full-perm in SL terms. (That is, other people still can't pick up your objects from the ground and walk away with them, but once you own any object, you can copy it, modify it, and give copies to other people at will.)

• (some outline here of which objects should be allowed in and out of that grid)

3. A noncommercial grid that has an SL-like c/m/t permission system, but doesn't do much to enforce it. The TOS contains a disclaimer that the permission system is just for convenience and may not be technically enforced, the grid has been known to casually link to and allow objects to travel to grids without permission systems, the grid will accept logins from any AD at all, and so on.

• (This is an interesting case because although the grid technically has c/m/t enforcement, and may be trusted in the sense that we believe it's non-malicious, the corporate grid above still wouldn't want non-full-perm objects to go there. This may be as simple as marking it as effectively a full-perm grid for asset-TP purposes, but we should think about it a bit I think. -- Dale Innis 13:20, 13 August 2008 (PDT))