[9:38] Rex Cronon: i checked like 20 minutes before
[9:40] Latha Serevi: There were a couple of group IM's to the effect that Zha's on vaca, and some jokes about her having kidnapped Sai.
[9:40] Latha Serevi: If we can get a quorum, my favorite/only topic revolves around groups. Dale Innis and I always agree on problems and disagree wildly on solutions. I hope we can touch upon this email comment from Dale at today's 9:30 Groupies: "So far we haven't been talking much about the non-IM aspects of groups. I'm sure that interesting new considerations will appear when we do."
[9:40] Saijanai: Kuhn: well, that would be intersting sense I've been here every day
[9:41] Tao Takashi: well, I might be a little quiet today as I have stuff to do
[9:41] Kopilo Hallard: it could be some psychotic pizza loving geek!
[9:43] Kopilo Hallard: waves hello to the familiar faces
[9:43] Saijanai: Kuhn: Tao, correct me if I'm wrong, but there's no permanent object associated with avatar data in pyogp, right? no place to store name/password, etc?
[9:44] Tao Takashi: no, that's part of what the app needs to do
[9:45] Tao Takashi: well, the passwordcredential is an object which holds this data
[9:48] Saijanai: Kuhn: not familiar enough with any system to coment. Just recall that Zero and Zha both say that normal IRC may have problems with SL behavior for group IM
[9:48] Bartholomew Kleiber: I am totally +1 with what Dahlia wrote today in the mailing list.
[9:48] Gareth Ellison: normal IRC would have small issues
[9:48] Gareth Ellison: but an IRC-like protocol would work great
[9:48] Tao Takashi: my main thing is not so much about IRC yes/no but mostly about enabling as many possible systems as possible
[9:49] Kopilo Hallard: it would have to support multicast right?
[9:49] Tao Takashi: then people will figure out the best way to implement it
[9:49] Gareth Ellison: i dislike the idea of multiple possible systems - since we burden client/server devs (both of them) with having to implement them all OR risk being incompatible
[9:49] Gareth Ellison: we should standardise on one protocol
[9:49] Tao Takashi: which means the less an AD has to provide the better.. because it would be great if you don't need to run an AD in order to play around with your IM implementation
[9:49] Tao Takashi: there can be one standard way of doing it we propose
[9:50] Latha Serevi: I duno if we have much of a quorum for "what are groups and how to manage them" discussion. My own interest is in the non-IM side. BTW, I think there should be two different kinds of groups, totally-insecure and totally-secure
[9:50] Saijanai: Kuhn: well, if the AD doesn't handle authentication for EVERYTHING, then you run the risk of having multiple authentication systems for the same avatar
[9:50] Tao Takashi: can be bound together by OAuth
[9:51] Tao Takashi: or other techniques but that's a standardized one and gaining momentum
[9:51] Rex Cronon: there is no such thing "totally-secure"
[9:51] Latha Serevi: "secure enough to handle land management", then
[9:51] Tao Takashi: I guess we mean "as-secure-as-we-can-get" ;-)
[9:51] Saijanai: Kuhn: yeah, but you can have models that inherently are less easy to secure
[9:51] Gareth Ellison: i think we need to take a leaf from HTTP's book
[9:51] Gareth Ellison: and allow some equivalent of the Upgrade: header
[9:52] Gareth Ellison: i.e make it forward compatible, but for the sole purposes of future protocol enhancements
[9:52] Gareth Ellison: and promote only 1 official group IM protocol
[9:52] Gareth Ellison: in the standard OGP spec, we should have that 1
[9:52] Tao Takashi: it still would be nice though to reuse existing services even if they are not as-secure-as-we-can-get
[9:53] Saijanai: Kuhn: well, seems to me that there might be one "official" protocol, but that the OGP needs to allow queries to establish multiple lines of communication via the AD
[9:54] Latha Serevi: There are issues of authentication in OGP; don't we want to have some kind of cross-grid-chat that does NOT depend on ironclad authentication?
[9:54] Latha Serevi: lowest common denominator vs best-we've got
[9:54] Gareth Ellison: latha - why do we want to make authentication un-important?
[9:57] Latha Serevi: So y'all are saying, "chat bridge" style IM is looser and to-be-defined-by-somebody-else-later, and you're more interested in the "real internal OGP group IM" ?
[10:00] Latha Serevi: I'm interested in, and concerned about, how we do authentication in OGP. Can we at least modularize it, so we don't have to go back and re-do group IM when we realize how we wanted to do authentication in the first place?
[10:01] Saijanai: Kuhn: well, the current scheme is just the name/password login. OTher authentication thigns wil happen between the AD and some other service. The AD acts as the proxy for the Agent, sothe agent need not login to the other service
[10:01] Tao Takashi: firday is a holiday which is when I will try to write something down about all this :)
[10:02] Tao Takashi: right now I am more in post-vacation workload
[10:02] Latha Serevi: Anybody have opinions on Shibboleth? [2]
[10:03] Latha Serevi: Seems to be somewhat like OAuth, but a bit more general. "The operation of the Shibboleth System is based on, and conforms to, the Security Assertion Markup Language (SAML) standard (version 1.1), published by OASIS [(http://www.oasis-open.org/)"] ...
[10:04] Teravus Ousley: I dunno.. Shibboleth.. OpenID.. LiveID.. all disparate standards..
[10:07] Tao Takashi: and OAuth is also not about authentication but authorization. It's main purpose is to give access to certain services without the need to give out your password
[10:08] Kopilo Hallard: that sounds like what is needed for IMs
[10:08] Tao Takashi: also more and more services use it, like Google or MySpace
[10:09] Latha Serevi: Well, their main use-case is an individual human at a web-browser trying to give permission for a photo-sharing site to give a photo to a photo-printing site.
[10:17] Gwen Hermit: "this isn't something you treat like a frig" < prok quote
[10:17] Latha Serevi: So, "clarity of purpose" is something that we'll want to try to facilitate, social engineering wise. The posting of transcripts is publicly announced; good transparency for us.
[10:18] Kopilo Hallard: so: anyone against the ultra-insecure, ultra-secure system?
[10:18] Gwen Hermit: btw, about IRC being ultra-insecure - who actually bothers themselves on IRC with the security issues? sensitive matters get taken to an SSL-only server or get taken somewhere else
[10:18] Rex Cronon: i am against the "ultra-insecure" system:)
[10:20] Saijanai: Kuhn: well, they are conflated right now. If we develop a secure IM system, it should probably be useable (or the model if tnot the protocol) for what gorup IM is already being used for
[10:20] Tess Linden: IM's won't be used to send money and inventory going forward
[10:20] Tao Takashi: there also might be OGP-enabled IM services which still allow "normal" participants in, then also it should be made clear who is authenticated by an AD (and which probably) and who isn't
[10:21] Latha Serevi: I wonder if there's a way to define a general enough group IM protocol that there can be two instantiations of it. In the less secure, the "are you a member of the group" doesn't involve crypto authentication, but just asking a service.
[10:23] Saijanai: Kuhn: seems there would be three levels: not-secure, AD secure, and via encrypted CAP that the AD can't use
[10:24] Tess Linden: I'm confused, whats the CAP that the AD can't use ?
[10:24] Saijanai: Kuhn: Was a use case Zero mentioned
[10:25] Latha Serevi: The third may be a separate "encrypted content" capability, and there are really only two IM levels plus two kinds of content
[10:25] Saijanai: Kuhn: If your company wants to establish a line of communcation with your avatar, it can send an enncrypted cap via the AD that YOUR client alreadyknows how to unencrypt
[10:27] Saijanai: Kuhn: The cap is encrypted at the company end, sent via normal AD channels to the client, which decrypts and establishes a separate IM channel outside AD knowledge
[10:28] Saijanai: Kuhn: can't do a man int he middle attack on a url that is encrypted
[10:28] Saijanai: Kuhn: for times when the AD isn't trustworthy enough
[10:30] Tess Linden: so this is for the use case of your wanting a secure IM channel outside of the AD through another network that you trust differently from your AD?
[10:30] Saijanai: Kuhn: the encrypted cap isn't a pipe that the AD knows about
[10:30] Latha Serevi: Or rather, there aren't three "kinds", but 2x2 options of (insecure who-to, secure who-to) x (unencrypted content, encrypted content)
[10:31] Saijanai: Kuhn: Tess, righty. someone in your company wants secure chat via teh virtual worlds system
[10:32] Tess Linden: Sai: but your AD is not part of the company
[10:33] Latha Serevi: So those things sent via the AD must not be crackable by it, in order to be company-secure. e.g. an encrypted cap.
[10:33] Tao Takashi: wouldn't it be easier to open a direct connection to some secure IM service?
[10:34] Kopilo Hallard: not only that but it might be more secure
[10:34] Saijanai: Kuhn: Tao, sure, but maybe the virtual worlds thing is important for some reason
[10:34] Latha Serevi: Easier, except for giving up the AD's help in discovering group membership?
[10:34] Saijanai: Kuhn: Tess, yes, but if the CAP is sent encrypted, the AD can't use it
[10:35] Tao Takashi: well, when you are inside an IM you are inside a window anyway.. maybe in the very secure case I would even want to not involve the AD on purpose
[10:36] Rex Cronon: or u could do it in public chat, and nobody would understand a thing:)
[10:36] Kopilo Hallard: btw when you say group chat do you mean conferences as well?
[10:36] Latha Serevi: There seems to be a capabilities equivalent to a "secure encrypted envelope", that allows a cap to be passed via insecure channel but not be useable by any man-in-the-middle. I think that's what Sai is referring to. Could presumably be used for private messages, as well as non-stealable caps.
[10:38] Saijanai: Kuhn: Latha from whatsisname's thesis right? That's where I got the idea, but no need for anythng more elaborate than standard public/private key encyrption for this scenario
[10:38] Teravus Ousley: I dunno.. SSL ultimately results in the same 'stuff' that you get over HTTP.. it's just got two added features.. 1. Can't be decrypted by someone listening Except by through a proxy or something like that . 2. You can verify that the person with the public key is who they say they are.. because we've previously established trust..
[10:38] Teravus Ousley: so.. Caps over HTTPS = secure mode
[10:39] Saijanai: Kuhn: except if you don't sufficiently trust the AD to know about hour billion dollar corporate secret
[10:39] Rex Cronon: my net connection went down 4 like 2 minutes:(
[10:40] Teravus Ousley: Well, that's a item of trust.. that you'd have to establish beforehand.. or.. if they don't want to bother.. they could turn off certificate authority chain validation
[10:41] Teravus Ousley: Anyway.. that seems to give service providers enough control and options..
[10:45] Latha Serevi: Anybody know who might end up defining the IM protocol? Is all this OGP stuff being chatted-about by us, and then done by Lindens under their control?
[10:45] Kopilo Hallard: to be honest I think conferences and ims should be encrypted because generally people use IM and conferences for private conversations
[10:46] Kopilo Hallard: where as group im is more general and like local chat
[10:46] Tao Takashi: I guess Lindens will implement their caps based IM service in order to stay backwards compatible
[10:46] Teravus Ousley: Latha.. write up a spec.. I think .. would be the best way to submit your idea.
[10:46] Tess Linden: hey c'mon Latha. We're talking about this very openly, and nobodys controlling anything.
[10:46] Tess Linden: why would LL implement something that people don't want?
[10:47] Latha Serevi: Tess - the Lindens are being great about doing OGP openly, but if I ever disagree with the approach, I'm gonna lose the argument by definition.
[10:47] Tess Linden: thats not true. If you make a good argument and it's the right thing to do then it would be stupid of us to implement it the wrong way.
[10:47] Latha Serevi: So, I'm mentioning it now and then, to see if we Groupies and other non-LL open gridders might need to establish a separate pole of influence.
[10:48] Latha Serevi: Tess: it's obvious that all decisions will be made by LL in the end, if the work is being done by Lindens on a linden site.
[10:48] Tao Takashi: the question is the difference between the spec and the implementation.. and on LLs side there might also be business implications like the amount of work to rewrite the whole IM system without any clue if the new one will be scalable as needed
[10:48] Latha Serevi: I'm not saying this is because the lindens are being mean; but rather that the rest of us aren't doing our job to stay a little independent.
[10:49] Tess Linden: but Linden chose to work on this stuff openly, we're at the AWG that Linden started a year ago
[10:49] Tao Takashi: which is again a reason why I propose an open architecture.. then LL can implement their "proven" system and others can experiment with their ideas and in the end we will see what will work best
[10:49] Latha Serevi: Right - Linden is "choosing" to listen to Groupies. But, if we started defining an OGP-ish protocol over at Opensimulator and gained enough momentum that LL had to join _us_, then LL lawyers wouldn't rule the grid.
[10:50] Saijanai: Kuhn: well, its why I'd like to see the current system proted to the AD as-is. SO we can see how the current systembehaves and have a workign model to work from
[10:50] Latha Serevi: I'm just mentioning this periodically so we realize that we're under LL auspices and "helping" with something we don't "control"
[10:50] Kopilo Hallard: *tries to hide the grave digger shovels*
[10:51] Teravus Ousley: isn't really interested in 'competition' personally... would rather work together
[10:51] Tao Takashi: the main problem is I guess that there is no real process which defines how the spec is defined and who decides what in the end.
[10:51] Latha Serevi: There is a process, Tao. The Lindens currently assigned to OGP decide.
[10:51] Tao Takashi: I am also for working together but keeping the possibility to plug something new in cannot be bad ;-)
[10:52] Rex Cronon: if u can the approval of Mr M, u can consider it done:)
[10:52] Saijanai: Kuhn: so far, I haven't seen any problems with how the OGP is progressing. Ther's a storng incentive to make OGP SL-compatible, OS-compatible AND generic enough to be used by other VW's
[10:54] Latha Serevi: Right - and I hope to continue all this - but establish a little bit of an OpenSim "moral center" also.
[10:54] Tao Takashi: Here is the process for OPenSocial btw: [3]
[10:54] Latha Serevi: Hence the occasional reminder that we are forgetting to stay independent because we love LL so much.
[10:55] Latha Serevi: What is OpenSocial anyway? Never heard of it.
[10:55] Teravus Ousley: OpenSimulator uses the 'OpenSocial' process internally
[10:55] Tao Takashi: It was started by Google and is a general way to implement Facebook like apps
[10:55] Tao Takashi: but in the meanwhile it's a standalone foundation
[10:56] Tao Takashi: aren't thos apps the most deployed ones on Facebook?
[10:56] Tao Takashi: so myspace uses it in conjunction with OAuth to make their data available to third party sites
[10:57] Tao Takashi: as it also defines a REST interface
[10:58] Tao Takashi: and I was a while in their spec discussion group and it seemed quite a good process at least from glancing over it
[10:58] Tao Takashi: but they also have a dedicated group of people at Google managing it I think
[10:59] Teravus Ousley: Well.. I don't think there's an issue with the process for most things.... Though.. based on the way the SL Community has reacted to some topics.. I'm not entirely sure using that process for everything would be super productive.
[10:59] Latha Serevi: Thanks for the info on OpenSocial, Tao. Should we all be paying attention to that, and drafting off them in some ways, I wonder?