[9:38] Zha Ewry: So... I know there's been some discussion of looking at Chat/IM next, and that's fine, but.. I'm going to try, very hard to get us to figure out how to do next steps on trust and component relationships
[9:39] Zha Ewry: In particuilar, the heart of the long term story has to be anchored in *some* reason to bvelieve that sim X is in fact a sim we can trust, and the sim we wanted to talk to.
[9:40] Zha Ewry: and likewise, that "obscure asset server fiifty two" is in fact, a safe place to put an asset
[9:40] Dale Innis: The first thing we can just use like two-way SSL or whatevers?
[9:40] Dale Innis: or am I oversimplifying now? :)
[9:40] Latha Serevi: Sure, Dale, I think so ... but you need to decide if the party is worth interacting with.
[9:41] Dale Innis: Right, but those are two different things: "is this really X I'm talking to?" and "how to I feel about X?"
[9:41] Zha Ewry: We're using https and such, in caps, once we're talking to someone
[9:41] Goldie Katsu: SSL lets you know the communication is consistently with who you started talking with
[9:41] Dale Innis: An' SSL with signed certs lets you know that it really is X (modulo trust in the CA).
[9:42] Zha Ewry: So, once we get to the point where we have a cap from service Zed, we're willing to believe that it really is the guy under the ventilator in lower manhatten.
[9:42] Zha Ewry: But, before we can do that, we really do need to konw that it's MIB's server, and not someone spoofing them
[9:43] Zha Ewry: (its the usual nasty game of two way trust, between losely coupled parties)
[9:43] Zha Ewry: The good news, is we're not tryintg to do it on every transaction, or anythign close
[9:43] Zha Ewry: Baring a couple of very specific use cases, I'm pretty sure that we can believe that TLS (HTTPS) will do what we need to keep the transcations secure, once we get the pipe open
[9:44] Latha Serevi: That game seems "solved" just fine. It's propagating and maintaining "groups" (SL groups or trust groups, similar mechanism ) that's the subgoal that is top of my list.
[9:44] Rex Cronon: so, u do it only on login? what happens if somebody gets in the middle afterwards?
[9:45] Latha Serevi: One oversimplification I use is to think of maintaining trust relationships in two parts - (1) a set of bitmaps, one for each type of trust I'm interested in, one bit per entity in the world and (2) how to maintain those bitmaps. Anybody like or dislike that oversimplification?
[9:45] Dale Innis: So to initially tell who they say they are, need an appropriate certificate.
[9:45] Rex Cronon: for quite a while people believed that the earth was flat:)
[9:46] Zha Ewry: That's about two steps into the dance, and we should talk about that shortly
[9:49] Saijanai Kuhn: well, yes it does. man in the middle can take place if the pie has been given (CAP) unless the CAP is encrypted in the first place
[9:49] Zha Ewry: One is, "Did I get onto the login I wanted to, at the client/user interaction level, the first touch, as it were for a user"
[9:49] Saijanai Kuhn: ah, missed the part about cert BUT a cert for every region?
[9:49] Dale Innis: Sai: yeah, the certificate lets you do exactly that encryption.
[9:50] Dale Innis: A cert for every RD perhaps. Not every region.
[9:50] Zha Ewry: the other is, "I'm a software component, not a user, I need to konw you are in fact the person I think you are, at soime level.. or, for a lot of reason, "You are in the domain you claim to be in"
[9:50] Saijanai Kuhn: even every RD is pretty intense after a while. YOu need that certificate authority thing
[9:50] Goldie Katsu: so the private key of the cert would be shared by all servers in that domain? or all traffic in the domain comes to a point and is repackaged from there?
[9:50] Zha Ewry: (I can argue, but for lots of reasons don't buy that the Client/AD log in, could be the same, but it causes tons of problems to do)
[9:51] Zha Ewry: So.. I'm goign to argue the private key of the certy doesn't go out widely
[9:54] Latha Serevi: But that dance is a special case of what I'm interseted in, I think; and it would help to have a general framework. The general problem is something like "I want to do X and I have a seed cap. What steps to I take to find out who can do X with me and establish secure comms with them?"
[9:54] Zha Ewry: I'd like the cert level stuff to happen at the domain level, for a ton of reasons, including scalability, truyst and
[9:54] Goldie Katsu: looks at her coffee and wonders why her brain isn't starting yet.
[9:54] Zha Ewry: That's conflating discovering and security, I think
[9:54] Latha Serevi: discovery is the meat of the trust problem
[9:55] Zha Ewry: I tend to think of it exactly the other way around, with one.. caveat
[9:55] Dale Innis: And nothing with "seed cap" in it is a general question. :) We don't even know jsut where those are used yet.
[9:55] Zha Ewry: Yoiu have to be careful that Discovery does not leak information that protect security
[9:55] Goldie Katsu: So user alice wants to talk to region domain bob and is logged in to agent domain charlie. We want bob to know for sure he's talking to charlie?
[9:56] Goldie Katsu: before handing it back to alice
[9:56] Zha Ewry: That's one of the many use csase, yes
[9:56] Goldie Katsu: and also charlie talkign to bob
[9:56] Goldie Katsu: So how do bob and charlie know how to find each other?
[9:57] Dale Innis: Tend to think that's a separate question?
[9:57] Zha Ewry: "Region five seventeen wants to store an asset on behalf of user Joesephine, and has been trold ot use asset store "Bobs Asset Services" and wants to know if he's really reached Bob's asset services"
[9:58] Zha Ewry: and.. as this is the web, the usual aswer for how we finf things, is we have URLs to them. This begs the question of how we get the URLs
[9:58] Latha Serevi: Easy. We define a function securely-communicate-with(entity) and use it to exchange a session key.
[9:58] Goldie Katsu: I thitnk that how they find each other is part of how we know we trust.
[9:58] Dale Innis: Identity and trust are still separate problems, though.
[9:59] Rex Cronon: if that asset is encrypted u can store it even on "Hackers Asset Services";)
[9:59] Latha Serevi: discovery = finding entity id (the hard part). security = verifying and communicationg with entity (mechanisms must be there, but thoroughlty solved problem)
[9:59] Dale Innis: We keep doing this thing where there are like four problems to address, and we switch at high speed between them all. :)
[10:00] Zha Ewry: Pull it down to the client, and then up to the server? That only works for user held content, and not even there
[10:00] Goldie Katsu: That assumes you see the asset and you can decrypt it.
[10:00] Saijanai Kuhn: also assumes you're talking to the server without the AD in the mix
[10:01] Latha Serevi: Rex's point (modified a bit) has merit -- an asset server needn't be able to decrypt my asset, necessarily. Hm, optional encryption...
[10:01] Rex Cronon: u have a case that hold everything u have on, and u carry everywhere u go
[10:01] Zha Ewry: That doesn't cover any of the region held assets
[10:01] Latha Serevi: (you would pass decryption cap to RD along with instructions for getting asset from AD)
[10:01] Saijanai Kuhn: there's that pesky capabilities in virtual worlds thesis again. self-modifying encrypted caps. Read once and re-encrypt
[10:02] Goldie Katsu: ok so AD Charlie and RD Bob are settining up to talk with each other - Did they get their respective IP info or cert info from a virtual world nslookup?
[10:02] Dale Innis: But Latha, first you have to be sure you're really talkikng to the right RD. :)
[10:02] Saijanai Kuhn: Lath, only as long as the AD doesn't see the key
[10:02] Goldie Katsu: (Which could go to a dns like server or a hardcoded "host file")
[10:02] Zha Ewry: The key better never bee in cleartext, ourside the trust chain
[10:04] Zha Ewry: i think, for what it's worth, I'd push back and ask "what web standards exist today"
[10:04] Dale Innis: people type URLs on browser address fields. :)
[10:04] Goldie Katsu: For some things there are specific links - like friend feed supporting specific other web2.0 services
[10:04] Zha Ewry: I'm not convinced we need to invent a new discover and trust magement group scheme, for virtual worlds, when so far, the whole of the web and web 2.0 has been able to duck it
[10:04] Goldie Katsu: and in some cases it is open like I type www.amazon.com in my browser bar
[10:05] Zha Ewry: (If we need to, we need a strong justification for it)
[10:05] Goldie Katsu: In the first I trust friendfeed did the check
[10:05] Goldie Katsu: in the second I'm trusting DNS
[10:05] Latha Serevi: I am convinced we do need it. Zha -2.
[10:05] Goldie Katsu: and that dns is really sending me to amazon.com - and the cert then has to match the URL for added assurance.
[10:05] Goldie Katsu: so in that case TLS does a part of the trust verification
[10:06] Latha Serevi: I can't think of a web problem that involves a dozen cooperating entities with complicated interactions like this, in re-definable relationships that can't plausibly be hard-coded by hand.
[10:06] Goldie Katsu: And some servers will do the closed model (friendfeed) and others the open (dns + cert)
[10:06] Zha Ewry: Well, most of the web workflow people would probabl point at thier work
[10:07] Bartholomew Kleiber: In the web there is no good way currently to make digital assets non-stealable, so Latha has a point
[10:07] Latha Serevi: Will anyone second my proposal that everything be built upon a secure gruops mechanism? Isn't it totally brilliant?
[10:07] Zha Ewry: But.. the point is well taken. And one I make a lot. We're depending on a lot more shared stff than those people
[10:07] Goldie Katsu: so a dns like lookup - and a cert with something that says bob is bob once you've looked him up would address the identity part of the question.
[10:07] Goldie Katsu: What you want to do with bob is another question.
[10:08] Zha Ewry: One of the ways the Grid work int he early part of the decade foundered
[10:08] Goldie Katsu: I'll send creditcard information to amazon.com but not to 4m4z0n.com
[10:08] Zha Ewry: was tryign to worry too much about that early on
[10:08] Bartholomew Kleiber: but then again if we try to solve this here, and its not even solved in 2D web, this might as well and up in a 3D DRM desaster
[10:10] Zha Ewry: The point, Rex, is to make sure that you don't, in fact ever send you CC info to a hacked node
[10:10] Latha Serevi: CC info is a bad example; it uses passing-around of in-the-clear passwords (CC numbers). Use nmore specific capabilities (one-time-use CC nubmers)
[10:10] Goldie Katsu: well if I have a communication between my browser and amazon verified by TLS then the attack can only happen behind amazon
[10:10] Rex Cronon: but u might have no idea if ide if is hacked
[10:10] Zha Ewry: or at least, only to one which has been well hacked
[10:11] Latha Serevi: Security from 3rd parties is trivial; the wondrous secure group mechanism on which our entire edifice is based is not. Sopmebody second my proposal, dammit.
[10:11] Zha Ewry: (if someone breaks into my box, which has the csecure cert for "Big Blue Labs" and uses it properly, we're sort of hosed)
[10:12] Goldie Katsu: unless I can get a cert you trust that says hacked amazon IP is amazon.com which it shouldn't because only amazon.com servers should have amazon.com's private key
[10:12] Saijanai Kuhn: Things can get impressive though. I got a phshing email today from eric at animationmagazine.net Legit newsletter. Legit email, but all the links in the newsletter were to .tn/uuid/uuid/uuid
[10:12] Goldie Katsu: But we do rely on the domains to protect their private keys
[10:12] Zha Ewry: we trust certs issued by people like verisign
[10:13] Zha Ewry: and we trust TLS (https) to keep thing safe on the wire
[10:16] Zha Ewry: Mostly, when as a user, I try to find a service to use, or as a component, I try to locate a service that a user has asked me to use
[10:16] Dale Innis: ( Latha: I'd tend to think that a secure groups mechanism needs to be built on top of other stuff, not just the other way around. But write down your proposal and I'd be glad to read it. :) )
[10:17] Zha Ewry: For most... of our up and running bits of the world, they will have sets of services they talk to all the time
[10:17] Zha Ewry: ie. if I'm a region in a grid, I probably takl to all the trusted services in my ghrids all the time
[10:17] Zha Ewry: I also probably talk to a set of well known public services
[10:17] Zha Ewry: and.. fromt ime to time, someoen is goign to walk onto my grid and say
[10:21] Zha Ewry: and finally, there's always "hmm. Ok. I need a place to store this asset, and I want to search for an asset server"
[10:22] Zha Ewry: Regoins, and services, and stuff, presumably, have a list (possibly null) of default services for all thier routine tasks
[10:22] Bartholomew Kleiber: there could be some whiltelist of 'good' domains, a blacklist for bad ones and everything else could be configured by the XD owner if he want to allow this or not. How these lists are built, I dont know. How does this work with anti-spam services?
[10:23] Zha Ewry: I think, I'm assuming, baring some real surprise, that every thing I want to talk to, has a URL
[10:23] Graph Weymann: Wouldn't the asset server there always be already-chosen by theagent domain (copyable assets)or the region domain (non-copiable)?
[10:23] Latha Serevi: To decide if I'm gonna fetch from an unknown asset store, or teleport to an unknown region, I would require them to be listed in some top-down chain from somebody in my group of asset-store-knowers or region-knowers. I have selected that group based on the kind of security I want.
[10:23] Zha Ewry: The default, sure, Graphy, but I may chose to store my assets somewhere else
[10:27] Dale Innis: has to take off early, but will read transcript. I hope we can start getting these ideas written down in the WIki?
[10:27] Graph Weymann: You could sell an asset and it stays on the same server... that is a very nice simple case since the currency and assets can all be conserved by the same domain
[10:27] Zha Ewry: The use case, is that the region your in, isn't up to speed ithyour asset servers
[10:27] Graph Weymann: (not that there aren't other cases)
[10:39] Zha Ewry: well, in the sense that somethign like "zha.ewry.org" may be pointed down to "myisp.com"
[10:39] Goldie Katsu: I'd like to say it is an edge case but chances are it would happen lots of times. I build something on sim x and reuse it with other parts on sim y. right now they are all on SL inventory but it could be across multiple places.
[10:39] Zha Ewry: or a proxy service which takes all the asset store requests, stores them in two or three subordinate services and gives me a 99.9999% uptime case
[10:40] Zha Ewry: (assuming, of course, I run my proxy forwarding service on really good hardened hardware)
[10:44] Zha Ewry: You can, Graph, but in general for scheme other than http and https, you can't expect people to be able to reasona bout the properties
[10:44] Goldie Katsu: urls have to resolve down to something.
[10:45] Graph Weymann: Zha, what properties are you thinking of?
[10:45] Zha Ewry: Pretty much, what promises are in the URI space. In HTTP and HTTPs, that's very clear. I'l lhave to go an dlook at the whole URL spec, to sanity check what's the case in the less common cases
[10:47] Graph Weymann: I suspect that what you're thinking of is either also provided by what I'm suggesting, or invalid :)
[10:48] Latha Serevi: 's tail and ears droop and she gives a long sigh.
[10:49] Bartholomew Kleiber: I think she is refering to if there are properties if the URI scheme, that can be 'exploited' for our use cases.
[10:50] Graph Weymann: I'm asking what specific properties those are
[10:51] Graph Weymann: Also, when I said different schemes, I didn't mean ones that are different that much from HTTP - just ones with more robust resolution mechanism
[10:51] Graph Weymann: YOu can plug in https (dns+cert chains) now and invent or use somethin better later
[10:52] Bartholomew Kleiber: I thought that was the notion - or one at least
[10:52] Graph Weymann: I'm saying, don't ay "dns is good enough", say "https urls are good enough"
[10:52] Latha Serevi: wonders if we're all still present. Perhaps we could start wrapping up, with a couple of wiki pointers (where was Tao's writeup again; any wiki pages updated recently?) and a pointer to the next meeting?