Note: The timestamps here are NZST (UTC -10, New Zealand.) The meeting began on Jul 14 at 13:30 EDT, (UTC +5, Eastern US.) Ahh, the joys of internet communications. Props to ajmitch. Pre-meeting =========== Jul 15 00:41:53 <-- ThreeSeas (3seas@user-38lc4bo.dialup.mindspring.com) has left #dotgnu-auth Jul 15 04:20:53 --> eric (~eric@12-224-124-83.client.attbi.com) has joined #dotgnu-auth Jul 15 04:23:28 --- eric is now known as ericAlt Jul 15 04:38:56 --> alias (~fallout@151.202.89.41) has joined #dotgnu-auth Jul 15 04:55:19 --> FrePort (~chatzilla@207.172.44.224) has joined #dotgnu-auth Jul 15 05:02:12 --> fitzix (~fitzix@64.252.133.27) has joined #dotgnu-auth Jul 15 05:04:33 * fitzix is away: phone Jul 15 05:16:16 * fitzix is back (gone 00:11:42) Jul 15 05:23:48 --> Lanatha (~lanatha@KGoldenberg-3.Homenet.Dal.Ca) has joined #dotgnu-auth Jul 15 05:23:54 allo all Jul 15 05:23:57 lo Jul 15 05:24:06 welcome to the auth meet Jul 15 05:24:10 than you Jul 15 05:24:11 any auth people here? Jul 15 05:24:19 fitzix invited me Jul 15 05:24:22 * ducttape is just an IRC groupy atm Jul 15 05:24:36 * Lanatha is Mark McKenna FYI Jul 15 05:24:57 nice to meet you Jul 15 05:25:05 * Lanatha bows Jul 15 05:25:19 Lanatha: welcome! Jul 15 05:25:20 wow, been awhile since I elbowed about on irc Jul 15 05:25:34 hey, fz Jul 15 05:25:41 do you recall who I am? Jul 15 05:25:50 sure do :) Jul 15 05:26:03 * fitzix is away: phone again Jul 15 05:26:08 arg Jul 15 05:26:10 cool... I tried to check that site you gave me, but it was down Jul 15 05:26:13 why does she do this?!? Jul 15 05:26:20 www.dotgnu.org Jul 15 05:26:22 * Lanatha laughs Jul 15 05:26:31 yeah - there's a DNS problem Jul 15 05:26:47 * mds arrives Jul 15 05:26:49 ah... what's the IP Jul 15 05:26:51 fitzix: who? Jul 15 05:27:11 * ducttape multitasks Jul 15 05:27:13 ducttape: gf Jul 15 05:27:23 fitzix: ah, gf's are like that Jul 15 05:27:26 ducttape: she always marathon calls me during meetings Jul 15 05:27:29 i concur Jul 15 05:27:42 fz: it's passive aggressive. Jul 15 05:27:46 * ducttape has a mobile phone and just turns it off when no contact is wanted Jul 15 05:27:57 * Lanatha agrees with duct Jul 15 05:28:13 when people say anything, i am just not in an area with signal :o) Jul 15 05:28:35 *laugh* I just say I have the damn right to turn my phone off whenever I feel like it :P Jul 15 05:28:43 lol Jul 15 05:28:50 * Lanatha afk sec Jul 15 05:29:06 * ducttape ponders bringing the spuds to the comp to peal Jul 15 05:29:55 so has anything happened on the meeting yet? Jul 15 05:30:07 doesn't start till now Jul 15 05:30:14 * ducttape opens meeting Jul 15 05:30:17 weird... oh, right Jul 15 05:30:17 :o) Jul 15 05:30:25 1:30 EST Jul 15 05:30:31 6:30 GMT Jul 15 05:30:36 it's 2:30 here, I thought i already translated it Jul 15 05:30:53 wheres here? Jul 15 05:30:55 does this happen on a weekly basis? Jul 15 05:31:03 AST -- Nova Scotia Canada World Sol Jul 15 05:31:15 ah Meeting - (Round 1) =================== Jul 15 05:31:23 * mds moves to bring the meeting to order. (I have limited time...) Jul 15 05:31:26 introductions? Jul 15 05:31:36 Mark McKenna, newbie Jul 15 05:31:38 * ducttape waves "hi I'm ducttape Jul 15 05:31:39 " Jul 15 05:32:08 Mario Santana, macs (Modular Access Control System) Jul 15 05:32:11 eeeeeddddddddd0. Jul 15 05:32:16 .. Jul 15 05:32:25 ++00000000000000000000000000000000000000000000000000000000000000000 Jul 15 05:32:26 morning Jul 15 05:32:26 eH? Jul 15 05:32:36 fitzix: put your cat away... ;-) Jul 15 05:32:42 * Lanatha laughs Jul 15 05:33:13 * ducttape looks at fitzix and ponders why the cat has to sleep on the keyboard Jul 15 05:33:32 ajmitch: morning (or should we say, middle of the night?) Jul 15 05:34:56 so is there like a meeting or something? Jul 15 05:35:07 alias: yes Jul 15 05:35:10 who are we missing? antifa? Jul 15 05:35:11 18:31 * mds moves to bring the meeting to order. (I have limited time...) Jul 15 05:35:18 mds: is chairing Jul 15 05:35:26 we're missing fitzix :) Jul 15 05:35:54 fitzix: is here, well hes logged in but has some feline laying on the keyboard Jul 15 05:36:03 that's what i mean Jul 15 05:36:19 ok, agenda for today's meeting? Jul 15 05:36:21 * ducttape gets water spray out to scare off da kitty Jul 15 05:36:46 oic. Ok, I'll chair until fitzix get back. Yeah? Jul 15 05:36:53 aye Jul 15 05:37:02 * ducttape votes mds to chair in fitzix's abscence Jul 15 05:37:11 from last meeting's logs (http://www.freesoftware.fsf.org/dg-authwg/logs/2002-07-07.txt) the agenda: Jul 15 05:37:16 yup Jul 15 05:37:19 1) Webservices target list (presentation antifa) Jul 15 05:37:25 2) ROI (all, presentation: mds) Jul 15 05:37:35 3) More argument over the diagrams (freport, mds) Jul 15 05:37:49 leading to 4) Network topology discussion (all) Jul 15 05:37:59 5) Discussion about the future (planning for non-participants) Jul 15 05:38:09 * fitzix is back (gone 00:12:06) Jul 15 05:38:11 uh, that's it I think. Jul 15 05:38:16 ok Jul 15 05:38:17 one question: What is the IP for www.dotgnu.org Jul 15 05:38:22 * mds yeilds the chair to fitzix. Jul 15 05:38:28 sorry - yeah, whenever I'm not around just run with it :) Jul 15 05:39:00 sorry - just got a new kitten, she's all over everything Jul 15 05:39:07 anyway Jul 15 05:39:11 as long as I bring it back... ;-P Jul 15 05:39:19 lol Jul 15 05:39:21 * Lanatha chokes Jul 15 05:39:23 mds: gotta sit on something Jul 15 05:39:24 mmm, kitten Jul 15 05:39:34 ducttape: lol Jul 15 05:39:52 I hearby bring this meeting to order (again) Jul 15 05:39:52 ducttape: /nick alf Jul 15 05:39:56 second Jul 15 05:39:58 65.194.192.130 Jul 15 05:40:02 tx Jul 15 05:40:11 * ducttape notes there is a keyboard driver which detects feline keyboard interference! Jul 15 05:40:37 present are ajmitch alias ducttape ericAlt fitzix FrePort jonaslund Lanatha and mds Jul 15 05:40:41 * ducttape will shut up now Jul 15 05:40:57 Ok - so let's get right down to business Jul 15 05:41:08 antifa's not here, so let's table #1 for now Jul 15 05:41:21 aye Jul 15 05:41:25 aye Return on Investment (Presentation) =================================== Jul 15 05:41:25 mds, do you have anything for Return on Investment for auth projects? Jul 15 05:41:54 yes, well. I was thinking of introducing the topic, then getting ideas. Jul 15 05:42:02 I don't know that we need to hound it to death, Jul 15 05:42:22 but I think roi is a reasonably good indicator of a project's worth. Jul 15 05:42:30 not yet, but I suspect an entire meeting could be taken up just discussing methods of ROI for auth services Jul 15 05:42:36 useful as such and as an adoption argument. Jul 15 05:42:54 ROI? Jul 15 05:43:04 ROI: Return on Investment: The amount of time it takes for the benefits of a system to outweigh its costs. Jul 15 05:43:12 ah ok Jul 15 05:43:15 are you referring specifically for ROI for people implementing the auth system or for the auth project itself? Jul 15 05:43:45 umm, I don't understand the question. Jul 15 05:44:04 I mean ROI for, eg, DotGNU, or any other org *using* the auth project... Jul 15 05:44:27 OK - that makes sense... like for company X that uses the code Jul 15 05:44:30 Can a system have an ROI in terms of itself? Jul 15 05:44:44 sure thing - the project uses resources itself Jul 15 05:44:54 I'd think that you need a return on investment of your time :) Jul 15 05:45:08 even if it's just the satisfaction of doing the project Jul 15 05:45:14 aye. Clear. Jul 15 05:45:21 ah, one question: Is the auth system meant to be decentralized in some way, or is there to be a central auth server which we (or someone) runs? Jul 15 05:45:58 Lanatha: both are possible, but the goal of the DotGNU auth system is that it can't be dependant on a centralized system Jul 15 05:46:28 my next question would be how does a server requesting authentication know to which auth server to look for the required information? Jul 15 05:46:39 meaning: whatever is implemented may have a central auth server component, but it also has to be runable locally Jul 15 05:46:45 uh... pardon me if I'm speaking out of turn Jul 15 05:46:54 * Lanatha nods Jul 15 05:47:05 Lanatha: some kind of configuration, probably. Jul 15 05:47:07 Lanatha: that would be handled by the client Jul 15 05:47:20 or by selecting the server in a config on the webservice itself Jul 15 05:47:45 maybe we should officially open with questions, for newcomers' benefit? Jul 15 05:47:56 sure thing - I'm open for that Open Floor ========== Jul 15 05:48:05 * fitzix hereby opens the floor Jul 15 05:48:15 * ajmitch falls thru Jul 15 05:48:18 Lanatha: go to town. =) Jul 15 05:48:20 lol Jul 15 05:48:21 ajmitch: lol Jul 15 05:48:35 ajmitch: playing too much nethack, are you? ;-) Jul 15 05:48:48 nah Jul 15 05:48:57 * ajmitch is freezing cold :) Jul 15 05:49:01 *chuckle* so the auth server would be generally run by the company requiring authentication? Jul 15 05:49:08 Lanatha: yes. Jul 15 05:49:32 is that an improvement over the traditional auth services we have now (in terms of transparency fo rtthe client)? Jul 15 05:49:32 that's one way to do it Jul 15 05:49:46 Lanatha: it can be if it's not mandated Jul 15 05:50:19 Lanatha: yes, because you can set it up any way you like Jul 15 05:50:23 right, of course. Then the actual implementation is controlled by the concerned parties, not some corporation whose name we won't reveal Jul 15 05:50:54 you can trust a third party, ala *assport, you can do it yourself, you can require certificates, etc. Jul 15 05:51:08 Lanatha: of course. This is Free Software. Jul 15 05:51:17 * mds loves Free Software. Jul 15 05:51:58 Lanatha: the parts of the implementation that may need protection are the protocols. Jul 15 05:51:59 Or you can run your auth locally Jul 15 05:52:08 *nog* Jul 15 05:52:36 Well, part of the idea is that people can't be forced to keep all of their auth data on a central server in the first place... Jul 15 05:52:46 As long as those are commoditized (not embraced-and-extended) the implementation is in the hands of each and every user. Jul 15 05:52:54 another thing I thought of: the system of course would be most useful if a server which wants user authentication could go to one place Jul 15 05:52:58 so, the architecture almost has to be built to obscure the server end... but there are lots of options Jul 15 05:53:11 --> antifa (~ken@63.230.172.239) has joined #dotgnu-auth Jul 15 05:53:19 yo antifa Jul 15 05:53:23 * mds welcomes antifa Jul 15 05:53:25 hi all, sorry i'm late :) Jul 15 05:53:33 heh - welcome antifa :) Jul 15 05:53:48 to get that information. But that should be done without giving the owner of that system exclusive control over that information Jul 15 05:53:52 antifa: the floor is open for questions atm Jul 15 05:54:09 coolio Jul 15 05:54:19 Lanatha: yes, and it opens up some of the same problems that we saw before Jul 15 05:54:22 Lanatha: indeed, should be done without giving the system's owner *any* control over the info Jul 15 05:54:44 this should be done by encrypting the tokens Jul 15 05:54:45 what about a decentralized web-oriented system like the peer-to-peer filesharing networks? Jul 15 05:54:56 of course, the only way that can be truly guaranteed is for the user to store her info locally Jul 15 05:55:03 and not giving out both parts of the key ring to just anyone Jul 15 05:55:38 * Lanatha nods slowly as stuff percolates Jul 15 05:55:58 Lanatha: the p2p stuff I think is most useful for tying discrete installations to each other, so they can cross-authenticate using each other's accessible info. Jul 15 05:56:27 yes, but I'm generally against a P2P auth system that stores auth datum on other clients Jul 15 05:56:41 Lanatha: and the web of trust you make that way can get extremely complicated in a hurry. Jul 15 05:56:42 yeah, me too Jul 15 05:56:42 the reason why is because that gives access to your info to untrusted parties Jul 15 05:57:01 even if it's encrypted Jul 15 05:57:02 fitzix: I don't think the auth data has to be stored on peers... Jul 15 05:57:25 I'm thinking mostly of a system where the auth systems don't actually store any sensitive info Jul 15 05:57:26 ...for the system to benefit from cross-auth'ing over a p2p network. Jul 15 05:57:30 mds: It would have to be if the decentralized auth system were to have persistent auth data Jul 15 05:57:44 i'm still looking for a good model of a p2p auth architecture myself, i think there's a lot of merit there, but i want to see a good plan, ie - how does freenet do it Jul 15 05:57:46 they just pass requests to the location where that info can be found Jul 15 05:58:06 fitzix: not if we're ok with the latency of grabbing auth data from the (user's local) source every time. Jul 15 05:58:23 mds: if the source is always connected Jul 15 05:58:27 mds: agreed - but then it's not really decentralized :) Jul 15 05:58:33 heheh :) Jul 15 05:58:43 I like the tokens concept of having some data stored publicly and some stored locally Jul 15 05:58:44 well, not *necessarily* decentralized. Jul 15 05:59:12 the problem of virtual ID is that we won't be able to meet functionality of the existing centralized systems without some data persistance Jul 15 05:59:18 we have to allow people to participate in the "decentralized" network, without forcing them to use its, umm, less secure features. Jul 15 05:59:35 which virtually mandates storing at least some of the data on a server somewhere Jul 15 05:59:43 mds: firmly agreed Jul 15 05:59:50 can't our system contain some of both? like a decentralized system with a certain number of CA's for example? Jul 15 06:00:07 antifa: yes Jul 15 06:00:10 it can Jul 15 06:00:19 what's a CA Jul 15 06:00:22 antifa: well, individuals can trust any "CA" they want. I imagine trustworthy CA's will emerge. Jul 15 06:00:26 Certificate Authority Jul 15 06:00:31 like a web of trust model where there's always some authority you can auth against Jul 15 06:00:35 A trusted third party. Jul 15 06:00:41 * Lanatha nods Jul 15 06:00:57 There's one problem with WOT Jul 15 06:01:02 and it's a big problem Jul 15 06:01:10 I trust A, and A trusts B Jul 15 06:01:15 I don't trust B Jul 15 06:01:19 what do you get? Jul 15 06:01:31 antifa: only you get to pick which CA you trust in which ways Jul 15 06:01:40 exactly Jul 15 06:01:41 fitzix: you can just do what krb does Jul 15 06:02:12 alias: go on' Jul 15 06:02:30 fitzix: well you get f+a and a+b but f-b...it should still work as long as f is ok not receiving any of b's services etc... Jul 15 06:02:43 * antifa wonders if that made sense Jul 15 06:02:49 oh, erh they have realms and basically you specify what kind of trust you give A Jul 15 06:02:59 and you can say that an entity can give trust to another entity Jul 15 06:03:00 anti: makes sense, but sounds like your WOT gets potentially big and complex Jul 15 06:03:06 and it's not very user transparent anymore Jul 15 06:03:19 precisely Jul 15 06:03:35 here's a though Jul 15 06:03:36 t Jul 15 06:03:45 there are models, but they get very very complex... and you have to ultimately delegate trust to server admins Jul 15 06:03:55 the average user doesn't understand WOT models Jul 15 06:03:57 yes, user transparency is a problem, it's a big part of the reason why it's been hard to migrate our users to openpgp Jul 15 06:04:14 auth server B gets a request for my sensitive data; it passes the request on to server A Jul 15 06:04:40 instead of channelling through server A, the service has to go talk to server A to get the info Jul 15 06:04:55 and so it doesn't matter if A and B trust each other, because all they do is redirect Jul 15 06:05:16 eh... could get bulky Jul 15 06:05:27 Lanatha: that only works if a B establishes a direct link between the service and A -- at which point we no longer have a WOT system :) Jul 15 06:05:38 we have a webservice directory Jul 15 06:06:01 or, more realistically Jul 15 06:06:12 a user directory that functions like a webservice directory Jul 15 06:06:21 which is not a bad idea at all Jul 15 06:06:42 yeah, I kinda thought Jul 15 06:06:44 particularly if you're going to have numerous auth servers Jul 15 06:06:47 hmmm...could you explain that some more? Jul 15 06:06:49 which we must Jul 15 06:06:55 OK Jul 15 06:07:09 let's say that there are 2000 DotGNU auth servers world-wide Jul 15 06:07:25 all run by different authorities... ISP's, corps, etc Jul 15 06:07:38 User A doesn't want to sign up to 50 of them Jul 15 06:07:45 * ducttape returns with coffee Jul 15 06:07:50 so, he signs up to a centralized user directory Jul 15 06:08:01 * ajmitch 'borrows' ducttape's coffee Jul 15 06:08:12 all that directory does is reference which server that person's auth data is on Jul 15 06:08:18 * ducttape notes this coffee is going to collapse in on its self and forma a singularity soon Jul 15 06:08:27 mmm, good coffee Jul 15 06:08:34 so each auth server doesn't neccessarily contain *all* the auth data, just parts of it? Jul 15 06:08:39 * mds respecfully submits that this is all OT -- dg-authwg is about protecting DotGNU, not necessarily DotGNU's users. Unless I'm wrong? Jul 15 06:08:39 which satisfies the needs of the other auth servers Jul 15 06:09:26 ie, sandboxing? Jul 15 06:09:29 * antifa is not sure htis is OT Jul 15 06:09:44 hrm... can I ask a fundamental question? Jul 15 06:09:47 mds: Well, the purpose is to produce auth services which requires a certain amount of user-centric design... but, our primary purpose at this moment is the back-end Jul 15 06:09:54 mds: sandboxing is not enough Jul 15 06:10:05 fitzix: not enough, but necessary? Jul 15 06:10:10 mds: yes Jul 15 06:10:18 so, auth servers contain *some* auth data, coordinated by a centralized user directory which contains a listing of *all* users and their relevant information? Jul 15 06:10:26 mds: you can't sandbox an external service in the same sense as sandboxing code Jul 15 06:10:57 * antifa realizes he needs to read up on sandboxing Jul 15 06:10:59 anti: sorta, except users would have to sign on to the central user directory. It'd be an option Jul 15 06:11:05 and not really so transparent anymore Jul 15 06:11:09 antifa: well, the central director(y/ies) would be an optional after-the-fact type of thing Jul 15 06:11:19 IMHO, the most important factor in the success of .GNU is user transparency Jul 15 06:11:21 precisely Jul 15 06:11:27 fitzix: aye. So the SEE is the "user" in this discussion? Jul 15 06:12:05 SEE> Jul 15 06:12:05 mds: Well, I don't tend to think of the SEE in auth terms except that the SEE uses the auth system for it's own profile storage and local auth Jul 15 06:12:07 SEE? Jul 15 06:12:20 Secure execution environment Jul 15 06:12:23 nog Jul 15 06:12:29 so who controls the central user dir's? do they serve as a dir for services as well? seems to me that would get HUGE if we're successful Jul 15 06:12:32 the auth service may be sandboxed by the SEE just like any other code... Jul 15 06:12:50 but I don't see the SEE as being central to auth's function - I'm not sure that that's even possible Jul 15 06:13:07 or, more appropriately, efficient Jul 15 06:13:21 fitzix: oic. I thought the SEE would *use* the auth's function to secure the execution env. Jul 15 06:13:35 what exactly is the basic job of the auth system? Jul 15 06:13:51 Lanatha: I'm not exactly sure atm. fitzix? Jul 15 06:14:03 from what i understand, the auth system needs to do basic user/passwd auth as well as profiles, tokens, sessions, and keys Jul 15 06:14:08 antifa: Yeah - we'd have to create a webservices directory ultimately... but WSDL, as I understand it, is encumbered by patents Jul 15 06:14:11 hehe... I'm a bad one for losing track of my goals and getting carried away in the details Jul 15 06:14:43 OK - do you guys want a rundown on the requirements of the auth system and why they are? Jul 15 06:14:50 sure Jul 15 06:14:54 fitzix: yes please Jul 15 06:15:06 Hi all..... Jul 15 06:15:08 Back last year, when DotGNU was originally formed - the primary issue was passport Jul 15 06:15:10 Did the meeting start early? Jul 15 06:15:11 hi Jul 15 06:15:21 ericAlt: nope Jul 15 06:15:22 hello ericAlt :) Jul 15 06:15:24 or did i miscalculate UTC Jul 15 06:15:26 sure. maybe prefaced by a short description of the problem it's to solve? Jul 15 06:15:27 late actually :) Jul 15 06:15:29 ericAlt: you're late :) Jul 15 06:15:41 since you're late, we were forced to put out a contract on you Jul 15 06:15:42 mds: makes sense to me :) Jul 15 06:15:50 :-P Jul 15 06:16:01 so - passport was the primary issue Jul 15 06:16:03 ericAlt: yoyoyo Jul 15 06:16:17 sorry....i was told it was to be at 18:30 UTC not 18:00 Jul 15 06:16:20 ah well Jul 15 06:16:32 fitzix: continue, please.... Jul 15 06:16:33 * antifa chuckles to himself that passport doesn't even solve the problem it was intended for Jul 15 06:16:41 For obvious reasons, it's centralized system concerned us... Jul 15 06:16:43 antifa: explain? Jul 15 06:17:06 * Lanatha applauds friends who show up spontaneously with good beer Jul 15 06:17:17 but more so, because an internet authentication lock-up by MS could ostensibly lock GNU/Linux users out of the internet Jul 15 06:17:21 think about it Jul 15 06:17:33 * mds has about 15 minutes before he must leave. =( Jul 15 06:17:34 yeah, scary prospect Jul 15 06:17:49 fitzix: clear enough. very scary. Jul 15 06:17:56 it goes deeper, too... potentially locking out any e-commerce except via Passport Jul 15 06:18:04 if MS can hold all of the base level services necessary for even accessing the a significant portion of the internet ... well, you get the picture :) Jul 15 06:18:07 Lanatha: precisely Jul 15 06:18:19 so, the need for an alternative was obvious Jul 15 06:18:32 fitzix: time to let mds talk on ROI? Jul 15 06:18:35 but, in the process, we have to solve the problems that passport doesn't Jul 15 06:18:44 hrm... Passport brags almost total user transparency, doesn't it? At the cost of user awareness of security issues, of course Jul 15 06:18:45 yes - this is coming to an end :) Jul 15 06:18:49 fitzix: this is under the assumption that Passport was widely adopted and alternatives not provided, I assume? Jul 15 06:18:53 ajmitch: nah, we can skip that for today. what fitzix is talking about is important. Jul 15 06:18:57 ericAlt: yes Jul 15 06:18:59 mds: k Jul 15 06:19:06 ericAlt: which, at the time, was a valid assumption :) Jul 15 06:19:12 fitzix: sure... Jul 15 06:19:21 it's not anymore, which makes me happy Jul 15 06:19:42 but - the goals for the auth system are as follows: Jul 15 06:20:01 It has to be secure Jul 15 06:20:05 ensure privacy Jul 15 06:20:15 allow users to control their information Jul 15 06:20:28 passport is transparent, but there a big problems with it....for instance how can it handle multiple users with various auth levels for various services....it can *kind of* currently, M$ will have to rework it as they continue to try and make it dominant Jul 15 06:20:28 i should probably read up on teh current state of passport, since i'm not convinced that anything MS invested so much time/money into is going to quietly disappear without biting someone in the butt later on Jul 15 06:20:55 be decentralized in the way that users can choose their auth system and control it themselves (by running their own server or through the client) Jul 15 06:21:13 ultimately it's the discussion about how the web services evolution of the internet will develop Jul 15 06:21:17 fitzix: in short, allow users to be in control.... Jul 15 06:21:31 ok Jul 15 06:21:41 yep - that's the big thing Jul 15 06:21:44 but not just in control Jul 15 06:21:49 fitzix: so the "auth" system is basically a distributed, secure store for user profile information? Jul 15 06:21:50 secure, as safe as possible Jul 15 06:22:00 mds: essentially, yes Jul 15 06:22:31 mds: it has to do more than that....it needs to be able to auth users against services as well as services against services Jul 15 06:22:33 uh... I think that it has to be a tradeoff between optional control and optional transparency Jul 15 06:22:49 so, in distributing the user profile information, where exactly does it go? to a "security service provider" trusted by the user? Jul 15 06:23:26 antifa: there's 2 pieces -- the info store and the decision-making. The decision-making needs access to the info store, but they're independent. Jul 15 06:23:38 mds: makes sense Jul 15 06:23:47 hmmm.... Jul 15 06:24:04 and they have to be independant Jul 15 06:24:13 it's like having an auth system for the auth system Jul 15 06:24:25 because services will store their own auth information for use Jul 15 06:24:35 but you need to be able to access the central store Jul 15 06:24:38 macs is more decision-making part than info store. Jul 15 06:24:40 * ducttape drinks coffee Jul 15 06:24:42 it can't just be transparent :) Jul 15 06:24:55 I think I'm starting to see why FrePort is always harping on the local/remote store difference. Jul 15 06:25:12 mds: it's important to the infrastructure Jul 15 06:25:33 fitzix: yes, I see that now. Jul 15 06:25:40 the remote part can be abstracted by the local part Jul 15 06:25:41 this is why freenet is compelling, if we can publish services to a network, we can have a central store of auth info, yet contain it in a decentralized way Jul 15 06:25:57 hence service <-> local <-> remote Jul 15 06:26:22 antifa: but freenet distributes the info in a way that the info's owner can't control. Jul 15 06:26:35 the original "model" of this (even though it's backwards) is in my tokens document from last year Jul 15 06:26:39 * mds envies ducttape and his coffee... Jul 15 06:26:43 hrm. It's really as much about locating information as about securing it Jul 15 06:26:57 Lanatha: precisely. Tricky. Jul 15 06:27:03 mds: but is that such bad thing if you combine it with the idea that no one using the system can control it? Jul 15 06:27:25 yeah - you can't distribute profile information transparently... well, you can - but it shouldn't be the default Jul 15 06:27:28 I think a decentralised 'search engine' would work quite well Jul 15 06:27:47 antifa: I think so, because I want control over what happens to my private info, no? Jul 15 06:28:20 well yes, but that control can be had by controlling the seperation of intra/internet right? Jul 15 06:28:34 antifa: it's not that simple Jul 15 06:28:39 I put my public information on a trusted server in the decentralised network Jul 15 06:28:54 antifa: intranet auth services are relatively predictable, and already exist Jul 15 06:29:12 ie which services and information is intranet only, and which services/info are public Jul 15 06:29:18 antifa: we're targeting internet auth (and intranet auth falls out the bottom automatically) Jul 15 06:29:46 my info doesn't get spread out over the network, it stays where I put it, but anyone can get to it through any other auth server (unless I specifically say not to) Jul 15 06:29:48 antifa: yes, but there can be internet-private and intranet-public classes of info as well Jul 15 06:30:03 Lanatha: hence the directory system :) Jul 15 06:30:07 is there a security hazard stuck in there somewhere? Jul 15 06:30:40 Lanatha: not if the referring server makes a direct link between service and target auth server Jul 15 06:30:50 Lanatha: as opposed to acting as a middle-man Jul 15 06:31:00 a middle-man scenario would have significant security issues Jul 15 06:31:16 fitzix: what if the middlemen couldn't decrypt the information Jul 15 06:31:37 Lanatha: that makes it considerably better Jul 15 06:31:54 seems like we could acheive that effect using keys and cert's Jul 15 06:31:54 Lanatha: but I'd like to avoid promiscuously tossing around encrypted tokens :) Jul 15 06:32:09 so 'trusting' a person is a one-time deal which means giving them the decrypt key Jul 15 06:32:21 fitzix: how come? Jul 15 06:32:22 The "public informatino" that your'e talking about storing on the auth server -- what does it consist of? Personal data, like name / address /other info? Or just auth data (public key) Jul 15 06:32:36 it may take a while, but it's still possible to brute-force crack a 2048kb encrypted token Jul 15 06:32:46 ericAlt: both Jul 15 06:32:47 eric: anything you want to be accessible to the network Jul 15 06:32:56 ya know what would help? having some sort of auth chart to give me a picture of how this architecture might look Jul 15 06:33:04 fitzix: a necessary risk. The world's not perfectly secure, and I wouldn't feel good living here if it was Jul 15 06:33:22 Lanatha: yes, but the key is limiting risk to the user Jul 15 06:33:22 ok Jul 15 06:33:31 Lanatha: if you don't have to do it in auth -- it shouldn't be done :) Jul 15 06:33:40 hehe Jul 15 06:33:48 hrm Jul 15 06:33:52 makes sense, really Jul 15 06:34:10 can i ask something, did you all receive the email i sent about gnutls last week? Jul 15 06:34:27 antifa: yep - and you're right... use of SSL is a good thing Jul 15 06:34:43 Honestly, I think that public data like name, address, CC number, etc. isn't really part of an auth framework..... Obviously any service that wants to access that data will have to use the auth framework, but I don't see how it's intrinsic to the auth system. Jul 15 06:35:04 * fitzix 's CC # is *NOT* public data Jul 15 06:35:06 :) Jul 15 06:35:20 Well, then I'm not sure what you mean by "public data" Jul 15 06:35:26 come fitzix, you can share... ;) Jul 15 06:35:45 Unfortunately, I have to go. I'll post the logs later (to http://www.freesoftware.fsf.org/dg-authwg/logs/) Jul 15 06:36:00 mds: bye :) Jul 15 06:36:01 fit: I guess I think the centralized user database idea is unnecessary. The auth services maybe should be half search engine: service asks for auth data, traverses decen network to get it, and, IF it's allowed to have that info, it gets back an auth server to go to to get it. Jul 15 06:36:10 Addresses and CC numbers are both things you might potentially want to be able to send to a vendor if you're buying something. Jul 15 06:36:30 ericAlt: because profiling is key to network services... you see, you can have secure auth for numerous services through token provision, but profile information comes for free in the infrastructure Jul 15 06:36:41 eric: only on a strictly voluntary basisc. Jul 15 06:36:51 Lanatha: of course... Jul 15 06:36:54 mds: later mds, have a nice day :) Jul 15 06:36:58 cya mds Jul 15 06:37:03 bye mds Jul 15 06:37:24 fitzix: well profiling and sessions are both needs that have to be addressed by the auth service Jul 15 06:38:25 antifa: yes Jul 15 06:38:31 Hmm. It just seemed to me that authentication is an abstract thing ... could apply to inviduals, machines, organizations, whatever ... names and addresses and other user info seem secondary. but maybe i don't know what i'm talking about. Jul 15 06:38:32 :-) Jul 15 06:38:54 well, it's not that you have a set of predefined data Jul 15 06:38:56 How are names and addresses and other profile information useful in teh auth framework? Jul 15 06:39:10 ericAlt: have you read the tokens document? Jul 15 06:39:26 Not yet. Sorry. Maybe I should keep m ymouth shut. :-) Jul 15 06:39:29 ericAlt: seems to me that part of the way the auth service will determine if a user/service has access to network services is dependant in part on that profile information Jul 15 06:39:46 ericAlt: no - that's OK :) Jul 15 06:39:56 ericAlt: Just wanted to know if you had that background Jul 15 06:40:02 Hmm. OK. So it's *not* a part of authentication, but may be a part of authorization. Jul 15 06:40:07 * antifa could be wrong too...i'm still new at this Jul 15 06:40:11 well, the idea is to abstract the profile information via token/key names Jul 15 06:40:26 antifa: no - you're right Jul 15 06:40:29 it's really more a secure online cookie database than an authentication service Jul 15 06:40:36 Lanatha: precisely Jul 15 06:40:37 re, both I guess Jul 15 06:40:39 er Jul 15 06:40:40 hehe Jul 15 06:40:43 yes, both Jul 15 06:40:49 hehe Jul 15 06:40:51 with the potential for default generic cookies Jul 15 06:40:57 you see Jul 15 06:40:57 because you want to know who's asking before you answer Jul 15 06:41:05 authentication is just verifying that an entity that claims to be ID X is actually entity X... Jul 15 06:41:07 I don't personally buy the idea of "one password for every site" Jul 15 06:41:12 names and addresses have nothing to do with that... Jul 15 06:41:14 and I figure I should be able to auth the service I potentially want to use before I tell him I exist, too Jul 15 06:41:35 if people want to develop services whose authorization depends on profile data, i guess that's ok.... Jul 15 06:41:44 ericAlt: yes, but that system is incomplete for the purpose of webservices Jul 15 06:41:49 so the cookie/key/token database could be stored in a decentralized fashion as long as it's secure and we have a reasonably quick way to search for the info we need Jul 15 06:42:01 If authentication all takes place through a preconstructed mechanism, all secure network traffic becomes immeasurably simpler and faster Jul 15 06:42:02 * fitzix bangs his gavel Jul 15 06:42:06 silence :) Jul 15 06:42:12 heh - people are getting confused here Jul 15 06:42:16 sorry. :-) Jul 15 06:42:18 <-- alias (~fallout@151.202.89.41) has left #dotgnu-auth ("Client Exiting") Jul 15 06:42:30 no problem -- I just don't want this to degenerate into an argument :) Jul 15 06:42:49 OK, I think I understand Jul 15 06:42:56 yes, you're right -- authentication is simply the verification that person A is person A Jul 15 06:43:04 but it's only part of the needed infrastructure :) Jul 15 06:43:13 I think that what you guys are talking about is just a bigger system than I thought you were going to address. :-) Jul 15 06:43:25 It has to be Jul 15 06:43:40 and, we get it for free Jul 15 06:43:52 I don't personally believe in the "one password for every site" ideology Jul 15 06:43:55 it's just not secure Jul 15 06:44:09 a thought Jul 15 06:44:15 even if it's abstracted behind a return value (or positive response) Jul 15 06:44:24 I also don't think that a lot of sites are going to go for it Jul 15 06:44:35 that's one of the problems with passport Jul 15 06:44:40 hmmmm. Jul 15 06:44:58 --> alias (~fallout@pool-151-202-89-41.ny5030.east.verizon.net) has joined #dotgnu-auth Jul 15 06:44:59 the important part is to have a flexible authentication system that services can use to store THEIR auth data, along with anything else Jul 15 06:45:08 Right.... Jul 15 06:45:11 the key is to verify that that service has the right to access those tokens Jul 15 06:45:23 fitzix: how does the "one pw for every site" play into this? Jul 15 06:45:39 a flexible system (that allows any auth data to be used by the service) gets profiling for free because it has to support named tokens Jul 15 06:46:07 ericAlt: passport tries to solve the problem by having all users authenticate to webservices against passport's response Jul 15 06:46:37 ericAlt: which is, IMO, a bad way to do things :) Jul 15 06:46:56 sure.... Jul 15 06:47:04 now, in a way, a profiling system makes it APPEAR that there is one PW for every site Jul 15 06:47:04 * antifa for a good overview of web service challenges, i thought this document was helpful -> http://www-106.ibm.com/developerworks/webservices/library/ws-peer1.html Jul 15 06:47:08 but doesn't mandate it Jul 15 06:47:30 But in a system like this, we're not talking about storing passwords, are we? We should be storing public keys, right? Jul 15 06:47:33 or am I confused? Jul 15 06:47:39 antifa: bookmarked :) Jul 15 06:47:52 public keys AND password data Jul 15 06:48:05 that way, you can't break the system just by stealing the keys Jul 15 06:48:13 you need the personalized data as well Jul 15 06:48:18 stealing the public keys? Jul 15 06:48:19 basically, adding a middleman you trust to take good care of your stuff, and delegate for you Jul 15 06:48:33 rather, hand out for you Jul 15 06:48:58 i must misunderstand since the public keys should be free for anyone to see... Jul 15 06:49:23 ericAlt: public keys work well, but thats why we were talking about auth architecture like WOT earlier, and public keys can't do things like sessions transactions, which is where the 'cookie' DB is from i think Jul 15 06:49:26 ericAlt: yes, in that scenario a webservice would authenticate based on it's having a key to access the token Jul 15 06:49:34 ericAlt: sorry - the webservice side private key Jul 15 06:50:34 it's a complex system :) Jul 15 06:50:41 but it has to be Jul 15 06:51:06 ok.....i think i'll stop interfering here and just listen for a while and see what I can learn. :-) Jul 15 06:51:56 * antifa wonders where FrePort is... Jul 15 06:52:44 http://users.ids.net/~nightspd/freport/ Jul 15 06:53:03 that's the FrePort diagram site... I think you guys might find it interesting Jul 15 06:53:10 as well as http://macs.sf.net Jul 15 06:53:46 bookmarked Jul 15 06:54:08 fitzix: is this an appropriate time to ask something? Jul 15 06:54:30 sure thing Jul 15 06:55:48 fitzix: the quesiton i had from the gnutls email is whether or not combined macs/FrePort is to attain gpg/ssl functionality, or if we are looking to include something like gnutls that has already built those functions? Jul 15 06:56:11 well that depends on need Jul 15 06:56:25 if we can use a GNU or other Free Software project Jul 15 06:56:28 we should Jul 15 06:56:46 but if it's more practical to take code and build our own support, then that's what we should do Jul 15 06:57:15 i see, thank you Jul 15 06:57:27 so, for something like SSL -- it'll be easier to just use GNUTLS Jul 15 06:57:44 but for GPG support, well, that might be a bit more tricky Jul 15 06:58:19 i guess that would depend on that status of the gpg support in gnutls right? Jul 15 06:58:22 so has all of the theoretical designwork been solidfied already? Jul 15 06:58:46 Lanatha: i'd like to see that document if it exists hehe Jul 15 06:58:57 antifa: yes, and GPG' Jul 15 06:59:11 s ability to be turned into a library usable for something like this Jul 15 06:59:37 Lanatha: a lot of it has been solidified on a per-project basis. But, just like anything else... things are bound to change Jul 15 06:59:56 FrePort is almost back Jul 15 07:00:03 FrePort is John Le'Brecage Jul 15 07:00:19 leader of the FrePort project -- whose link I gave you shortly before Jul 15 07:00:26 I guess I've been thinking a lot about how to make systems palatable to the general public Jul 15 07:00:31 He's not feeling well, so be easy on him :) Jul 15 07:00:42 fit: yeah, I've been looking at it off and on Jul 15 07:00:44 fitzix: the openpgp library page (gpgme) -> http://www.gnupg.org/gpgme.html Jul 15 07:01:22 Lanatha: we can't underestimate the need to be sensitive to the needs of the public Jul 15 07:01:31 antifa: thanks :) Jul 15 07:01:34 are we actually considering user transparency for this task, or is that a separate concern? Jul 15 07:01:49 are we starting the meeting when FrePort gets back? Jul 15 07:02:59 Lanatha: user transparency is important, but I'll take security first... but, on the same line, we can't compete with passport well unless we consider transparency to be important Jul 15 07:03:23 antifa: well, the meeting started at about 1:40 EST ... but it's been all question and answer. :) Jul 15 07:03:32 which is good Jul 15 07:03:47 Actually, there's probably a million questions people want to ask me before we start. I'd like to li mit it to six. Jul 15 07:04:04 see, that's what I've been thinking. Now my personal opinion of most people is that they'll take a hit to security in order for things to be a bit simpler, because most don't really believe that anything they can't see can possibly be that dangerous Jul 15 07:04:07 fitzix: I only ask because i have to go in about 30 minutes, but i have the presentation ready...stuff just came up is all Jul 15 07:04:22 * antifa welcomes FrePort Jul 15 07:04:27 * Lanatha bows Jul 15 07:04:30 FrePort: welcome Jul 15 07:04:46 * fitzix is away: nature calls Jul 15 07:05:02 continue without me - I'll catch up Meeting (Attempt 2) =================== Jul 15 07:05:19 give the gavel to FrePort lol Jul 15 07:05:28 He Jul 15 07:05:31 did Jul 15 07:05:33 * fitzix gives the gavel to FrePort Jul 15 07:05:50 * FrePort bangs the gavel. Jul 15 07:06:28 Order please, this is the third weekly meeting of the DotGNU working group. Grab your freshments and go to your seats... Jul 15 07:07:17 I know I'm a bit late, but I'm aslo a bit under the weather. We have a number of presentations scheduled. Jul 15 07:08:28 excuse me a moment. Jul 15 07:08:55 * FrePort conferences quickly with presenters (message me please on the status of your presentations) Jul 15 07:10:48 Our agenda of meeting for this session is: Jul 15 07:11:01 1) Webservices target list (presentation antifa) Jul 15 07:11:14 2) ROI (all, presentation: mds) Jul 15 07:11:37 3) More debate over the diagrams (freport, mds) Jul 15 07:11:51 4) Network topology discussion Jul 15 07:12:05 5) Discussion about the future (planning for non-participants) Jul 15 07:13:00 I now yield the floor to antifa. This is his first presentation with us, so please reserve your questions until the end of his presentation) Jul 15 07:13:26 * ajmitch sits in the back row & restrains his heckling Jul 15 07:13:44 This is the web services target list presentation...first a couple of things... Jul 15 07:14:36 Web Services being a 'newer' and quickly changing topic made compiling this list difficult Jul 15 07:14:57 freshmeat and sourceforge list these services all across the board... Jul 15 07:15:17 so the target list was to be compiled against the following criteria: Jul 15 07:15:41 1) the service requires a login or profile information now or in the short term Jul 15 07:15:51 2) the service is gpl Jul 15 07:16:17 to that i added 3) web service is defined as: a collection of functions that are packaged as a Jul 15 07:16:18 single entity and published to the network for use by other programs. Jul 15 07:17:09 one second please :) Jul 15 07:19:05 it's a big list, trying to get it on the web for people to look at...sorry for the delay Jul 15 07:20:24 alright, FrePort is putting it up, will be a moment... Jul 15 07:20:58 but based upon that criterion, it was often very difficult to determine if certain projects fit or not... Jul 15 07:21:08 so the list may contain some items that can be discarded... Jul 15 07:22:48 the web services that are out there however are a huge range of things, like account managers, pager utilities, various server software packages, web identity services, etc... Jul 15 07:23:52 all of the projects i looked at had some sort of auth mechanism, but none of them were based on much of a standard, none of them had much documentation on their auth system, and all of the auth systems i saw were still very much in development. Jul 15 07:24:06 with that here's the list -> http://users.ids.net/~nightspd/f Jul 15 07:24:08 report/dotgnu-auth/web_services_list.txt Jul 15 07:24:14 oops, lemme do that again Jul 15 07:24:19 http://users.ids.net/~nightspd/freport/dotgnu-auth/web_services_list.txt Jul 15 07:24:22 there lol Jul 15 07:24:47 And the floor is now open for questions :) Jul 15 07:26:51 Interesting variety... not the collection I would have expected. Jul 15 07:29:06 * fitzix is back (gone 00:24:21) Jul 15 07:29:21 Everyone got this? I'm interested in two things. Initial impressions and missed items. As the defacto maintainer of this list we need to update antifa with any projects we think should belong on it. Jul 15 07:30:02 Since I have to leave in just a few minutes, please send any comments/updates to the auth mailing list, perhaps it would be better if we discussed it there anyway Jul 15 07:30:42 And the question I have for FrePort is: do you want me to prepare the next one of these for next week? we have webmail, blogs, freeciv, and mobile on the list still Jul 15 07:30:45 works for me -- wow, it's a long list... and I'm sure that we can add a bit to it Jul 15 07:31:38 Sounds good if we argue them out on the ML. Can you present a revised list for next week along with your new list? Jul 15 07:31:59 FrePort: certainly, how does webmail sound for next week? Jul 15 07:32:12 * fitzix notes that the ML might not work for people at the moment -- DNS issues Jul 15 07:33:23 noted. Should we send suggestions direct to antifa? Jul 15 07:33:29 my email address is -> knowack@uswest.net, you can send directly to me as well Jul 15 07:34:26 does that work for you fitzix? Jul 15 07:34:43 works for me Jul 15 07:34:46 If that's all, issue #2 is up assuming that mds is ready to go and there are no further questions for antifa? Jul 15 07:34:55 mds had to go Jul 15 07:35:02 let's table issue #2 Jul 15 07:35:18 * FrePort emits a rumbling sigh and a loud cough and sneeze. Jul 15 07:35:36 I'll see you all next week then if there's no questions :) i have to go unfortunately Jul 15 07:35:46 Okay. Issue #3 also has to be tabled then. Jul 15 07:36:11 See you 'round antifa. May your e-mail box be overflowing. Jul 15 07:36:23 bye all! and i hope so! lol Jul 15 07:36:27 <-- antifa has quit ("User abortion with 5 coathooks") Jul 15 07:36:28 later antifa - good presentation :) Jul 15 07:36:32 And 4. Jul 15 07:36:58 So that brings us back to 5, which is what has gone on for the last 2 hours. Jul 15 07:37:48 Shall we limit that discussion until 1600 EST, and then roll our agenda for next week? Jul 15 07:37:59 sounds good Jul 15 07:38:22 OK - back fully Jul 15 07:38:32 * FrePort opens the floor to discussion on whatever was being discussed previously. Jul 15 07:38:49 We'll be going for some 30 minutes. Jul 15 07:39:21 does anyone have any questions for FrePort regarding the design of auth systems? Jul 15 07:39:38 * FrePort waits patiently. Jul 15 07:40:34 is anyone else here? :) Jul 15 07:41:21 Call a meeting to order and everyone goes out for pizza. Jul 15 07:41:58 lol Jul 15 07:43:09 Okay, I've a question fitzix. How do we (or others) make money off of DotGNU and auth in particular... Jul 15 07:43:41 Because the smell of money is what brings 'em in the door. Jul 15 07:43:43 Well, there are a number of potential models Jul 15 07:44:11 * fitzix personally thinks that money is dirty and smells nasty ... but, then again... Jul 15 07:44:12 :) Jul 15 07:44:26 one model is the "pay-per-provider" model Jul 15 07:44:48 where a user pays a monthly/yearly/whatever fee for being allowed to store information on the server Jul 15 07:44:56 that's a fairly straightforward model. Jul 15 07:45:04 his profile you mean? Jul 15 07:45:09 yep Jul 15 07:45:23 now - I think that that would be a very competitive markt Jul 15 07:45:45 but, it could also be very lucritive if planned properly Jul 15 07:45:46 * fitzix is away: phone Jul 15 07:45:53 grr... Jul 15 07:46:22 Very much so, it would most closely mirror the ISP market... Jul 15 07:48:14 Wherein they largely differentiate themselves on their uptime and the amount of capacity they give a user and at what price. Jul 15 07:54:11 * fitzix is back (gone 00:08:25) Jul 15 07:54:28 back Jul 15 07:54:28 sorry all... i tuned out for a while.... Jul 15 07:54:30 yep Jul 15 07:54:44 in fact, that market would probably be largely tied to the ISP market Jul 15 07:54:51 as a Value Added incentive Jul 15 07:55:19 ISP's put up their own auth servers and provide auth for their customers Jul 15 07:55:31 another money-making opportunity is in support for the auth solution Jul 15 07:55:35 and customization of it Jul 15 07:55:40 ooh, money Jul 15 07:55:49 I could see people putting up installations under contract Food Fight and VRS! ================== Jul 15 07:55:51 * ducttape is an anarchist, but needs to eat occasionally Jul 15 07:56:04 mm... food Jul 15 07:56:39 anarchy and eating all in the same sentence... now that's a good time Jul 15 07:56:41 :) Jul 15 07:57:52 * FrePort screams "Food Fight!!!" and chucks a pizza frisbee style at ajmitch. Jul 15 07:58:02 That anarchistic enough for ya all? Jul 15 07:58:08 lol - yep Jul 15 07:58:18 * fitzix catches a splatter of pizza in his mouth Jul 15 07:58:37 So, what other ways do we have for monetizing this? Jul 15 07:58:45 * fitzix throws a frozen hotdog at FrePort Jul 15 07:58:46 FrePort: no Jul 15 07:59:15 * ericAlt throws a vegan tofudog at fitzix Jul 15 07:59:30 * ericAlt thinks hotdogs are a little nasty.... :-) Jul 15 07:59:45 which is precisely why you throw them... Jul 15 07:59:45 lol Jul 15 07:59:56 they throw better when they're frozen Jul 15 08:00:15 * FrePort catches ducttapes toss and with a graceless spin wings it at ericAlt. Jul 15 08:00:37 hmm - well, services could pay the servers for access to the profiles (access ultimately controlled by the user, of course) Jul 15 08:01:01 my toss? eeek? Jul 15 08:01:05 * fitzix wonders what ducttape tossed Jul 15 08:01:06 :) Jul 15 08:01:39 * fitzix tosses a egg foo yung patty at FrePort Jul 15 08:01:41 With all this food flying about it's difficult for the sick man to track it all. Jul 15 08:01:47 lol Jul 15 08:01:51 so..... Jul 15 08:01:55 * FrePort ducks a bowl of jello thrown from another channel. Jul 15 08:02:17 what do you auth experts have to say about VRS.... and the authentication of machines when they want to sign in to a VRS cluster? Jul 15 08:02:24 Interesting. So instead of the user paying to keep his data private, the services pay to access it... Jul 15 08:02:34 FrePort: yep Jul 15 08:02:43 FrePort: I could see user cooperatives forming to handle that Jul 15 08:02:51 * ducttape doesn't have the apparatus to toss Jul 15 08:02:59 actually, the more I think about that idea, the more I'm interested in it Jul 15 08:03:04 * ducttape fires a custard cannon at fitzix Jul 15 08:03:05 I guess my return question is "What does VRS need to know about the client when they log-in?" Jul 15 08:03:08 ducttape: you have no arms? :) Jul 15 08:03:10 lol Jul 15 08:03:22 fitzix: no, am missing something more fundemantal than that Jul 15 08:03:31 Good aim? Jul 15 08:03:32 ducttape: now that could have multiple meanings :) Jul 15 08:03:35 ducttape: lol Jul 15 08:04:11 * FrePort wipes custard from his coifierre. Jul 15 08:04:22 That's it. This means war. Jul 15 08:05:20 * fitzix tosses a full pot of coffee (one of the big metal jugs) at dotgnu-sage on #dotgnu Jul 15 08:05:49 FrePort: unfortunately we don't know that yet. :-) VRS is very protomorphic Jul 15 08:06:28 the basics are that we need to simply authenticate so we know who is joining the cluster. Jul 15 08:06:52 i think that the VRS cluster will maintain its own list of allowed nodes and their associated trust level within that VRS cluster Jul 15 08:06:54 Well, basically there are three services that MACS@Freport could offer. Jul 15 08:07:31 I would think that VRS would use the auth system similarly to the way that the SEE would use it Jul 15 08:07:39 Is the trust level morphic... it changes depending on which nodes are added? Jul 15 08:08:06 probably not. Jul 15 08:08:56 Okay, scratch one idea... Jul 15 08:09:47 Will the VRS client need some setup data as in "Where's the master node that will assign me neighbour nodes? or like that? Jul 15 08:11:14 (BTW, has anyone ever noticed that Passport is basically Kerberos with "cookies" substituted for "tickets"?) Jul 15 08:12:48 FrePort: hmm... it might need some setup data.... Jul 15 08:13:03 FrePort: yes Jul 15 08:13:05 not a master node, but it might be given neighbor nodes (VRS says "no!" to the concept of "master nodes") Jul 15 08:14:30 Well, consider that the M@F is three components: Jul 15 08:15:28 an auth service, an access service, and a databanking service (these do not correspond to the names on the diagram) Jul 15 08:16:12 The auth services merely authenticates the users to the other services. Jul 15 08:16:43 the access service rules whether any data in the databanking service can go to any particular requestor Jul 15 08:17:13 The databanking service stores the actual data in encrypterd form. Jul 15 08:17:39 So, I see the following possibilities (all off the top of my head) Jul 15 08:18:34 1) The VRS client can store whatever data it needs in the databank for logging onto the VRS. (saves having to remember a password or challenge/response) Jul 15 08:19:16 2) The VRS client can save its configuration data in the databank (makes the user capable of roaming) Jul 15 08:19:49 hmmm.... Jul 15 08:20:11 And most ambitiously: 3) A server frontend to the VRS network could be added to the front of MACS@Freport so that.... Jul 15 08:21:21 a MACS@Freport server is a node on VRS, and can provide more finegrained filtering of trust through the access service. Jul 15 08:22:01 hey guys - I've gotta get going here Jul 15 08:22:04 Now all that's just off the top of my head, without Mario to slap me around and tell me why it definitely couldn't work. Jul 15 08:22:26 I'll talk to you guys later Jul 15 08:22:29 good meeting :) Jul 15 08:22:36 seeya fitzix Jul 15 08:22:44 * FrePort waves g'bye to fitzix. Jul 15 08:22:44 * ericAlt sighs..... Jul 15 08:22:53 adios :) Jul 15 08:22:58 bye Jul 15 08:23:08 unfortunately VRS is, i think, still way too much vaporware to have much of a picture of its needs in terms of the details of auth Jul 15 08:23:08 damn it's hot and humid here Jul 15 08:24:03 Well keep it in the back of your mind as you plan... Jul 15 08:24:19 we've got about 2.5 people and we're only just now having our first IRC meeting to get some ideas about what we're doing. :-/ Jul 15 08:24:32 yeah.....thanks for the info Jul 15 08:24:59 <-- fitzix has quit ("Client Exiting") Jul 15 08:25:03 Good luck with VRS. See you at next week's meeting? Jul 15 08:25:25 actually no....going to be gone for a week tuesday-tuesday..... Jul 15 08:25:43 Okay. *nods* Jul 15 08:26:05 Unless there's anything more anyone needs to know from me??? Jul 15 08:27:21 * FrePort bangs the gavel Jul 15 08:27:27 Meeting adjourned. Post-meeting ============ Jul 15 08:28:33 * ajmitch returns :) Jul 15 08:28:48 In time for me to bang the gavel? Jul 15 08:29:07 ajmitch: Want to e-mail me the log? Jul 15 08:30:44 hmm? Jul 15 08:30:55 i'll see what i can do