[9:38] Zha Ewry: well, that dre-rez with no detsinatoin is a logout
[9:38] Tao Takashi: Periapse: so do you know what the correct client is? :)
[9:38] Saijanai Kuhn: hmmm. what happens if you're TPing from one sim to the next in the same region?
[9:38] Latha Serevi: I have a question; what source-available client code exists? Complete list please, with specific mention of the LL client even if it's not generally available, and what client code Zha and Tao are using for their tests.
[9:39] Tao Takashi: and a test script of mine which I haven't released yet as it's more an experiment
[9:39] Zha Ewry: I've been using custom builts ones, with mods to match the strawman (which I think Linden in plannong on releasing (the client) shortly
[9:40] Tao Takashi: but regarding de-rez, what else would a region need to know except "avatar is leaving"?
[9:45] Zha Ewry: So.. let me steal the floor for a moment, before we dive back into the proof of region memebership, etc.
[9:46] Zha Ewry: One clear thing, that's come out of listenign to the OpenSim, (and some of our internal teams) is that we're not going ot have seamless, single signon worlds, probably ever, certainly not in the near futrue
[9:47] Zha Ewry: Which means, that.. for example..
[9:47] Zha Ewry: One might well, want to be able to, as easily as possible, log on to one grid, work for a while, and then teleport, both across the grid boundary, and the auth boundary
[9:48] Zha Ewry: (Say, for example, I had a grid which was using our internal LDAP for authentication) Not pretty, not seamless (which I admire as a goal) but.. I need to be be able to add the auth token, at the point
[9:49] Zha Ewry: watches the sim sit in stunned silence
[9:51] Zha Ewry: This is in deep tension with Zero's desire to say "Once you're logged in, you're logged in"
[9:52] Tao Takashi: well, this is also similar to what I'd think an ideal social network landscape would look like ;-)
[9:52] Latha Serevi: Whether totally auto or semi-auto or manual, there will be multiple auth tokens managed by somebody. I could see either the client or the AD holding the necessary tokens possibly; Zha, do you have a strong opinion on which?
[9:52] Zha Ewry: Tao, I agree in theory (having had to give plurk my yahoo, gmail, twitter, facebook, and feriendester crednetials last week)
[9:53] Tao Takashi: Zha: That's what OAuth was designed for
[9:53] Goldie Katsu: Some regions will be willing to share trust on authorization but yes there will be places where re-logging in again will be necessary.
[9:54] Carlos Roundel: interacting with internal ldap servers
[9:54] Tao Takashi: Carlos: I heard about shibboleth at the IdentityCamp and wasn't the problem with that that it's very much hierarchical?
[9:54] Rociorizo Magic: This approach is Multilevel Security
[9:54] Tao Takashi: that at least was one of the problems the guy who talked about it mentioned, as it's not really scalable
[9:54] Goldie Katsu: Or something that creates effective single sign on
[9:54] Tao Takashi: but I don't really know anything about it
[9:55] Tao Takashi: so, back to the scenario: AD internal has authenticated me by whatever method. Now it needs to tell some other RD that I am indeed this guy
[9:55] Zha Ewry: So.. the rough use case, I'm advocating, is recognition that we're stuck with multiple authentication tokens (and possibel challanges for them) in the foreseable future
[9:56] Latha Serevi: (my question again) Do we prefer client-holds-tokens, AD-hold-tokens, or agnostic? What's the URL I should be refering to to the current strawman protocol, anyway?
[10:00] Latha Serevi: Zha, yes, you're agnostic as usual. But, as usual, I"d like to define one or two common cases. say, "very careful user with every request coming to client" and "relatively lax user with every request being handled by AD after initial auth of user to AD".
[10:01] Zha Ewry: Well.. The overall patern, I think, is that we need tokens early, to get our first caps
[10:01] Tao Takashi: I think having a detailed use case might help where one can see what information is actually used and what services
[10:01] Zha Ewry: (and those, being TLS, and short term) are considered secure
[10:01] Latha Serevi: We also forgot to open this discussion with the one or two URL's that we use as a starting point. Anybody have any to belatedly specify? :-)
[10:01] Kopilo Hallard: I imagine users to actually use the function to 'backup' or 'store' inventory on multiple sources
[10:01] Tao Takashi: Sai: unfortunately reading chatlogs otoh is not very productive which is why I would like to more some of this more to some mailing list
[10:01] Zha Ewry: But.. we will have cases,w here we need to add new authnetciation tokens on TP
[10:02] Goldie Katsu: This sort of falls into the trust model and how you determine trust.
[10:02] Tao Takashi: I am a bit lost on which problem we are trying to solve here ;-)
[10:02] Zha Ewry: Well, I'm sweating two, related problems
[10:03] Latha Serevi: (re chat logs, I like the "chat logs as is, but move basic material to wiki pages" approach. I volunteer to do some of that as I'm able.)
[10:03] Zha Ewry: One is.. gettign users logged into one or more Agent domains
[10:03] Goldie Katsu: What agent domain does the region domain trust to auth the user, and is that user authenticated to that agent domain or a OAuth related one.
[10:03] Tao Takashi: what does being logged into more than one agent domain mean?
[10:03] Tao Takashi: a client can have access to information stored on both?
[10:03] Goldie Katsu: and then if the region domain does not trust the agent domain the user is coming from - how does it inform the client that "this agent domain doesn't work - log into one of these"
[10:03] Zha Ewry: and.. there is hiding behind that, the whole how do regions manage membership and proof ot the same
[10:03] Tao Takashi: some AD can contact the other and call services?
[10:05] Tao Takashi: ok, the DataPortability group would do the same probably as we are for free flow of data and users
[10:05] Tao Takashi: but anyway, I login to AD1 but might want to call services on AD2
[10:05] Tao Takashi: it of course depends on which services will really be bound to an agent domain. Like groups or IM could maybe be a separate component
[10:05] Tao Takashi: but it's probably the same problem: How do you use their services
[10:06] Zha Ewry: Maybe, but assume, I have to cope with being able to hop between disjoint, not sharing authentcatoin parts of the world
[10:07] Tao Takashi: ok, so IM service X might not have my account data on hold and can check if I am the real guy
[10:07] Tao Takashi: but I guess I once need to prove to that service/AD that I am person X which then can be remembered by some token
[10:07] Latha Serevi: I don't really see the tension, Zha. Isn't it always possible to put a proxy between the user and irritating and nontranparent auth requests that come up, m aking them invisible? So then it's not so much a tension, as just making sure we allow for helpful auth-proxies.
[10:08] Zha Ewry: Not, I think at the protocol level
[10:08] Zha Ewry: I think the client is going to get sucked into it in some cases
[10:09] Latha Serevi: (the client can be the proxy but not bug the user; although I don't see the requirement for the request to make it back to the client either)
[10:10] Tao Takashi: and this sounds like what OAuth is doing
[10:11] Tao Takashi: I login to AD 2, this asks me if it's ok to let AD 1 access service 1,2,3,4 and then they exchange some token
[10:11] Latha Serevi: Certainly auth requests need to be forwarded to the some entity capable of auth-ing, as part of the protocol. Seems that that entity could be pretty much any service or client. Makes me wonder if services _and_ clients shouldn't have URL-like identifiers so we can just name them.
[10:12] Tao Takashi: with client you mean the calling service I assume, not the OGP viewer
[10:13] Tao Takashi: in fact if today's social network morph tomorrow into some OGP capable social networks then using OAuth would mean a big win as it seems to spread
[10:13] Zha Ewry: Oh, pretty much everything shoudl end up being a REST service with aURL I tink
[10:14] Tess Linden: one of the reasons why Zero insists on having the agent domain separate from the region domain is because he envisions you holding your Identity in one place, separate from "which region" you're visiting
[10:14] Zha Ewry: The client, kn particular, is just, in my mind, a bundle of services, which happen to be hard to ivoke
[10:14] Whump Linden: Zha, can I ask a clarifying question?
[10:14] Tess Linden: but if you have your identity on two agent domains at the same time, wouldn't you have multiple personality disorder?
[10:14] Saijanai Kuhn: for anyone who came in late, I have a transcript up until now
[10:14] Tao Takashi: some comment from EuroPython after showing capabilities: "So you decided to use REST which's aim is to make HTTP sane and then you obfuscate these resource uris again?!?" :)
[10:14] Zha Ewry: Well, I do, already, Tess, is the problem. I have Identities, I can't federate
[10:15] Tao Takashi: whump: can you eventually invite me again to gridnauts? I now should have a group slot for it.
[10:15] Whump Linden: Zha, okay, I think that answered the question I was going to ask.
[10:15] Latha Serevi: Tess, yes, we need to manage the multiple personality disorder; but if you think of "identity" as "list of services needed, including multiple kinds of auth", then maybe those services won't all live on the same host; all you need is a single place to find the list of mappings of needed-service to service-provider, right?
[10:15] Zha Ewry: The repsonde to that,Tao, I think, is that we like the REST properties, which have to do with access patterns, and want to make them securable
[10:16] Zha Ewry: I don't like that, in some contexts, I have to have MPD, but I have to live with it ;-(
[10:16] Freemason Magic: I Would like to invite you to the group Software Assurance in Second Life
[10:17] Latha Serevi: Perhaps this is a good time to spend a minute on group-membership fu. What's "software assurance"? Which gridnauts groups are there (I'm not in anything other than groupies right now)?
[10:17] Tess Linden: Latha: cant you push those needed services to the region domain so your identity can be managed in one chunk?
[10:17] Freemason Magic: Software Assurance is a group of 200 programmers
[10:17] Tao Takashi: well, I don't see the security argument with caps really, it should be pretty much ok with headers, too. like the rest of the web does it. I really see caps more or less used because of the existing infrastructure at LL
[10:17] Saijanai Kuhn: gridnaut = group testing SL Opensim TPing
[10:17] Saijanai Kuhn: not sure what the other one is
[10:17] Zha Ewry: not always, Latah, because, I may have several sets of non conflatable Identities
[10:18] Tess Linden: Tao: didn't this conversation happen before?
[10:18] Zha Ewry: Did I really say "nonconflatable?"
[10:18] Victor Hua: Now not entirely knowing what is going on .. if this is out of context you can let it pass, but you could always have a default response, I don't know this user, therefore this set of services is safe to provide, but this set is not.
[10:18] Tao Takashi: Tess: sure :) and you still did not convince me ;-)
[10:18] Saijanai Kuhn: looks at the sky and whistles
[10:18] Freemason Magic: trying to develop a methodology to make SL
[10:19] Latha Serevi: Zha: good point, we'll probably need both "ways of supporting a flexible distributed single identity" and "ways of associating incompatible/different identities"
[10:20] Latha Serevi: Has anybody heard of Freemason's group other than Freemason? Sounds vaguely reasonable, but maybe that group will raise more roadblocks than they'll help overcome?
[10:20] Zha Ewry: But. if you want "secure" REST you need to do some thigns to protect the endpoints, at lowe cost, which leads to the obfuscsated URLs.
[10:21] Zha Ewry: It breaks the REST like cachability in some spots, but hopefully not in places which cost you too much
[10:21] Tao Takashi: see, I don't see a difference here in moving this UUID to some header
[10:23] Tao Takashi: and you have an additional roundtrip for retrieving it and you need to have some central management server which knows all the URLs and permissions of the other services
[10:23] Tao Takashi: but anyway, we don't need to discuss it as I doubt we will choose not to use them in this context. I will shut up now :)
[10:28] Freemason Magic: TRUST without creating confidence is nothing
[10:28] Goldie Katsu: confidence? What do you mean by confidence?
[10:28] Latha Serevi: Freemason, I think you are talking too much and not tuning in to what else is going on. Please be patient. At the moment I don't know whether to believe anything you say is worth listening to.
[10:28] Freemason Magic: you are wasting your time with technical discussions
[10:28] Lolcat Adamczyk: Freemanson, can you write trust less noisy?
[10:28] Zha Ewry: Freemason, unless you're able to talk about this in the context of web services, I can't see how it apples to the archietcture work we're tyring to accomplish here
[10:33] Zha Ewry: Freemason, this is the time for you to be quiet, and listen, and possible take a good read through the wiki and the transcripts of existign discussions
[10:36] Zha Ewry: So.. I'm assuming that we're going to end up needing a pretty simple path, to manage memebership, in a domain, and a good way of not havign to broadcast changes in membership
[10:36] Zha Ewry: So.. somethign along the lines of "Here's the domain I claim I'm in." and here's how you validate me
[10:37] Latha Serevi: OK, group membership, think think. Everything needs to be based on a decent authentication, I would imagine, so I guess a group needs to be an identity with a public key? The validation would be similar to that of a user. The interesting stuff is, how to manage the pre-validation passing around of membership lists for myself, the group, etc. ??
[10:37] Tao Takashi: you mean being a member of which agent domain?
[10:37] Zha Ewry: In this case, I'm worried abotu a service (say a region server)
[10:37] Saijanai Kuhn: or do you mean group sa in group IM in SL group?
[10:38] Goldie Katsu: Are groups something that would fall into a utility function?
[10:38] Zha Ewry: so, when someone says "Here is a LM: [4] zhas.sim.org/foo/123/123/11"
[10:38] Tao Takashi: here is something the openid guys have written about some group protocol: [5]
[10:38] Latha Serevi: (I'm referring to "groups" as general "sets of identities" which could be SL groups, or other sets of shared capabilities. They seem to ahve similar properties.)
[10:38] Zha Ewry: How do I figure out which region domain, the sim, is in, and how can I trust that
[10:38] Zha Ewry: (and note, the exact same probelm happens when I have an asset server, in a domain)
[10:39] Tao Takashi: this was also discussed in one of the groups around the web data portability idea.. this is maybe also something which should be discussed with the web scene as there are groups to manage as well
[10:39] Zha Ewry: How do I know, provably, which trust properties to apply to the service
[10:39] Tao Takashi: Zha: By not having the URL to that region directly but asking the region domain for a cap for that region?
[10:39] Goldie Katsu: assets and groups and a few other things are complex in that they need in some sense to be able to span multiple agent domains and/or region domains.
[10:39] Zha Ewry: (and since the domaina are all seperately managed, )
[10:40] Zha Ewry: I think it needs to become explicit
[10:40] Latha Serevi: If you have a way to securely claim ownership of a capability (like "member of AWGroupies" or "obeys privacy policy X", then the rest can be implemented on that layre, right?)
[10:41] Zha Ewry: I also think we need to try and, as much as possible, assumne its groupings of services, NOT, fixed
[10:41] Zha Ewry: The current AD/RD split, is based on a best guess, and the first round of tryign to scale out
[10:41] Tao Takashi: Zha: right. I would even think that it should not really be fixed..
[10:41] Tao Takashi: just endpoints on how you can discover those services
[10:42] Zha Ewry: The proprties I want to preserver include:
[10:42] Zha Ewry: Ways of proving I'm a memeber without broadcating my internal state changes to everyone
[10:42] Tao Takashi: like IM and group handling could even be separate services. They might not even be just restricted to OGP but can span the whole web/social networking stuff as well
[10:43] Tao Takashi: and it makes sense IMHO to not invent too much new if those web people already work on it because in the end we need to merge it again ;-)
[10:43] Tao Takashi: now I have two 5s... what do I do with it? ;-)
[10:43] Tao Takashi: maybe I give them out to somebody else soon :)
[10:44] Zha Ewry: One of the ways we have the current hard to scale tangle, is that the relatonships, and the singletons are baked into the architetcure
[10:44] Zha Ewry: So... What I'd like us to try and do is say
[10:44] Zha Ewry: ""Here is how a set of services are described, and here is how I prove memebership"
[10:44] Tara5 Oh: I have to jump to RL for a bit byee all and see ya later!
[10:45] Zha Ewry: Ideally, Tao should eb able to ut up an agent domain, which supports text only chat, and a client should eb able to ffind it, and use it, using the prorotocls
[10:45] Tao Takashi: I already proposed XRDS for service discovery (and also started to imlpement some support for pyogp)
[10:47] Zha Ewry: it might be interesting to mark up some stuff in XRDS simple, and see how it looks
[10:47] Tao Takashi: the basic pattern in OpenSocial, MySpace's DataAvailability is always that you discover services via XRDS and do authorization to use them via OAuth
[10:47] Zha Ewry: (picking the XRDS-simple subset expclitly, and seeing if it is suddicient
[10:47] Tao Takashi: yes, XRDS-Simple is the thing
[10:48] Tao Takashi: that's why I mean actually, just a lazy typer
[10:52] Latha Serevi: Being new to XRDS-Simple, I've been checking out "XRDS-Simple in context" [7] . I also hadn't eard of Shibboleth [8] "a standards based, open source software package for web single sign-on"
[10:52] Zha Ewry: looks pained and mutters WSRF, OGGF, Globus and looks very pained
[10:53] Tao Takashi: that's maybe another interesting topic. do we version the whole protocol or do we break it up into smaller chunks, like IM, group, etc.
[10:53] Zha Ewry: Versioning is a nightmare, but better to think about it now
[10:53] Zha Ewry: and.. I can't see versioning the whole thing
[10:53] Tao Takashi: as said before, the problem I heard about shibboleth is that it's very hierarchical and not easy to extend
[10:53] Zha Ewry: We're likely to want to incrementally update single capabilties
[10:53] Lolcat Adamczyk: breaking up. think small devices with do only chat, why update them when the audio changes?
[10:53] Tao Takashi: Zha: right, the whole thing would really be a pain
[10:55] Tao Takashi: and you could build workgroups around those sub protocols
[10:55] Whump Linden: Tao, Zha, don't take my mention as an endorsement of Shiboleth, just that it implents a desirable behavior, checking an assertation without revealing any other information. "Is Alice part of group Beta?"
[10:56] Zha Ewry: if we do clusters of function, we can always regroupr them
[10:56] Zha Ewry: And the degenerate case of clusters is a single service
[10:56] Latha Serevi: I'm not quite getting the picture of how these pieces might fit together. If you know a URL associated with my identity, couldn't you just ask me what my service mappings are rather than using resource discovery? Shibboleth is a possible solution to implementing the "verifiable group membership problem" but is unrelated to resource discovery?
[10:56] Tao Takashi: IM, group, profile management, inventory, land management all come to mind as sub protocols which sound logical
[10:56] Rociorizo Magic: TAO I work with SHIBBOLETH for 10 years
[10:56] Zha Ewry: if we do monolithic, we're screwed.
[10:56] Rociorizo Magic: how long and WHAT you have done with it?
[10:56] Tao Takashi: Latha: well, this URL to you migth be a URL which has an XRDS document or has one attached to it
[11:00] Goldie Katsu: Rociorizo, if you have something to contribute in the discussion, such as how Shibboleth can help/isn't hierarchical etc, then contribute.
[11:00] Tao Takashi: and right Zha, we probably can always regroup them by simply defining a new protocol uri
[11:01] Tao Takashi: too bad I don't have the contact of that guy presenting shibboleth to us, we could ask him
[11:01] Saijanai Kuhn: heavy sigh. Note to self. Figure out better screeening or stop inviting
[11:01] Tao Takashi: he was deploying it for some university
[11:01] Rociorizo Magic: you think computer serurity is a game
[11:01] Whump Linden: wonders if we started talking about Dysons, vs. Eureka, vs. Electrolux, we'd get a different set of interactions.
[11:02] Goldie Katsu: Rociorizo, some of the people here are security architects who have designed security for a living for large scale services provided by well known companies.
[11:02] Zha Ewry: On the contrary, we think computer security is a complex, deeply painful field, which requires thorughtfgul discussion
[11:02] Latha Serevi: Rociorizo, please be polite. I have IM'ed Freeemason and will talk to him later. I have IM'ed you also and would be happy to hear what you have to say.