[00:05:33] --- mrichardson has joined
[02:02:59] --- mrichardson has left
[05:22:32] --- jas has joined
[06:45:41] --- Benoit Bailleux has left: Lost connection
[06:45:51] --- jas has left
[07:24:02] --- kdz has joined
[07:24:09] --- kdz has left
[08:37:58] --- DanC has joined
[08:38:18] <DanC> is this thing on?
[08:38:55] <DanC> any idea what the update latency for http://www3.ietf.org/meetings/ietf-logs/dix@rooms.jabber.ietf.org/2006-03-21.html is?
[08:41:08] <DanC> aha. I see myself in the log. This thing is on.
[08:54:53] --- sandro has joined
[08:55:06] <sandro> Hey, DanC.
[08:55:48] * sandro hopes someone else shows up in the next 65 minutes.
[08:58:43] <sandro> DanC, did sxip get presented as phishing solution at the W3C workshop?
[09:09:24] --- tlr has joined
[09:09:33] <tlr> hey
[09:09:59] <sandro> hey, Thomas
[09:10:51] <tlr> (I need to put up the slides from the workshop, urgently...)
[09:11:03] <sandro> I know how that goes.
[09:11:35] <sandro> /who
[09:11:37] <sandro> heh
[09:11:53] <tlr> danc, sandro, tlr are here. But I think others will actually get to see the conversation when they join the channel.
[09:11:58] <tlr> (not 100% sure about that, though)
[09:12:18] <sandro> Yes, or it'll be in the logs, at least.
[09:12:35] <tlr> ah, it's logged server-side?
[09:12:55] <sandro> Can you not see DanC talking about that before you joined?
[09:13:12] <tlr> I see "DanC: aha. I see myself in the log. This thing is on."
[09:13:18] <tlr> and some text before that
[09:13:42] <sandro> the line before that gives the link to the logs.
[09:13:46] <tlr> yep
[09:14:06] <tlr> I just hadn't realized before that the logging is done by the server itself, not by some bot or other participant.
[09:14:16] <sandro> Ah.
[09:19:21] --- jlcjohn has joined
[09:23:41] --- Rob Yates has joined
[09:24:56] * DanC tunes in
[09:25:26] <DanC> Sandro, DIX/SXIP got presented at the workshop; the connection to phishing was sorta left implicit
[09:26:24] * DanC wonders if this client has a "beep when you see my name" feature
[09:27:38] <DanC> hmm... it seems to have the relevant feature, but doesn't know where the relevant sound file is
[09:27:51] * DanC heads over to #dawg
[09:32:41] <sandro> no beeps for me, but I happened to be reading your e-mail to the same effect at the time. :-)
[09:32:53] --- jas has joined
[09:39:30] --- nsb has joined
[09:41:59] --- AndyGallant has joined
[09:42:27] --- AndyGallant has left
[09:44:30] --- mrichardson has joined
[09:45:40] --- Dave Cridland has joined
[09:46:38] <mrichardson> hi.
[09:48:08] --- Jeffrey Altman has joined
[09:48:40] --- dick.hardt has joined
[09:49:40] --- hartmans has joined
[09:49:43] --- Hollenbeck has joined
[09:52:31] --- Dave Cridland has left
[09:53:15] --- Barry Leiba has joined
[09:55:42] <Hollenbeck> Slides available here:
[09:55:45] <Hollenbeck> http://www3.ietf.org/proceedings/06mar/slides/dix-0.ppt
[09:57:36] <Hollenbeck> or more generally:
[09:57:37] <Hollenbeck> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65
[09:57:47] <dick.hardt> Bob has some slides that we are working on posting up there right now
[09:57:51] --- agallant has joined
[09:59:06] --- dumdidum has joined
[09:59:18] --- nm has joined
[09:59:31] --- nm has left
[09:59:33] --- tianlinyi has joined
[09:59:35] --- rowan0 has joined
[10:01:06] --- hardie@jabber.psg.com has joined
[10:01:40] --- robsiemb has joined
[10:02:18] * sandro hears audio. excellent
[10:03:12] <rowan0> no audio here...
[10:03:24] --- brabson has joined
[10:03:32] <sandro> I heard a bit, then it died. ah, working again now.
[10:03:34] <Jeffrey Altman> I have audio
[10:03:55] <rowan0> got it now
[10:03:56] --- lisaDusseault@jabber.psg.com has joined
[10:04:17] --- leifj has joined
[10:04:20] --- cabo--tzi--org@jabber.org has joined
[10:04:27] --- marcos.sanz has joined
[10:04:29] --- stephenfarr has joined
[10:04:37] * sandro loses audio again
[10:04:41] <rowan0> eep
[10:04:55] --- hardie@jabber.psg.com has left
[10:05:07] --- psangster has joined
[10:05:09] --- ludomp has joined
[10:05:10] <Jeffrey Altman> the audio stream is very inconsistent.
[10:05:12] --- rlbob has joined
[10:05:31] * sandro gets audio back
[10:05:39] <mrichardson> Jeffrey, is that a general comment, or a specific problem just now?
[10:05:49] --- fenton has joined
[10:06:06] --- dcrocker has joined
[10:06:26] <marcos.sanz> Agenda:
[10:06:28] <robsiemb> (someone goes to registration desk to investigate audio problems)
[10:06:28] --- pawal has joined
[10:06:58] <dick.hardt> nice picture of Bob
[10:07:00] <marcos.sanz> http://www3.ietf.org/proceedings/06mar/agenda/dix.html
[10:07:14] --- kdz has joined
[10:07:25] --- eludom has joined
[10:08:21] --- mcfadden has joined
[10:09:01] <Jeffrey Altman> the audio stream sounds like someone placed a mic next to a laptop fan
[10:09:16] <lisaDusseault@jabber.psg.com> Ben Laurie checked -- hesays the desk people are going to look into the audio quality
[10:09:29] <rowan0> The black helicopters are coming for your identity
[10:10:27] <marcos.sanz> A brief overview of the Scene Setting is being given
[10:10:53] <marcos.sanz> Web authentication, many different solutions
[10:11:26] <eludom> 12+ solutions...10 years ago
[10:11:28] <mrichardson> maybe the microphone on the front table is too close to laptops up there?
[10:11:32] <eludom> today...
[10:11:35] <mrichardson> doesn't look like it...
[10:12:24] <eludom> losts more stuff. Who's on my site ? Who can I interact with ?
[10:12:51] <marcos.sanz> There is no enterprise Identity Management System yet
[10:13:04] <eludom> SSO required, but no enterprise (global) IdM system
[10:13:21] <eludom> so....new goals
[10:13:42] <Rob Yates> is the audio very quiet for everyone? i have my volume way up and can hardly hear
[10:13:55] <eludom> user centric, widely deployable, good enough security, scale to web
[10:13:56] --- rjc has joined
[10:13:57] <jas> same here.
[10:13:58] <agallant> agree - can someone ask him to speak up?
[10:14:03] --- alexeymelnikov has joined
[10:14:30] <Jeffrey Altman> bob morgan needs to learn to use a mic better but that is not the fundamental problem. I'm still hearing a fan
[10:14:30] <dick.hardt> is that better on the audio?
[10:14:35] <Jeffrey Altman> that's better
[10:14:45] --- pk has joined
[10:14:47] <dick.hardt> they turned off the mic that was on the table
[10:14:51] <Rob Yates> yup, much better
[10:15:00] <rowan0> Still sounds like harddrives and helicopters to me :)
[10:15:02] <marcos.sanz> Reminder: If somebody wants something to be speaked out at the microphone, please prefix with "mic:"
[10:15:38] <eludom> pitch done.
[10:15:45] --- elwynd has joined
[10:16:07] <eludom> John Merrils: define a few terms
[10:16:41] --- Glenn Parsons has joined
[10:16:54] <jlcjohn> the audio problem sound a lot like what we used to call "motorboating"; see, for example http://www.avid.com/onlineSupport/supportcontent.asp?browse=&productID=0&contentID=8636
[10:17:10] <jlcjohn> people using the mic need to NOT mumble. :^(
[10:17:42] <eludom> reading problem statement form charter
[10:17:47] <marcos.sanz> http://dixs.org/index.php/DIX_Charter
[10:18:06] <eludom> drill down
[10:18:11] <eludom> for user:
[10:18:23] <eludom> have to manage/retype ids
[10:18:26] <eludom> for service ops:
[10:18:40] <eludom> inaccurate data, incomlete data, ....
[10:18:53] <eludom> Example. Amazon.com web form
[10:19:04] <eludom> Proposed goals:
[10:19:24] <eludom> automate DIX , protect privacy, minimal barriers to adoptoin
[10:19:33] <eludom> benefit
[10:19:50] <eludom> for users: easier, for SPs: better data
[10:20:16] <eludom> Scope discussion
[10:20:39] <eludom> in scope: DIX between user and service, HTTP/HTML, Browser based
[10:21:00] <dcrocker> FWIW, I just posted a follow-up note to the mailing list, attempting to summarize the functional deliverables for DIX, in terms that are intended to match IETF chartering. So, my note earlier this morning attempted to describe how dix might get used, while this later note attempts to define deliverables. With any luck, both notes are compatible with what other folks have in mind for DIX.
[10:21:03] <eludom> out of scope: servie to service, federation, schema, digital certs, how users authenicate
[10:21:27] --- ShoichiSakane has joined
[10:21:32] <Hollenbeck> I thought it was a helpful contribution, Dave.
[10:21:34] --- kent has joined
[10:21:51] --- nov has joined
[10:21:54] <eludom> Eliott Lear:
[10:22:05] <marcos.sanz> "I consider myself narrow and ambitious"
[10:22:09] <Jeffrey Altman> speak up please
[10:22:09] <marcos.sanz> *laughter*
[10:22:13] <eludom> Like most of scope, but....
[10:22:27] <Jeffrey Altman> thank you
[10:22:31] --- bhoeneis has joined
[10:22:54] <eludom> el: my mac has a keychain
[10:23:17] <eludom> el: does DIX manage authentication or credentials
[10:23:29] <eludom> answer: you can choose where authenticadtoin happens
[10:23:43] --- beuchelt has joined
[10:23:44] <eludom> el: do docs address that ?
[10:24:04] <eludom> answer: separration is a requirement of what we're doing
[10:24:06] <eludom> Sam Hartman:
[10:25:28] <eludom> sh: need to increase security without reducing usablity
[10:25:50] <eludom> sh: you seem to be ignoring server auth to client, not just client to server
[10:25:53] <marcos.sanz> "particularly in scope how the server authenticates to the identity provider and to the clients, not only the other way round"
[10:26:04] <eludom> Michael slavach (sp)?
[10:26:12] <eludom> Dick Hart replies to Sam
[10:26:38] <eludom> Is Microsoft Infocard in scope or out
[10:26:46] <eludom> sh: needs to be in scope
[10:27:24] <eludom> DH: how you auth is out of scope
[10:27:45] <eludom> ms: would like to inclde peer-to-peer sip
[10:27:47] <marcos.sanz> DH: In scope are the results of the authentication
[10:28:37] <eludom> ms: zrtp being presented by Phil Zimmerman now, check his work
[10:28:55] <eludom> ms: would like that added to scope
[10:29:02] <eludom> answer: will add for debate
[10:29:31] <eludom> question: why are we here, project liberty does same work, need to survey existing work
[10:29:32] --- inet6num@jabber.org has joined
[10:29:42] <eludom> q: what is different about this ?
[10:30:01] <marcos.sanz> That was R. Shockey asking.
[10:30:10] <eludom> answer: we believe that this is a diferent problem space
[10:30:33] * eludom is missing names of questioners
[10:30:38] <Hollenbeck> This is Marc Blanchet
[10:31:17] --- ShoichiSakane has left: Replaced by new connection
[10:31:19] <mrichardson> http://www.projectliberty.org/
[10:31:50] <eludom> two classes of problems: user at end, or no user at end.
[10:31:53] --- ShoichiSakane has joined
[10:31:59] <marcos.sanz> M. Blanchet: "If HTTP is the transport, why do I have to care about who is the client at the other side" (this is because scope explicitly outlisted non-browser based applications)
[10:32:04] <eludom> solving the user at the end with a browser problem
[10:32:25] --- ShoichiSakane has left
[10:32:34] --- ShoichiSakane has joined
[10:33:17] <marcos.sanz> Answer: "To leverage on the abilities of million browsers out there"
[10:33:30] <eludom> separate discussion will address other HTTP (server to server)
[10:33:46] <eludom> AOL: don't limit scope to browsers
[10:34:05] * tlr wonders who from AOL was speaking.
[10:34:44] <eludom> AOL: the space of problems is much bigger than it was in the day of only bowser. We're pussing the limits of browser based auth now. Problems with term "browser"
[10:34:48] <eludom> Sam hartman:
[10:35:02] <marcos.sanz> E.Chung, I believe
[10:35:45] <eludom> avoid choosing substrates based on auth techs available.
[10:35:52] --- rjc has left
[10:36:02] <eludom> sh: concerned about push to HTTP for wrong reasons
[10:36:10] <eludom> Dave Crocker:
[10:36:26] <eludom> "I am in favor of world peace"
[10:36:30] <eludom> "No your not"
[10:36:51] <eludom> This is a hard problem. History shows.
[10:37:07] <eludom> dc: all prior efforts have fallen down
[10:37:18] --- mani has joined
[10:37:29] <eludom> dc: need to work hard on adoption, showing people need
[10:37:53] <eludom> dc: need to distinguish between internal tech discussions vs. public discussions, basic utility
[10:37:54] <mani> [the audio streaming is in bad shape]
[10:38:16] <rowan0> quite
[10:38:26] <eludom> dc: Example. Scope: Need to have discussion, but not in a general audience.
[10:38:49] --- nm has joined
[10:38:53] <eludom> dc: Need to distinguish information framework, set vs how you move it around
[10:38:58] --- nov has left
[10:39:07] <eludom> dc: HTTP is one initial delivarable, but not only one
[10:39:22] --- beuchelt has left
[10:39:41] <eludom> dc: I think what's in your head an public perception is different
[10:40:23] <eludom> dc: Clients can request info from services in many ways, HTTP is just one
[10:40:34] <eludom> dc: May fit under your persona construct
[10:40:59] --- nm has left
[10:41:07] <eludom> dc: Browser only solutions will not be flexible enough
[10:41:20] <eludom> reply: Yes, challange is explaining
[10:41:33] <eludom> being discussed in another community
[10:41:55] --- Mallikarjun has joined
[10:42:03] <eludom> approach in charter: don't exclude other possible uses. ?HTTP just one binding?
[10:42:09] <eludom> Phil:
[10:42:16] <marcos.sanz> reply: this will be a layered approach, and won't exclude other solutions
[10:42:24] <eludom> objective should be how to deply ?
[10:42:51] <eludom> [xxx] are successfull in certian communities
[10:43:23] <eludom> ?if this succeeds? now people will have one password for the internet...reuse...bank fraud easier
[10:44:00] <eludom> Need something lightweight, like HTTP/HTML, easy to hack
[10:44:06] <eludom> then it grew, perl, ruby..
[10:44:13] <eludom> we might be doing opposite here
[10:45:04] --- nov has joined
[10:45:25] <eludom> Jeff ?Hodges?:
[10:45:42] <eludom> There is existing prior work. You appear to be reinveting world.
[10:45:42] <dick.hardt> yes
[10:45:54] * mrichardson what phb said.
[10:45:57] --- jeffmc930@gmail.com has joined
[10:45:58] <eludom> answer: we're not ignoring it, if existing tech can solve problems , use it.
[10:46:20] <eludom> Eliott lear:
[10:46:46] --- Mallikarjun has left
[10:46:52] <eludom> The burden is on this group not to reinvent the world. What do you want to do ?
[10:47:00] --- ShoichiSakane has left
[10:47:02] <eludom> el: What about email apps ?
[10:47:14] <eludom> answer: out of scope/up for debate
[10:47:27] <eludom> "in future might be a good thing"
[10:47:40] <eludom> el: calendering, access to network ?
[10:48:02] <eludom> "we can solve this in the web layer, then push it down"
[10:48:13] <eludom> el: You're targeting the wrong problem.
[10:48:33] <fenton> "all about moving the result of authentication around, not doing the authentication"
[10:48:33] <eludom> el: First thing on agenda good: providing a way to transport bits for SSO
[10:48:57] <marcos.sanz> el: and don't worry what the application is!
[10:49:31] <eludom> el: if you focus too much on HTTP you won't be able to reprodce in other protocls
[10:49:34] <eludom> Eric Rescorla:
[10:50:04] <eludom> I'm going to introduce terms. Sorry if there is overload.
[10:50:31] <eludom> er: echoing objective: Design a system whereby user can auth to trusted 3ed paryy
[10:50:48] <eludom> er: 3ed party can provide info (verified) back
[10:51:31] <lisaDusseault@jabber.psg.com> ekr also introduced the term "relying party" which is what the dmd1 docs call the "member site"
[10:52:22] <eludom> er: define formats, then bindings (classic securtiy approach)
[10:52:38] --- hsantos has joined
[10:52:56] <eludom> er: other solutions not getting things done aparently
[10:53:34] --- alfredo.matos has joined
[10:53:38] --- mani has left
[10:53:52] <eludom> Moving on to Requirements
[10:54:08] <eludom> "Seven Laws of Identity"
[10:54:23] <eludom> www.identityblog.com
[10:54:38] <marcos.sanz> http://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf
[10:55:11] --- resnick has joined
[10:56:19] * mrichardson having just re-read SAML charter, I need a very strong statement as to why DIX differs from SAML.
[10:56:30] <eludom> eric rescorla goes to mic
[10:56:44] <eludom> er: these are not principals, this is a laundry list
[10:56:46] --- jis has joined
[10:57:04] <mrichardson> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
[10:57:10] <eludom> sam hartman:
[10:57:34] <eludom> You need a paragraph that describes what you are trying to do in enough detail that I can reason about it and get it all in my ead
[10:57:38] <eludom> Rich:
[10:57:54] <marcos.sanz> Richard Schockey speaking
[10:58:01] <eludom> What are you trying to solve that has not been solved elsewhere....SSO, Single domain....
[10:58:07] <eludom> Jim:
[10:58:32] <eludom> Dave Crocker:
[10:58:33] <marcos.sanz> J. Semersheim
[10:58:48] <eludom> "I have a fair track record of involvement in BOFs that failed"
[10:58:56] <eludom> dc: I would like this not to be one of them.
[10:59:13] <eludom> dc: when it gets in trouble it changes what it's doing.
[10:59:28] <eludom> dc: you have lots of feedback that its not working.
[10:59:47] <eludom> dc: People are asking for a descrition of requriemnts and benefits
[11:00:02] <eludom> dc: you're being asked how this is different than previous work.
[11:00:19] <eludom> dc: You need to adapt the agenda
[11:00:37] <eludom> pause
[11:01:34] <marcos.sanz> Robert Morgan speaking
[11:01:40] <jlcjohn> (The speaker is mumbling!)
[11:01:43] <eludom> Part of the reason for bringing this to the IETF was to ?get input? from people working on disparet things
[11:02:04] <nsb> Bob is soft spoken, he's not mumbling.
[11:02:34] <eludom> er: There are 3 ways systems can fail
[11:02:39] <eludom> 1. Do nothing useful
[11:02:41] <jlcjohn> (Yes he is! BTW, the audio gain in the room is too high...)
[11:02:52] <eludom> 2. Be flawed architecturally
[11:02:55] <eludom> 3. Bungled implementation
[11:03:40] <eludom> Dick Hart:
[11:03:41] <marcos.sanz> Dick Hardt is now speaking
[11:03:50] <eludom> see requirements adoptoin
[11:03:55] <eludom> er: that's a result
[11:04:19] <eludom> er: that's like saying the patient died. Why?
[11:04:23] --- sandro has left
[11:04:43] <eludom> dh: answers el: We're not seeing DIX as SSO, but a way to move digital idenity
[11:05:07] <eludom> dh: in email you have few accounts, on web you have many
[11:05:21] <hartmans> People should consider that sometimes sysetms fail because of politics, personalities, etc. Sometimes reinventing the wheel is the right solution simply because you will have different layer 8 and 9 issues.
[11:05:24] <eludom> dh: in Web 2.0 moving things about yourself is a problem
[11:05:28] <eludom> Jeff:
[11:06:01] <eludom> j: Some prior work is widely adopted in specific communities (Dick just claimed that)
[11:06:37] <eludom> j: Liberty looking at 1Billion devices ?in next year?. That's good adoption
[11:06:53] <eludom> j: SAML has good adotpion
[11:07:33] <eludom> j: deployment and adoption has a huge ammount to do with politics and sociology, not tech
[11:08:18] <marcos.sanz> R. Shockey speaking (and now: that is the correct spelling)
[11:08:47] <hsantos> anyone else following the audio feed? is it a bit low for you as well?
[11:08:49] <marcos.sanz> P. Hallam-Baker speaking
[11:09:36] <eludom> phb: we need to get to a concrete set of requiremnts, distribute to SAML, inforcard, higgens, etc, ask them how they meet those reqs
[11:09:57] <eludom> phb: will know what delta is
[11:10:05] <eludom> answer: good idea
[11:10:18] --- ShoichiSakane has joined
[11:12:09] <marcos.sanz> (I didn't get the name of the speaker and he's not wearing a badge)
[11:12:13] <eludom> Curt ?: searched, found 6+- solutions in this space, which should I use ? None until there is consolidation
[11:12:18] <nsb> Kurt Zeiliga of IBM is speaking
[11:12:38] <nsb> excuse me, Zeilenga
[11:12:41] <marcos.sanz> (of IBM? he's wearing an openLDAP t-shirt)
[11:12:49] --- JeffH has joined
[11:12:49] <nsb> Yes, he's from IBM, but he's also Mr. LDAP.
[11:12:59] <leifj> ibm is paying for openldap
[11:13:09] <eludom> ? Blumenthal: The world does not need a protocol to MOVE id, but need to know what it is
[11:13:12] <marcos.sanz> Uri Blumenthal speaking
[11:13:45] --- kent has left: Disconnected
[11:13:57] <eludom> answer: that's not what we're defining. We're moving things.
[11:14:29] <eludom> ub: protocol for transporting is irrelevent.
[11:14:44] <eludom> er: bring up problem statmenet please
[11:15:12] <marcos.sanz> Scott is closing the mic line to focus back on the agenda
[11:15:23] --- jeffmc930@gmail.com has left: Logged out
[11:15:26] <Hollenbeck> ..to refocus the agenda, that is.
[11:15:36] <kdz> For the record: While IBM is my current benefactor, here in the IETF I represent the OpenLDAP Foundation.
[11:16:54] <leifj> ldap is an interesting analogy to the current discussion
[11:16:55] <eludom> er: you are missing the notion that you like to assert claims to someone with no prior relationship
[11:17:23] <leifj> ldap started out with "this DAP (x500) stuff is way to complicated"
[11:17:27] <eludom> er: 2. you want to have replying party be confident in those claims
[11:17:42] <eludom> er: 3. individuall assertable
[11:17:52] <leifj> and now is at "if we had only stayed with X500 we'd be much happier today"
[11:18:00] <leifj> complexity isn't a vice
[11:18:33] <eludom> er: 4. claims with connection to real world.
[11:18:59] <eludom> er: I'm not getting that from this text
[11:19:37] <eludom> er: ercap
[11:19:41] <eludom> er: recap
[11:19:54] <eludom> er: 1. Make claims to people wihth no reelations
[11:19:58] <eludom> 2. Relying party trust claims
[11:20:22] <eludom> 3. claims to be ... real world
[11:20:30] <eludom> 4. Individually assertable
[11:20:50] <eludom> aswer: we drew line lower than 3ed party claims
[11:21:12] <lisaDusseault@jabber.psg.com> Number 3 is "there are two kinds of claims, those which have a real-world existence (e.g. over 21) and those which are merely self-assertable (e.g. this agent has the identity ekr@rtfm.com)".
[11:21:13] <eludom> sh: clarify "3ed party claim"
[11:21:29] <kdz> [in reply to leifj complexity comment] over simplicification is a vice
[11:21:45] <leifj> right - make it as simple as possible but no simpler
[11:21:50] --- Eliot.Lear has joined
[11:21:52] <eludom> sh: what is a 3ed party claim in your mind
[11:22:06] <eludom> answer: a service that makes a claim about you, performs some process
[11:23:40] <eludom> sh: if 3ed party claims are out of scope....what purpose does the id provide ?
[11:23:49] <eludom> clarification: identity agent
[11:24:14] <eludom> sh: does the server ever care if the agant is sitting on the client"
[11:24:16] <eludom> no
[11:24:32] <eludom> the trust is between the person creating the claim and the person consuming it
[11:25:01] <eludom> the trust is not with the person who stores the claim
[11:25:11] <eludom> sh: the relying party can not get at that distinctoin
[11:25:13] --- peterd has joined
[11:25:37] <eludom> goals of dix: automate providing data
[11:27:54] <eludom> Chair: cutting off line. Let's focus on "what is unique here". Let's not rathole on 3ed party claims
[11:28:06] --- trond has joined
[11:28:59] <marcos.sanz> ekr: I don't understand why 3rd pary claims shouldn't be in scope
[11:29:29] <eludom> sh: I think we can move on to uniqueness discussion.
[11:30:00] <eludom> sh: does anyone think that er's list is unique ?
[11:30:10] <eludom> ...the line forms on the right...
[11:30:47] --- JeffMc has joined
[11:31:17] <eludom> sh: er's list was an attempt to tell you what he thought you were doing
[11:31:30] <eludom> phb: Whats missing is a uniform ID
[11:32:16] <eludom> phb: what is in scope to design and build....3ed party claims exist x.509, SAML
[11:32:51] <marcos.sanz> phb: we don't need a third third party claim
[11:33:06] <eludom> phb: how do you know that what everyone is talking about is the same ?
[11:33:08] <kdz> Sam noted that he thought DIX may have complexity not necessary in absence of a requirement to support 3rd party claims
[11:33:29] <marcos.sanz> Love Hornquist Astrand speaking
[11:33:35] <mrichardson> "glom" is a well-defined technical term. It's a process that occurs on the back of napkins at IETF bars.
[11:34:17] <eludom> Jeff Hodges: There is prior work, OASIS estensible resources (XRI)
[11:34:39] <marcos.sanz> Uri B. speaking
[11:34:42] <eludom> ub: specify your expected deployment scope
[11:35:25] <eludom> char: is that what would make it unique ?
[11:35:39] <eludom> ub: no that is what would make it >useful<
[11:36:09] <eludom> Lisa D: if this is internet scope, that should be big enough
[11:36:16] <eludom> ub: we have to agree on what identity is.
[11:36:31] <lisaDusseault@jabber.psg.com> Also I believe that "internet scope" is the consensus here.
[11:37:06] <eludom> Ben Lauri: Claims have to be unlinkable.
[11:37:21] --- Glenn Parsons has left
[11:37:28] <marcos.sanz> (B. Laurie: please wear the badge!)
[11:37:42] <marcos.sanz> Jim Fenton speaking
[11:37:45] <eludom> Jim Fenton: Federated scheme, can 2 clients ?talk?
[11:38:01] <eludom> your second point was on privacy
[11:38:11] <eludom> I think you can build anonymity with this
[11:38:29] <marcos.sanz> M. Richardson speaking
[11:38:30] <eludom> Michael Richerdson: SPKI 10 years ago
[11:39:00] <eludom> mr: Prior to XML, XMLSIG duplicates a lot of it
[11:39:42] <eludom> mr: this was supposed to reduce the burdon on casual web site designers
[11:40:10] <eludom> mr: Authentication burdon was too high.
[11:40:21] <eludom> mr: systems don't scale (X.509).
[11:40:33] --- lixia has joined
[11:40:33] <eludom> mr: work well for Millions, not casual 1-1
[11:40:35] --- hallam has joined
[11:40:56] --- kent has joined
[11:42:19] --- stephenfarr has left
[11:43:03] <robsiemb> what did sam say there?
[11:43:06] --- JeffMc has left: Logged out
[11:43:38] <eludom> el: Clairificatoin: is the solution predicated on a unique user ID ?
[11:43:58] <eludom> answer: we need a unique ID for user
[11:44:01] <eludom> el: why ?
[11:44:11] <Hollenbeck> sam said that there may be work to do, even if what we're talking about here isn't completely unique
[11:44:26] <eludom> so that the service knows which user
[11:44:29] --- inet6num@jabber.org has left: Replaced by new connection
[11:44:45] --- trond has left
[11:45:13] <eludom> ex: I go to lots of gambling sites. I need to prove to them all that I'm a heavy gambler.
[11:45:23] --- jis has left: Logged out
[11:45:34] <eludom> el: Liberty aliance does not do that ?
[11:46:10] <eludom> JH: one does not need to have a publicly unique id to get the propertys, preserve privacy. You can have all this using conditional cryptography.
[11:46:14] <eludom> dc: 3 tasks
[11:46:26] <eludom> dc: 1 statement of problem, nature of soution, crisp, tight.
[11:46:50] <eludom> dc: 2. Need a matrix of prior work.
[11:47:10] <eludom> dc: compare functionality, develop effort, deploy effort, op effort, usablity
[11:47:15] <JeffH> no, a subtle-but-important issue is that one is NOTgoing to get *strong* privacy across all parties if one uses "conventional crypto"
[11:47:29] <eludom> characterize how DIX is better than X on any or all
[11:47:35] <JeffH> that's what Ben Laurie's point was
[11:47:37] <eludom> dc: 3. usage schenereos
[11:48:11] <eludom> dc: Comment about scaleing is crutial. Things good at enterpise level do not always scale to internet.
[11:48:24] <marcos.sanz> Lisa Dusseault speaking
[11:48:40] <marcos.sanz> (please state the name at the mike)
[11:49:03] <eludom> LD: Jeff said you don't need a unique ID...I don't understand
[11:49:24] <eludom> LD: Several people want HTTP to have a way that does not reply on forms, post, etc.
[11:49:32] <JeffH> my point prior to that was that if one uses a unique identifier across parties, one is going to have privacy issues, and other efforts have acknowledged this and figured out how to get the identification properties that DickH desires *without* linkable unique identifiers -- i.e. provides at least some better privacy
[11:49:40] <leifj> shibloleth for instance use session-unique id's
[11:49:49] <leifj> (saml-based)
[11:49:54] <marcos.sanz> Halla
[11:49:55] <Rob Yates> yeh, we need http only for feed readers
[11:49:57] --- trond has joined
[11:49:59] <marcos.sanz> Hallam-Baker speaking
[11:50:09] --- rowan0 has left
[11:50:31] <lisaDusseault@jabber.psg.com> But if Shibboleth uses session-unique IDs, how do I prove to your blog site that I'm the owner of my blog when I leave a comment on your site?
[11:50:35] <eludom> phb: "I get worried when people say you need PGP, rather than you need private email"
[11:50:52] <lisaDusseault@jabber.psg.com> An identifier could always be unique for a session but it shouldn't be required to be, is my best current understanding
[11:50:55] <Rob Yates> feed readers are becoming increasingly important. I do not think that DIX can rule out "rich clients"
[11:51:07] <eludom> phb: Blogs provide a good use case.
[11:51:23] <leifj> because your blog-site is allowed to fetch one of my identities (the one I choose to show to blog-sites) using the handle
[11:51:29] --- nov has left
[11:51:33] <marcos.sanz> D. Hardt speaking
[11:51:49] <eludom> Dick Hart: Liberty pair-wise IDs good innovatoin. Works well in federated model with explicit trust
[11:52:02] <peterd> well, blogs can assert you have editorial control over content published there, does not require 'persistant' identifiers (aside from blog URI of course)
[11:52:03] <eludom> dh: Does not scale to internet. Not everyboy can trust everyboy.
[11:52:42] <eludom> dh: Liberty model has lots of privacy disadvantes (one central idenety server)
[11:53:05] <peterd> not necessarily. thats a deployment decision
[11:54:16] <marcos.sanz> The chairs have so far collected following points in a slide about "DIX -Uniqueness?": a) Unified approach to self and authority stated claims b) Portable Unique Identifier for User c) Simple and easy to adopt/deply d) P2P exchange of ID information e) Privacy ... F) Use case: blogosphere. Not satisfied by exsiting technology? g) Internet scale for trust.
[11:54:24] <eludom> jh: lost of this is implementatoin details. Pairwise IDs can be hidden. You can give good user experience.
[11:54:43] <eludom> On screen:
[11:54:57] <eludom> * Unified approach to self and authority stated claims (bob)
[11:55:07] <eludom> * Protable Unique ID for user (Phil/Dick)
[11:55:11] <leifj> as in many cases the availability of tools and implementations mean more than the relative complexity of solutions
[11:55:19] <eludom> * Simple and easy to deply/adopt (Love)
[11:55:24] --- yushun has joined
[11:55:31] <eludom> * P2P exchange of id info (?)
[11:55:35] <eludom> * Privacy
[11:55:55] <eludom> * Use Case: Blogosphere. Not satisfied by currrent tech ?
[11:55:58] <marcos.sanz> Scott: Is there agreement on these points?
[11:56:04] <eludom> * Internet scale for trust
[11:57:01] <eludom> LD: Ned for portable identifiers users. Not unique. e.g. yahoo, work.
[11:57:14] --- lixia has left
[11:57:16] --- dumdidum has left
[11:57:20] <eludom> LD: I may want to buy gold coins and never have that ID correlated.
[11:57:46] <eludom> phb: Lisa saying many-to-one mapping, under user control
[11:58:55] --- lixia has joined
[11:59:21] --- muonzoo has joined
[11:59:26] <marcos.sanz> b) Has been reweritten from "Portable Unique ID" to "Multiple Portable Unique ID"
[11:59:47] --- nov has joined
[12:01:02] <marcos.sanz> That was P.Faltstrom speaking
[12:01:40] <eludom> chair: need to come up with conglomerate of things that create a unique problem
[12:02:14] --- Adam has joined
[12:02:31] <eludom> phb: concern with XRI WG. "Have hammer. Will find nail"
[12:02:52] <eludom> sh: I agree with phil.
[12:03:22] <eludom> sh: I don't care if it's unique if it will be used/solve problems.
[12:04:01] <eludom> uh: Not a question of uniqueness. But why will THIS one succeed.
[12:04:13] <eludom> dc: I agree with Sam.
[12:04:30] <eludom> dc: This is an exercise to figure out why this will succeed.
[12:04:41] <marcos.sanz> s/uh/Uri Blumenthal/
[12:05:25] <eludom> phb: portable IDs have to be user oriented, not strings of bits, not tied to one machine
[12:05:40] <eludom> phb: very easy to use PKI bound to device, but what if you have 6 ?
[12:05:57] <marcos.sanz> b) Has been reweritten from "multiple portable unique ID" to "friendly multiple portable unique ID"
[12:06:16] --- JeffMc has joined
[12:06:32] <peterd> pbh points out one of the favorable properties of XRI, BTW
[12:06:43] <marcos.sanz> That was paf speaking
[12:07:03] <eludom> chair: we are not going to get back to agenda. What's best use of time ?
[12:07:08] --- bew has joined
[12:07:45] <eludom> LD: getting sense of room/consensus would be useful
[12:08:54] <eludom> SH: I believe that the protocol is way over done given this problem statement.
[12:09:46] <Hollenbeck> SH -> Sam Hartman
[12:09:56] --- brabson has left
[12:10:08] <eludom> sh: I'm lost.
[12:11:37] <eludom> EL: I need a way for my Dad to be able to access securely multiple websites without having passwords all over the place
[12:11:50] <eludom> EL: Don't care about usernames, just passwords
[12:11:54] <marcos.sanz> The chairs are collecting consensus points in a slide. So far we have a) Elliot's Dad: Multiple sites, multiple passwords.
[12:12:40] <eludom> sense of room: we have something to do ? Loud humm.
[12:13:03] <eludom> sense of room: shoud we solve Eliotts dads problem ?
[12:13:25] <tianlinyi> u
[12:13:25] <tianlinyi> u
[12:13:36] <peterd> that does set the bar to >internet scale<
[12:13:57] --- elwynd has left
[12:13:58] --- elwynd has joined
[12:14:08] <marcos.sanz> Yet another consensus point in the slide: b) The BoF shouldn't go away
[12:14:27] <tianlinyi> shouldn't? should?
[12:15:07] <marcos.sanz> Actually, the slide says "should" but the humming in the room was for "shouldn't go away"!
[12:15:28] --- Adam has left
[12:16:04] <marcos.sanz> @tianliny: That has just been corrected in the slide, thanks.
[12:16:30] --- bew has left
[12:16:46] <eludom> New consensus point:
[12:17:37] <eludom> Reuse existing technology, where appropriate ?
[12:18:20] <eludom> phb: We need a set of reqs defining needs of blogosphere
[12:18:39] <eludom> phb: IETF has atom, http..most obvious place to do it
[12:19:44] <marcos.sanz> 4th consensus point in the slide: "Write requirements of blogosphere use case?"
[12:20:23] <JeffH> the "reuse existing tchnology" point was made by me.
[12:20:26] <eludom> el: minimize dependacies
[12:20:28] --- resnick has left
[12:20:37] <JeffH> who is eludom?
[12:20:41] <eludom> Steven Yount: I want to be able to tell elliots dad to go away and not come back
[12:20:53] <marcos.sanz> 5th: "Minimize dependent thir d parties?"
[12:21:00] <eludom> SY: How do I stop him from just creating another identity and coming back
[12:21:14] <eludom> dc: ED protocol, for Eliotts Dad
[12:21:34] <eludom> dc: Propose 3-5 use cases that current tech does not solve
[12:21:45] <marcos.sanz> 6th: Know who the user is?
[12:21:51] <eludom> dc: this will give us a good idea what to do
[12:22:13] <eludom> phb: minimize out of pocket deployment cost. See EDI.
[12:22:41] <marcos.sanz> 5th is rewritten to "E: Minimize dependent third parties. PHB: Deployment costs"
[12:22:56] <peterd> what do we _really_ need to know wrt ED? open question, IMHO
[12:22:57] --- dcrocker has left
[12:23:29] <marcos.sanz> M. Richardson speaking
[12:23:39] --- yushun has left
[12:24:13] <eludom> Michael Richardson: all solutions tend towards same solution on back end.
[12:24:23] <eludom> MR: problem is that there is no front end standard
[12:24:39] <eludom> MR: Probably no >well know< front end standard
[12:24:49] --- nov has left
[12:25:22] <eludom> EL: would like to add to list
[12:25:32] <eludom> EL: accomodate (not require) hardware authenticators
[12:25:35] --- hartmans has left
[12:25:45] <marcos.sanz> The consensus slide so far looks like: a) BOF should go away - No b) ED's problem: Multiple sites, multiple passwords. (PF: Restated as an Identifier problem?) - Yes c) Know who the user is? d) JH: Reusing existing technology, where appropriate? e) E: Minimize dependent 3rd parties. PHB: Deployment costs f) PHB: Write requirements of Blogosphere Use Case?
[12:26:29] --- lixia has left
[12:27:07] --- nsb has left
[12:27:25] <eludom> Back to consensus slide
[12:27:47] <eludom> adding: 3-5 Use Cass, not addressed by other tech.
[12:27:55] <eludom> impending humms...
[12:28:26] <eludom> Are there people who believe there is 0 work ?
[12:28:29] <eludom> silence.
[12:28:39] --- kdz has left
[12:28:49] <marcos.sanz> Wolfgang Steigerwald speaking
[12:29:13] --- Eliot.Lear has left
[12:29:30] <peterd> there is, perhaps, at a minimum clarifications/profiling of existing material required
[12:30:16] --- alfredo.matos has left
[12:30:40] <eludom> Does the proposal fail to reuse existing tech
[12:30:41] --- pawal has left
[12:30:52] <eludom> hums about equal
[12:31:01] <marcos.sanz> My personal guess is that people haven't read the drafts yet
[12:31:09] --- Barry Leiba has left
[12:31:20] --- mcfadden has left
[12:31:40] <eludom> More work on requirements and use cases?
[12:31:47] <eludom> loud humm. No opposed.
[12:32:09] <eludom> LD: askes for for people to work on it. Several hands go up.
[12:32:15] <Rob Yates> i will work on use cases
[12:32:21] --- fenton has left
[12:32:29] <peterd> uses cases precede requirements
[12:32:39] --- alexeymelnikov has left
[12:32:40] <eludom> Chair: clearly not enough consensus for WG charter, but do have some directoin.
[12:33:02] <eludom> we do have some problems agreed upon, need to take discussions back to list.
[12:33:13] --- NFreed@jabber.org has joined
[12:33:38] --- hallam has left
[12:33:40] --- trond has left
[12:33:41] --- NFreed@jabber.org has left: Logged out
[12:33:53] <eludom> chair: more work needed before Montreal. 2 BOF limit.
[12:34:14] <eludom> going once....
[12:34:22] --- JeffH has left
[12:34:23] <eludom> done.
[12:34:27] --- rlbob has left
[12:34:28] --- lisaDusseault@jabber.psg.com has left: Logged out
[12:34:32] --- Hollenbeck has left
[12:34:33] --- ludomp has left
[12:34:33] --- eludom has left
[12:34:46] --- Rob Yates has left
[12:34:50] --- Jeffrey Altman has left
[12:34:59] --- agallant has left
[12:35:08] --- leifj has left
[12:35:18] --- jas has left
[12:36:01] --- ShoichiSakane has left
[12:36:25] --- hsantos has left
[12:39:51] --- psangster has left
[12:44:04] --- JeffMc has left: Logged out
[12:44:38] --- muonzoo has left: Logged out
[12:44:41] --- peterd has left
[12:51:28] --- robsiemb has left
[12:51:55] --- tianlinyi has left
[12:52:23] --- marcos.sanz has left
[12:52:31] --- bhoeneis has left
[12:53:44] --- pk has left
[12:56:48] --- elwynd has left
[12:57:12] --- kent has left: Disconnected
[12:58:59] --- dick.hardt has left
[13:07:26] --- cabo--tzi--org@jabber.org has left: Logged out
[13:08:42] --- elwynd has joined
[13:20:31] --- jlcjohn has left
[13:20:56] --- stephenfarr has joined
[13:22:38] --- stephenfarr has left
[13:30:19] --- elwynd has left
[13:39:18] --- kdz has joined
[13:44:26] --- kdz has left
[13:50:46] --- nico has joined
[13:59:02] --- pk has joined
[13:59:05] --- pk has left
[14:04:38] --- elwynd has joined
[14:07:06] --- dcrocker has joined
[14:08:07] --- dumdidum has joined
[14:10:04] --- JeffH has joined
[14:10:16] --- JeffH has left
[14:14:24] --- dcrocker has left
[14:21:00] --- dumdidum has left: Replaced by new connection
[14:34:13] --- Dave Cridland has joined
[14:41:54] --- alexeymelnikov has joined
[14:44:59] --- dcrocker has joined
[14:47:57] --- alexeymelnikov has left
[14:52:42] --- alexeymelnikov has joined
[14:55:43] --- Dave Cridland has left
[15:11:17] --- alexeymelnikov has left
[15:46:16] --- nico has left
[16:16:53] --- dcrocker has left
[16:24:58] --- elwynd has left: Replaced by new connection
[16:24:59] --- elwynd has joined
[16:41:22] --- dcrocker has joined
[16:42:13] --- tlr has left
[16:43:42] --- dcrocker has left
[17:19:03] --- DanC has left
[18:39:32] --- elwynd has left: Replaced by new connection
[18:40:37] --- elwynd has joined
[20:17:18] --- mrichardson has left
[20:18:55] --- elwynd has left