User:Zero Linden/Office Hours/2008 September 02

[13:09] Zero Linden: sorry -- last minute conference call that cut into my lunch
[13:09] Connected undefined:
[13:09] Morgaine Dinova: Tao: you wouldn't want Prok to be happy with your posts ... it would mean you're doing something wrong :P
[13:09] Mirt Tenk: hi Zero
[13:09] Graph Weymann: Hello
[13:09] Morgaine Dinova: Hiya Zero :-)
[13:09] Tao Takashi: :-)
[13:09] Mirt Tenk: I have a bumper sticker
[13:09] Mirt Tenk: "Well-behaved women rarely make history."
[13:09] Xugu Madison: Zero, morning!
[13:09] Mirt Tenk: applies to more than women
[13:10] Georgette Whitfield: I like that one Mirk
[13:10] Zero Linden: looks like a large part of our group is at Burning Man....
[13:10] Georgette Whitfield: The RL event?
[13:10] Tao Takashi: Burning Man also has strong Plone links :)
[13:10] Graph Weymann: Zero, do I correctly understand that you're the guy behind OGP using capabilities?
[13:10] Morgaine Dinova: True for all people ... if you don't rock the boat, you are invisible
[13:10] Mirt Tenk: tao this is good
[13:11] Morgaine Dinova: Hi Rex
[13:11] Zero Linden: Graph - I am
[13:11] Georgette Whitfield: Hi REx
[13:11] Tao Takashi: Hi Rex
[13:11] Rex Cronon: hi everybody
[13:11] Mirt Tenk: greetings
[13:11] Saijanai Kuhn: Zero, Graph's the guy who wrote a MUD in E
[13:11] Rex Cronon: i almost forgot:)
[13:11] Graph Weymann: Zero, I've been wanting to talk with you for a while :)
[13:11] Georgette Whitfield: Hi new arrivals
[13:11] Jonit Ivory: Hi all
[13:12] Mirt Tenk: hi
[13:12] Rex Cronon: hi
[13:12] valentine Biddle: hello
[13:12] Georgette Whitfield: Zero I just want your bear I donno anything technical don't ask me kthx!
[13:12] Morgaine Dinova: I don't have a Zero bear either! :-(
[13:12] Tao Takashi: btw, I wonder if we can add some header to the protocol which is optional to the domain server to send but needs to be sent by the client if present :)
[13:12] Mirt Tenk: no
[13:12] Morgaine Dinova: We are all alone, Raul
[13:12] Graph Weymann: Anyway, I'm a little worried that the capability nature will be overrun by people layering on identity-based schemes
[13:13] Georgette Whitfield: No Raul here we are
[13:13] Graph Weymann: (where not appropriate)
[13:13] Georgette Whitfield: No one is alone
[13:13] Zero Linden: Bears.... bears for sale....
[13:13] Raul Kranfel: wherea re you?
[13:13] Morgaine Dinova: Woohoo!
[13:13] Mirt Tenk: I'll have one!
[13:13] Georgette Whitfield: Yay!
[13:13] Xugu Madison: I'll trade you a door for a bear
[13:13] Georgette Whitfield: Thanks Zero
[13:13] Morgaine Dinova: raises hand for a bear
[13:13] Morgaine Dinova: Hey, thanks Zero :-)
[13:13] Georgette Whitfield: Cool
[13:13] Mirt Tenk: ty zero, I feel like I'm collecting beanie babies
[13:13] Georgette Whitfield: And it come with free coffee
[13:13] Georgette Whitfield: How cool is that
[13:14] Mirt Tenk: hot is better
[13:14] Zero Linden: Uhm....gee Tao --- meet Graph
[13:14] Zero Linden: Graph -- meet Tao
[13:14] Morgaine Dinova: Well this is only my second one, so not much of a collection yet. :-) I'll ask Tess next ... but Rob prolly won't give me one, hehe
[13:14] Tao Takashi: heh :)
[13:14] Zero Linden: my guess is that your aims are dimetric!
[13:14] Tao Takashi: SL meet the web
[13:14] Graph Weymann: Zero, and I talked with, hm, Which Linden, I think, who was interested, but knew nothing about capability design patterns
[13:14] Mirt Tenk: hm
[13:14] Morgaine Dinova: Web is so yesterday
[13:15] Tao Takashi: might be but the majority of people and devs is there
[13:15] Zero Linden: SO
[13:15] Zero Linden: yes
[13:15] Zero Linden: I'm the original capability architectect at LL
[13:15] Morgaine Dinova: Graph: we don't have any cap design pats in OGP yet ... want to give us some?
[13:15] Tao Takashi: but maybe I shouldn't bring up that topic again ;-)
[13:15] Zero Linden: so --- I suppose I have some thoughts on these issues
[13:16] Zero Linden: what'd like to hear though, is a succint statement of a) what Tao is achieving with his optionally required header and b) which identity problem Graph is worried about being layerd on top
[13:16] Zero Linden: you have ... oh, say, three sentences..... go!
[13:16] Zero Linden: :-)
[13:16] Georgette Whitfield: eeps.
[13:16] Zero Linden: feels like a game show host
[13:16] Morgaine Dinova: Er, "optionally required"? Is that like "slightly pregnant"?
[13:16] Tao Takashi: I basically want cookies so my server can ignore the cap part ;-)
[13:16] Georgette Whitfield: I wonder if my translator speeks geek
[13:17] Tao Takashi: one sentence
[13:17] Graph Weymann: uh, okay. well, it's a rather vague concern, but I'm afraid that the benefits of capabilities will be lost by way of putting higher-level protocols into place which are avatar-identity-based authorization (which gets you Confused Deputy, lack of delegation, etc...if you know those buzzwords)
[13:18] Georgette Whitfield: Crikey
[13:18] Zero Linden: I know those buzzwords -- but not everyone here does
[13:18] Graph Weymann: I hear lots of talk about referring to objects by UUIDs
[13:18] Tao Takashi: I don't
[13:18] Graph Weymann: but no facets
[13:18] Graph Weymann: (objects, avatars, groups, whatever)
[13:19] Morgaine Dinova: I think I know what Graph means. It's like if you try to hide continuations behind plain function calls, you don't really gain the full benefit.
[13:19] Graph Weymann: so anyway, I want to help you get these things right :)
[13:19] Xugu Madison: I like that there's a fine-grained permissions system, but I do wonder... why capabilities?
[13:19] Zero Linden: So - you must recognize that SL, even the eventual OGP, will probably, due to pragmatics, be a hybrid system
[13:19] Graph Weymann: oh, I won't be surprised
[13:19] Zero Linden: so, for example, the notion that every facet of every object will have it's own capability is just not tenible
[13:20] Tao Takashi: my header idea also stems from pragmatism, btw. because then you can sue plain web frameworks for the task and have a quite simple setup
[13:20] Morgaine Dinova: Tenable
[13:20] Graph Weymann: Hm?
[13:20] Zero Linden: can't spell.... he's dyslexic.... and doesn't mind if people put in corrections at all!
[13:20] Graph Weymann: I didn't follow that, what do you mean by facet, that is not a capability?
[13:20] Morgaine Dinova: That's a true american typo, "sue" in place of "use" :-)
[13:20] Tao Takashi: I also always sue my toaster
[13:20] Tao Takashi: poor thing
[13:20] Morgaine Dinova: Hehe
[13:21] Xugu Madison: I'm not allowed to use kitchen appliances. Not after... last time...
[13:21] Zero Linden: Well, for example, right now objects in all the existing protocols are refernced by UUID --- which is like a capability, in that knowledge of the reference is access to the object
[13:21] Zero Linden: BUT
[13:21] Mirt Tenk: wow, dyslexic programming must be difficult
[13:21] Zero Linden: if I am the owner or the creator - I have different views and actions, and in a pure capability system, I'd have a different capability to the object
[13:21] Zero Linden: here, in SL, I don't
[13:21] Graph Weymann: Yes, why not?
[13:22] Graph Weymann: Surely having two IDs instead of one is not too bad?
[13:22] Zero Linden: because a) the current system isn't archtected that way
[13:22] Jonit Ivory: UUIDs should be universal and applicable to teh domain they are taken to, by a trusted mechanism?
[13:22] Zero Linden: b) that implies that a mapping on some side must be kept
[13:22] Tao Takashi: I wonder if at some point the proxy might become a bottleneck
[13:22] Tao Takashi: isn't it a SPOF now already anyway?
[13:22] Graph Weymann: Zero, sure, the object's host knows both ids for that object...?
[13:23] Morgaine Dinova: The problem there is that OO people can't cope with the idea of two different references to the same object, for different rights. Their problem though
[13:23] Morgaine Dinova: Ie. it's not in the OO model
[13:23] Zero Linden: Graph- probably - one would need to generate the secondary UUIDs on use - and then reap them....
[13:23] Tao Takashi: I can cope with adapters so I can also cope with that :)
[13:23] Zero Linden: there are a surprizing number of facets for an object
[13:23] Zero Linden: in a system as rich as SL
[13:23] Graph Weymann: Zero, I was suggesting that you could get away with static exactly two...but I've hardly thought about it much.
[13:23] Zero Linden: group access, owner access, creator access, etc...
[13:24] Graph Weymann: You do know that a UUID won't do for a capability, that you need to pair it with a host public key or similar, right?
[13:24] Graph Weymann: (so that nothing else can claim to be that object, etc.)
[13:24] Zero Linden: Graph- in SL - capabilities are URLs
[13:24] Graph Weymann: yes, but do your URLs have Tyler CLose's y-property?
[13:24] Xugu Madison: Which include a key that I presume is secure somehow
[13:25] Graph Weymann: If not, you have spoofing problems
[13:25] Graph Weymann: and/or information leak
[13:25] Zero Linden: I'm not sure I follow ---- https:// should suffice, no?
[13:25] Graph Weymann: no
[13:25] Zero Linden: why?
[13:25] Zero Linden: nor do I see how there is information leak...
[13:25] Morgaine Dinova: Graph: not true. For identical UUID and key space sizes and equivalent sparseness and randomness properties, the two have equivalent security.
[13:25] Graph Weymann: Zero, oh, I suppose https sufficies if you trust the CA roots
[13:26] Graph Weymann: Morgaine, that's not the issue
[13:26] Zero Linden: Graph - I trust the CA roots
[13:26] Mirt Tenk: CA=?
[13:26] Jonit Ivory: https is fine, the root CA would be LL?
[13:26] Mirt Tenk: cap author?
[13:26] Graph Weymann: Morgaine, if you have a UUID-cap then if you send it to the wrong server you lose it
[13:26] Zero Linden: CA = certificate authority - and it is the basis of trust in SSL/TLS ---
[13:26] Jonit Ivory: Certificate authority
[13:26] Graph Weymann: so you have to send it to the right server
[13:26] Mirt Tenk: right, ty
[13:26] Zero Linden: when you go to Amazon and purchase something and check the "lock" icon in your browser
[13:26] Morgaine Dinova: Graph: it is the issue. It's about the probability of guessing a UUID or guessing an encryption key. Directly equivalent
[13:26] Graph Weymann: Zero, this is a separable issue (can be fixed later), but you can avoid needing to do that
[13:27] Graph Weymann: Zero, look up Tyler's httpsy
[13:27] Zero Linden: you are trusting that the well known CAs that your browser trust, vouched for that server really being Amazon.com
[13:27] Tao Takashi: you can also do other ways of spoofing an IP etc.
[13:27] Graph Weymann: Morgaine, yes, but different problem;
[13:27] Jonit Ivory: I floated the idea of a separate Inventory Domain last time I was here, Zero your thoughts?
[13:27] Graph Weymann: Morgaine; a host public key is public, so it isn't a valuable secret
[13:28] Zero Linden: Graph --- there would be nothing stopping any domain in OGP from using httpsy: as a capability URL if it desired....
[13:28] Graph Weymann: Morgaine: so you use the key to establish a connection to the right server, then send the sparse-cap to it
[13:28] Zero Linden: ....except that almost no standard libraries would handle it
[13:28] Graph Weymann: Zero:right, so never mind - that can be fixed later
[13:29] Zero Linden: ultimately, the OGP construction of capabilities, factors out level of trust here to a choice between cooperating parties
[13:29] Zero Linden: for most, https: is sufficient trust
[13:29] Graph Weymann: I wince every time people say 'trust'
[13:29] Zero Linden: and in some case, http: is good because you don't even want to keep the cap private
[13:30] Zero Linden: we have the concept of "well known caps" that *should* be distributed widely
[13:30] Morgaine Dinova: Graph: that's not significantly different. After all, you're using the PKI to determine endpoints for a session key, and the session key has a keyspace, so it's the same situation as with the address space of a UUID.
[13:30] Georgette Whitfield: Exactly what I was going to say Morgaine!
[13:30] Georgette Whitfield: coughs
[13:30] Graph Weymann: Morgaine, I'm not talking about guessability, but whether it is leaked
[13:31] Graph Weymann: Morgaine, if you have just a UUID which is a cap, then you have no way of knowing what server to send it to
[13:31] Xugu Madison: Zero, do CAPS URLs expire at all?
[13:31] Graph Weymann: and if you send it to the wrong server, it now has got the cap
[13:31] Zero Linden: They can expire at the option of the issuer
[13:31] Zero Linden: in the current system, most of your caps expire when the viewer leaves the region
[13:32] Graph Weymann: so you use a public key, whether gained through tthe CA system or not, to ensure that only you and hthe host of the cap ever see it
[13:32] Xugu Madison: 'cos time/session limiting them might be an idea to reduce scope for replay attacks
[13:32] Morgaine Dinova: Well in our case we WANT that leakage. For example, we've been talking about a cap acquired in one session being sent over to a mobile device, and the session continuing. So disallowing leakage between session endpoints would be a bad thing.
[13:32] Graph Weymann: Morgaine, that's not lakage, that's delegation
[13:33] Zero Linden: Xugu - if you don't want a replay attack, then the cap is issued and used only with HTTPS --- assuming you trust (don't wince Graph, it is practical) the CAs, then your caps aren't going to be leaked
[13:33] Graph Weymann: By leakage I mean a cap getting into the hands of an unrelated third party
[13:33] Mirt Tenk: unintended
[13:33] Morgaine Dinova: Define "unrelated"
[13:33] Graph Weymann: Ouch
[13:33] Xugu Madison: Zero, assuming the client system is secure. Which is a lot less of a given than would be nice...
[13:33] Zero Linden: I think Graph meant what Mirt says
[13:33] Graph Weymann: I mean, some one that didn't know it already
[13:33] Graph Weymann: the client and the true server
[13:34] Zero Linden: Xugu - I don't think we are here to solve the issues of users' computers and the software they choose to load on it being secure
[13:34] Mirt Tenk: that you didn't mean to know it
[13:34] Morgaine Dinova: Our session-free caps model has many benefits, and is just as secure in terms of address space for brute forcing.
[13:34] Xugu Madison: Zero, I suppose. As long as caps can be expired if compromised, anyway...
[13:35] Zero Linden: Simiarly, we are not here to solve the issues of total network end to end security --- again, IPsec, and or TLS and or HTTPSY and or other layers may, and should, solve those
[13:35] Zero Linden: we are here to build a system that works on top of the infrastructure as it exists, and can move with it -
[13:35] Morgaine Dinova: Client systems are never secure ... basing a design on that is as bad as the fallacy of DRM. That's why all security is vested in knowledge of a cap instead.
[13:35] Zero Linden: I'm pretty sure our caps construction, as currently designed, does that
[13:36] Zero Linden: using HTTPS: is a practical end-to-end security (however flawed central authorities might be)
[13:36] Mirt Tenk: higher ed will want session caps
[13:36] Graph Weymann: yes, as long as the whole URL constitutes a cap, you're good
[13:36] Zero Linden: further, unlike Tyler's caps that are full closures, we encode nothing in the capability itself
[13:36] Morgaine Dinova: Zero: I agree totally. Let's not reinvent the secure session wheel.
[13:36] Mirt Tenk: Xugu, think so?
[13:37] Zero Linden: Yes - Graph, that was a very early design decision that has been revisited several times
[13:37] Graph Weymann: arg, I seem to be going on at length about the things that don't need to be talked about, sorry folks :)
[13:37] Zero Linden: and each time we've come down strongly on
[13:37] Zero Linden: the cap is the whole URL -- and if the user tacks crap on to it -- we throw it away
[13:37] Xugu Madison: Mirt, session caps? Looks like we can beat the server software into doing it however we want, so we're fine
[13:37] Morgaine Dinova: Hehe Graph, it's OK, it's a chat, not a presentation. But I'd love a presentation!
[13:37] Zero Linden: so: https://sim12345.agni.lindenlab.com:12032/cap/bdfd8e2b-35e3-4b56-a493-9d42b82e65c4
[13:38] Zero Linden: is an example cap in our system
[13:38] Graph Weymann: yes, you needn't explain further
[13:38] Zero Linden: okay
[13:39] Graph Weymann: I'd rather talk about what the caps mean (actual application protocol design) rather than how they're stored, now :)
[13:39] Zero Linden: now - Tao - is it that you want the cap ID in a cookie or header ---- or that you want a session id in the cookied or header?
[13:39] Zero Linden: Graph - we use caps for EVERYTHING
[13:39] Xugu Madison: I interpreted as session ID in a cooke or header
[13:39] Tao Takashi: whatever the server decides
[13:39] Graph Weymann: sure, sure, but how you break down everything is critical
[13:39] Tao Takashi: I'd put a session id in there
[13:40] Zero Linden: but there is a constant trade off between what is passed in the arguments to the cap invocation, or issuing individual caps....
[13:40] Xugu Madison: Really, they do. Ya want coffee at LL, better have the full UUID *nods*
[13:40] Graph Weymann: Zero, what's the bottleneck in issuing individual caps, besides deciding when to discard them?
[13:40] Zero Linden: Well, Graph - considering editing an object --- there are say 100 or so parametric values (position, rotation, twist, cut, etc...)
[13:41] Zero Linden: should there be one cap: adjust_object_parameter?
[13:41] Graph Weymann: Right, of course those don't need to be, for most use cases
[13:41] Zero Linden: or one cap for each number?
[13:41] Morgaine Dinova: Always break down everything into small disjoint caps is my advice. You can always aggregate them back later into cap sets for composite functionality.
[13:41] Zero Linden: Right - well there's an example... we hit this all over the system
[13:41] Morgaine Dinova: Decouple :-)
[13:42] Zero Linden: well, it is quite a bit of traffic to ask for the rotate-z parameter for this object, then the rotate-x, etc....
[13:42] Morgaine Dinova: Optimize traffic later, not at caps design time.
[13:42] Zero Linden: we have to make a judgement call (as API designers) for where the value of individual control is minor or absent, and the complexity not worth it
[13:43] Graph Weymann: well, that sounds very good then
[13:43] Zero Linden: but again, it is pretty clear that changing the rotation of an object one axis at a time is of no serious value...
[13:43] Morgaine Dinova: Er ....
[13:43] Zero Linden: ...beyond the academic amusement of giving the three different caps to three different people and letting them cooperatively rotate the object
[13:43] Graph Weymann: hah
[13:43] Zero Linden: so - just make rotation be one cap...
[13:43] Morgaine Dinova: Not at all Zero
[13:43] Zero Linden: or really, the whole object parametric set
[13:44] Morgaine Dinova: Give the control to 3 different objects and you have a nicely decoupled design
[13:44] Graph Weymann: Zero, I heard about a flap about stealing textures by llSetTexture after looking at the client data stream...you know how that ought to be solved by facets, right? :)
[13:44] Zero Linden: Right - but at present, we don't see a need to enforce that level of control down to caps -- you could just as easily give all three objects the whole cap for object editing and tell them which parameter they are editing
[13:44] Graph Weymann: Just to pick a random example
[13:45] Zero Linden: I agreee it is less elegant -- but realy, not much use cases
[13:45] Morgaine Dinova: Graph: how?
[13:45] Graph Weymann: I assure you, I've never suggested there should be a facet for every object parameter :)
[13:45] Zero Linden: Graph - again, I'd say that we'd expect the client to get a cap to edit object foo
[13:46] Zero Linden: where again, I'd expect that all the parameters, including texture, for object foo would be under that cap... again deciding in this case for arguments to the cap invocation rather than separate caps
[13:46] Graph Weymann: Morgaine, if you have a read-facet and a use-as-object-texture facet ,then every client gets the read, but you can't set a texture without the use-facet (the region rejects it)
[13:46] Graph Weymann: So clients can't see textures and then put them on their own objects, as is the current condition
[13:46] Zero Linden: you mean, Graph, the region doesn't issue it to most viewers
[13:46] Zero Linden: surely it isn't rejecting it
[13:47] Graph Weymann: Er, why not?
[13:47] Zero Linden: you have two caps --- the cap to read the texture
[13:47] Zero Linden: and the cap to set the texture on an object
[13:47] Zero Linden: you present the cap to set the texture --- that's all you need
[13:47] Xugu Madison: I think what Zero means is that if you can't set it, you just don't have the cap at all, so there's no request to reject
[13:47] Zero Linden: if you have that cap, the simualtor just sets away
[13:47] Xugu Madison: rats, we explained simultaneously
[13:48] Zero Linden: well - we might translate what Graph said to : the region rejects the request to issue the edit-cap
[13:48] Morgaine Dinova: Graph: so that's like partial currying of function arguments, in one sense. Getting a curried function back is similar to getting a facet for an inner parameter.
[13:48] Graph Weymann: Zero, I meant the scheme to protect setting a texture *you don't own* on an object you do
[13:48] Mirt Tenk: delivery on demand
[13:48] Graph Weymann: But I may be explaining something obvious again...
[13:48] Zero Linden: Ah - well --
[13:48] Zero Linden: *that* problem
[13:49] Zero Linden: (sorry, thought you were doing a different one)
[13:49] Graph Weymann: Point is, you can solve that trivially
[13:49] Graph Weymann: by havin two facets for each texture
[13:49] Graph Weymann: one sits in your inventory and ays you can apply it, the other goes to eeryone who looks at it
[13:49] Graph Weymann: That's why I'm here, I want to see that every problem which can be solved by caps is :)
[13:50] Zero Linden: in that regard
[13:50] Morgaine Dinova: You know, REST deals quite nicely with facets, because a REST resource is not actually an object, but only a specific view into an object.
[13:50] Zero Linden: we already have that second facet: the inventory item
[13:50] Graph Weymann: can be solved by trivial applications of caps, I mean :) not to overdo anything
[13:50] Latha Serevi: Regarding Zero's "caps for everything" -- in OGP-land, we're reinventing the "everything" that LL does, to a certain degree, in the process of opening-up, generalizing, and hopefully simplifying. We'll have to write down some axioms and stuff. I wonder how we can try to be compatible with LL-caps. Can we really hope to bring LL-caps in all its complexity (and presumably proprietaryness) out into OGP land? Or should we be trying to find a framework that can hold LL-caps and our OGP-something-else ?
[13:50] Graph Weymann: Zero, true, the problem is in llSetTexture then :)
[13:51] Zero Linden: Latha - LL's current caps aren't really that complex, and the cap server code is BSD
[13:51] Jonit Ivory: ok need to go, been fascinating listening to all :)
[13:51] Morgaine Dinova: Cya Jonit
[13:51] Jonit Ivory: ciao ciao
[13:51] valentine Biddle: bye
[13:51] valentine Biddle: :)
[13:51] Mirt Tenk: take care
[13:51] Rex Cronon: bye
[13:51] Zero Linden: OGP caps, as constructed in the current draft of the spec, are the same, but spelled out in more detail ---
[13:51] Zero Linden: and they are still pretty straight forward
[13:52] Georgette Whitfield: PLease excuse me
[13:52] Georgette Whitfield: Time for Amber's hours
[13:52] Mirt Tenk: bye, take care
[13:52] Tao Takashi: cya Georgette!
[13:52] Latha Serevi: Zero - that's cool, so the underlying mechanism is open & probably usable; but what about the interaction logic? That's complex and mostly undocumented, right? What cap is needed for what operation, and where it comes from. and it won't have been generalized to non-LL actors yet, I presume.
[13:52] Rex Cronon: bye
[13:53] Georgette Whitfield: Thank you
[13:53] Zero Linden: In the case of textures, we can decide that you must present both the texture ID (same as the viewing-cap) AND the inventory ID (that you have and proves that you can use the texture) to the call
[13:53] Zero Linden: of course llSetTexture() doesn't have those parameters
[13:54] Zero Linden: but, we have not yet tackled the issues of putting caps into play in LSL
[13:54] Graph Weymann: right...
[13:54] Zero Linden: that is further down the road...
[13:54] Zero Linden: protocol first
[13:54] Xugu Madison: how's inventory coming along? :-D
[13:55] Mirt Tenk: Xugu have you been building us one? ;-)
[13:55] Zero Linden: I don't know --- the much of the OGP team is out this week between vacation, SLCC and VWLA
[13:55] Morgaine Dinova: How independent are protocol and caps definitions?
[13:55] Mirt Tenk: who will be @ SLcc?
[13:55] Xugu Madison: Mirt, it's right on my to-do list, after sleep
[13:56] Mirt Tenk: lol
[13:57] Zero Linden: The construction in the OGP spec makes for a wide variety of cap implementation strategies
[13:58] Zero Linden: The interaction logic is defined all interms of REST operations over some transport identified with a URL....
[13:58] Mirt Tenk: and hosts have options?
[13:59] Zero Linden: By having a pardigm of asking the host (via the seed-cap) for the URL to an operation, the host is free to return a cap --- which is really just an secure external form of a URL to a function
[13:59] Zero Linden: As a consequence, we can define the cap mechanism once- then define the whole protocol (all ~400 functions) in terms of REST like operations (we call them resources in OGP)
[13:59] Morgaine Dinova: So where OGP handles a cap, that cap can be any cap, without any semantic implied by knowing which specific cap it is?
[13:59] Zero Linden: and these just flow over caps, where those operations should be secured
[14:00] Zero Linden: No, - when you want to do an operation, you must ask the appropriate entity for a cap for that particular operation
[14:00] Zero Linden: (Resource class name)
[14:00] Mirt Tenk: ok makes sense
[14:01] Zero Linden: then you must keep the association yourself: To do object/foo_bar on gizmoo foo -- use this cap the region returned
[14:01] Morgaine Dinova: What does "flow over caps" mean? A cap isn't a transport
[14:01] Zero Linden: then you invoke that cap ( == make an HTTP request on the URL)
[14:01] Morgaine Dinova: Aye, the transport is at a level below
[14:02] Zero Linden: "flow over caps" menas that every operation once defined, is essentially a cap --- and follows the same pattern
[14:02] Graph Weymann: Morgaine, it's a common shorthand... the messages sent to the cap, their arguments, and responses
[14:02] Zero Linden: each function is described like this:
[14:02] Morgaine Dinova: Oh, kk, just a turn of phrase then :-)
[14:02] Graph Weymann: every cap can be seen as a communication channel
[14:02] Zero Linden: "Set Region Environmentals"
[14:02] Graph Weymann: it's just built on top of whatever (http, captp, ...)
[14:03] Zero Linden: name: region/set_envrionmentals
[14:03] Zero Linden: cap: retrieved from region seed cap
[14:03] Morgaine Dinova: Only as a theoretical dual. We're treating caps as transportable entities here, not as transports. The dual probably exists, but we;re not thinking of caps that way
[14:03] Zero Linden: request: { time_of_day: real, .... }
[14:03] Zero Linden: response: ....
[14:03] Graph Weymann: Morgaine, no, you get little caps from big caps -- that *is* an example
[14:04] Mirt Tenk: ty graph, just clarified a lot for me
[14:05] Morgaine Dinova: Caps have sizes? :-))))) You can only compare the size of scalar entities, and comparing set sizes is a stretch :-)
[14:05] Graph Weymann: Morgaine, well, a partial order, anyway
[14:05] Zero Linden: well- one can think that caps generally, only begat caps will lessor privledge
[14:05] Zero Linden: though it is admittedly a multi-dimensional space
[14:06] Morgaine Dinova: Hehe, begat
[14:06] Graph Weymann: (mumble mumble rights amplification mmble)
[14:06] Zero Linden: that simple construct, though, doesn't take into account that the system is under mutation from other points
[14:06] Zero Linden: or that these things have time value
[14:06] Mirt Tenk: system?
[14:07] Morgaine Dinova: or that rights can be revoked, or temporary. Indeed, it's a dynamic system
[14:08] Latha Serevi: Given the notions of "seed cap", rights amplification, etc, I don't understand this at all --- Zero >>> caps generally, only begat caps will lessor privledge
[14:08] Tao Takashi: it's also not that easy to understand unfortunately
[14:09] Zero Linden: Latha - actually I think this whole line of reasoning, while the calculus of cap systems --- is not the best way to understand Caps in OGP at all
[14:09] Tao Takashi: but you might say that the seed cap is the big cap which can give you caps of lesser power
[14:09] Morgaine Dinova: I think that's a dangerous semantic to hardwire in, priviledge relationships between caps.
[14:09] Zero Linden: so
[14:09] Zero Linden: here is the easy way to think of it all
[14:09] Zero Linden: drop all the caps stuff for the moment
[14:09] Zero Linden: imagine that SL is just a web site
[14:10] Morgaine Dinova: tries
[14:10] Zero Linden: once you authenticate, you get a URL to the web page for the region you are in
[14:10] Zero Linden: you look at the web page and it has all sorts of other links in there
[14:10] Zero Linden: including ones for all the parcels you own
[14:10] Tao Takashi: tried to implement an AD like a web page ;-)
[14:10] Zero Linden: you click on them an dyou get a page hwere you can edit the parcel properties
[14:10] Zero Linden: there were also links to parcels you don't own
[14:11] Zero Linden: you click on them and you get only a view of the settings, no form
[14:11] Zero Linden: now
[14:11] Zero Linden: it turns out, once you authenticated
[14:11] Zero Linden: you could take the URL in the browser address bar
[14:11] Zero Linden: and just mail it your friend
[14:11] Zero Linden: and they now have all the same access as you did
[14:11] Zero Linden: if, instead
[14:12] Graph Weymann: unfortunately, most web sites don't work like that :)
[14:12] Zero Linden: you just mailed them the URL to the form for the parcel you both manage
[14:12] Zero Linden: they'd be able to manage the parcel properties
[14:12] Zero Linden: but curiously
[14:12] Zero Linden: that parcel form page ---
[14:12] Zero Linden: had NO link back to the region page
[14:12] Zero Linden: That's right - most don't
[14:12] Graph Weymann: (because they have session cookies)
[14:12] Morgaine Dinova: Yep, that's what we want, so that we can delegate capabilities to other clients outside of our old session, which may disappear for good.
[14:13] Zero Linden: Morgain- the point of using caps is that the "dangerous" seed cap is far less dangerous than the all powerfull session cookie
[14:13] Tao Takashi: this problem is being solved with OAuth on the web (the delegation part)
[14:13] Xugu Madison: Are you doing cap requests, BTW? 'cos I'd kill for a URL-based cap for delivering an object to someone
[14:13] Graph Weymann: but it's not a problem, if you stick to cap-URLs!
[14:13] Zero Linden: OAuth is essentially a cap system.... though it leaves many of the practical details out of the spec ---
[14:14] Zero Linden: which I think will hurt it's adoption
[14:14] Tao Takashi: intentionally
[14:14] Graph Weymann: OAuth is an identity-based system, isn't it?
[14:14] Latha Serevi: I'm thinking there are two concepts I need to "get", one, URL-as-key, and two, the difference between a cap and an ID badge. I don't think I get the second fully yet.
[14:14] Tao Takashi: I am not sure, there is a discovery extension now and it seems to be widely discussed and more and more services also implement it
[14:14] Graph Weymann: Latha, you don't hand your ID badge to someone else
[14:15] Tao Takashi: basically OAuth does what flickr does
[14:15] Graph Weymann: or if you do, it conceptually is *everything you can do*; caps are finer-grained
[14:15] Zero Linden: Graph- OAuth is a system whereby a user can authorized site A to look at the user's friends list on site B
[14:15] Tao Takashi: you login to one service tell it that service B is allowed to use certain functions and after that service B can use those
[14:15] Zero Linden: essentially
[14:15] Graph Weymann: caps identify the target, badges (or whatever) identify the actor
[14:15] Zero Linden: which is a cap ...
[14:15] Graph Weymann: Zero, yes, and thus it is non-capability
[14:15] Graph Weymann: since you designate site A
[14:16] Morgaine Dinova: While ID determines whether you've been granted a cap in the first place, it's an interesting question whether IDs themselves can be handled as caps, subsequently.
[14:16] Graph Weymann: a cap system you would take the list and *give it to* site A
[14:16] Zero Linden: well - after authorization, in theory site A has a cap-like-thing to site B which shouldn't allow it more than the friends list
[14:16] Graph Weymann: oh, well that's good then :)
[14:16] Graph Weymann: I think there was some OAuth discussion on cap-talk but I didn't memorize it
[14:16] Tao Takashi: and it can revoke it if it wants to
[14:16] Morgaine Dinova: After all, we DO hand our badges to others ... and really that's for us to decide.
[14:17] Tao Takashi: basically it's like flickr works with external services
[14:17] Latha Serevi: Graph, do I need to guard my "seed cap" in the same way as a master key or an ID badge? That's what I'm still trying to get, probably by reading another caps intro rather than on-the-fly today.
[14:17] Tao Takashi: like the flickr uploadr
[14:17] Graph Weymann: Latha, absolutely
[14:17] Graph Weymann: Latha, I think the SL seed cap is time-limited - you get a new one each login
[14:17] Zero Linden: right - but I give a back door key to my friend feeding my cat while I'm on vacation -- I don't hand them a copy of my whole key chain with my safe-deposit box key on it
[14:18] Graph Weymann: the way all cap-system logins work is:
[14:18] Latha Serevi: Oh, I thought the answer was going to be "no, of course not." :-) live and learn.
[14:18] Zero Linden: Yes - the seed cap is very valuable ----
[14:18] Graph Weymann: you present a username/password, the system hands you back a "root" capability to everything-which-is-yours
[14:18] Zero Linden: but be clear that there are many seed caps
[14:18] Zero Linden: for example - one is to your account
[14:18] Zero Linden: the other is to the region you are in - as you
[14:18] Zero Linden: AND, in OGP
[14:18] Morgaine Dinova: I assume all caps will have expiry as a property, even if unused.
[14:18] Mirt Tenk: right, like, no God tools
[14:19] Zero Linden: usually none of these outlast the login session
[14:19] Tao Takashi: still would like some cookie.. I like cookies :-)
[14:19] Morgaine Dinova: Aye, no god tools, no god sessions, no root access.
[14:19] Zero Linden: mostly because people today are good at carrying around account names and passwords in their heads, and not master caps on electronic key chains
[14:19] Tao Takashi: thanks again, Mirt :)
[14:19] Zero Linden: (again, I don't think OGP is here to solve that problem, either!)
[14:19] Tao Takashi: your inventory is a wealth of good things :)
[14:19] Mirt Tenk: I try to contribute when I can :-/
[14:20] Tao Takashi: that probably wasn't good english
[14:20] Zero Linden: carries around an electronic cap to his PayPal account --- honest!
[14:20] Warm Cookie: whispers: Ahhh, Fresh from the oven. Yumm!!
[14:21] Mirt Tenk: wow, OK, you know there are people in higher ed running the SL engine off flash drives in public computer labs?
[14:21] Mirt Tenk: b/c not installed on the machines
[14:21] Tao Takashi: that sounds like a bug ,-)
[14:22] Zero Linden: right - another reason that we aren't here to solve the user-account-password problem
[14:22] Morgaine Dinova: Engine? You mean client|?
[14:22] Latha Serevi: In OGP-land, my main seed-cap is via my AD, I'd imagine. So, not only do I "get" it from my AD, but every time I "use" it, I am pinging my AD to get a sub-cap of some kind, I guess. Am I going to be doing a zillion little requests all via my AD for every operation I might want to do, to get the million little sub-caps I'll need?
[14:22] Mirt Tenk: srry, client
[14:22] Xugu Madison: Can we define IT services here as a bug? I can work with that....
[14:22] Mirt Tenk: um, I am in it services
[14:22] Zero Linden: Latha - yes and no
[14:22] Zero Linden: for example, right now, when you TP to a region (in SL, not OGP) you get a region seed cap
[14:22] Xugu Madison: Mirt, but you're not in IT services _here_ :)
[14:23] Zero Linden: and then immediatly your viewer requests about 20 smaller caps
[14:23] Tao Takashi: needs to head out unfortunately
[14:23] Mirt Tenk: so not constantly pinging?
[14:23] Zero Linden: but many of these are multiple use
[14:23] Zero Linden: like one of those caps is "upload-texture"
[14:23] Zero Linden: and you can invoke it many times
[14:23] Tao Takashi: cya all soon!
[14:23] Mirt Tenk: that's the part I'm trying to get a handle on, how much pinging back & forth?
[14:23] Rex Cronon: bye tao
[14:23] Tao Takashi: and please comment on [1] is there's something to comment on :)
[14:23] Mirt Tenk: take care tao, hope you find some cookies
[14:23] Zero Linden: and -- you request and get all those caps in one transaction
[14:23] Latha Serevi: (if it were a certificate, I could just pass it directly, but a cap always goes "via" the host it's based on, I gather)
[14:23] Zero Linden: so - in many ways
[14:23] Tao Takashi: Mirt: I might implement them myself ;-)
[14:23] Zero Linden: after getting the seed cap, you'll ask for prbably on the order of a hundred or so caps, and get them all
[14:24] Zero Linden: and be done
[14:24] Mirt Tenk: is this caps on demand or auto for all?
[14:24] Zero Linden: in some cases, there are one-shot caps --- but those are all cases where you needed to do a network transaction anyway
[14:24] Zero Linden: on demain
[14:24] Zero Linden: on demand
[14:24] Zero Linden: you must ask for the caps you want... though a domain is free to pass you additional ones it thinks you ar elikely to ask for in the future
[14:25] Zero Linden: but the idea is to allow different level of clients to ask for fewer functions
[14:25] Zero Linden: and thus "advise" the domain that it will be less load
[14:26] Latha Serevi: Regarding the domain interactions, if I want to edit an object I own, in a region I'm in, I wonder what the path is? I ask my AD for a cap; does RD need to interact with AD before it lets me modify the object?
[14:26] Morgaine Dinova: Latha: the cap to a zone element would access the zone server, not the AD, so the "parent" cap doesn't turn into a cascade of accesses from "child" caps.
[14:26] Rex Cronon: bye everybody
[14:27] Morgaine Dinova: Cya Rex
[14:27] Rex Cronon: tc
[14:27] Zero Linden: Latha - you have a seed cap to the region you are in - you ask it for a cap to edit the object
[14:27] Zero Linden: well all
[14:27] Zero Linden: I'm wayyyyy over my time
[14:27] Zero Linden: this has been good
[14:27] Xugu Madison: Seeya Zero, take care, thanks for the bear!
[14:27] Zero Linden: thanks for coming all
[14:27] Morgaine Dinova: Hehe, cya Zero
[14:27] Zero Linden: see ya later
[14:27] Graph Weymann: Zero...
[14:27] Graph Weymann: Zero, I hope I wasn't too much of a pest :)
[14:27] Latha Serevi: (zero's gone) - you were great, Graph, thanks
[14:28] Morgaine Dinova: I'd like to hear or read a presentation on cap design patterns, Graph.
[14:28] Graph Weymann: Please let me know any time you have a capability design problem :)
[14:28] Mirt Tenk: ty graph
[14:28] Graph Weymann: Morgaine, I'm rather bad at summarizing, sorry...
[14:29] Morgaine Dinova: Hehe, it's OK, I don't have ADD ^_^
[14:29] Latha Serevi: What's the most recent OGP spec's URL?
[14:30] Graph Weymann: Morgaine, for something I already wrote see [2]
[14:30] Morgaine Dinova: Is there a document on cap design patts on erights?
[14:30] Morgaine Dinova: Looking, Graph
[14:31] Graph Weymann: No, but there should be
[14:31] Graph Weymann: They should all be written up and taxonomized and hypertextified on [3]
[14:31] Latha Serevi: Is the most recent OGP spec [4] ... with a version 3 coming up soon? Or is it out already?
[14:32] Graph Weymann: another useful place is [5]
[14:33] Graph Weymann: anyway, I'm off now to Asim Zahra, I'll be online for another half-hour
[14:33] Mirt Tenk: take care, ty
[14:33] Xugu Madison: I'm off to beat Oracle around the head
[14:33] Mirt Tenk: thanks all, take care. Xugu, I'll catch you tomorrow

User:Zero Linden/Office Hours/2008 September 02

Navigation menu

Search