[19:15:02] matt joins the room [19:15:02] Chatroom configuration modified [19:15:07] Barry Leiba joins the room [19:15:31] PHB joins the room [19:15:58] Richard L. Barnes joins the room [19:16:02] Eran Hammer-lahav joins the room [19:16:10] yaron.sheffer joins the room [19:16:58] hartmans@jis.mit.edu/owl joins the room [19:17:22] jhildebrand joins the room [19:17:25] glen joins the room [19:17:58] Lisa joins the room [19:18:08] Blaine Cook joins the room [19:18:32] Doug Otis joins the room [19:19:03] sftcd joins the room [19:19:28] ludovic.poitou joins the room [19:19:41] Ted joins the room [19:19:51] Mark Nottingham joins the room [19:20:14] Moving scribing here [19:20:15] Question from ekr: is the second one the same as the standard web authentication problem? Answer: yes. Who is using oath? 17 listed Run through of 3 legged contact import [19:20:24] Mark Nottingham leaves the room [19:20:24] Blaine Cook leaves the room [19:20:26] Barry Leiba leaves the room [19:20:26] Going through friend feed as the contact import [19:20:31] sal joins the room [19:20:39] glen leaves the room [19:20:42] stpeter joins the room [19:21:04] resnick joins the room [19:21:07] cyrus joins the room [19:21:07] Barry Leiba joins the room [19:21:09] Randall Gellens joins the room [19:21:09] Now running through 2 legged public search [19:21:11] cabo joins the room [19:21:12] tonyhansen joins the room [19:21:17] bhoeneis joins the room [19:21:21] aaronstone joins the room [19:21:24] rlbob joins the room [19:21:24] SE-STEFANS-TTV joins the room [19:21:25] yaron.sheffer leaves the room [19:21:27] =JeffH joins the room [19:21:29] Showing yahoo's search api [19:21:31] lebobits joins the room [19:21:33] SE-STEFANS-TTV leaves the room [19:21:33] matt leaves the room [19:21:33] cyrus leaves the room [19:21:34] Melinda joins the room [19:21:36] marcos joins the room [19:21:43] stefans joins the room [19:21:47] vstirbu joins the room [19:22:03] cyrus joins the room [19:22:04] Walking through how a developer you might interact with oauth, showing Yahoo/developer interaction [19:22:23] this is the "two-legged" scenario [19:22:25] ldondeti joins the room [19:22:37] They issue credentials to the developer in this scenario [19:22:53] PHB leaves the room [19:23:02] Clarification questions from the chat? [19:23:13] PHB joins the room [19:23:13] seeking to learn: Doesn't SAML already do this for us? [19:23:22] Chris Newman joins the room [19:23:23] Shall I reflect to the mic? [19:23:34] no, I'm here in room [19:23:38] okay [19:23:38] Blaine Cook joins the room [19:23:40] lebobits: the problem is all in the user interface [19:23:42] I just wanted to know from the jabber folk [19:23:44] mcharlesr joins the room [19:23:45] jonas joins the room [19:23:47] yaron.sheffer joins the room [19:23:49] Eric Rescorla joins the room [19:23:57] For anyone remote, please put at the front to get it repeated in the room. Thanks [19:24:00] no, SAML per se does not address the delegation case [19:24:13] so, ought we fix the user interface? [19:24:14] Is this an area of interest? [19:24:17] lhalff joins the room [19:24:18] for SAML that is [19:24:22] I couldn't join this room with my ecotroph.net account, only my gmail. [19:24:26] First comments, then early hum [19:24:42] PHB at the mic; he is interested in this problem from SAML, WS*, etc. [19:24:53] The critical issue from his perspective is user interface [19:25:05] Working out how the user understands what they were doing. [19:25:17] slowhog joins the room [19:25:19] there are Liberty specs that use SAML to support delegation [19:25:24] He notes he did not understand what was going from the ui [19:25:33] Mark Nottingham joins the room [19:25:36] vidya joins the room [19:25:36] chris_griffiths joins the room [19:25:37] Summary: we should not take this on unless we tackle the UI problem. [19:25:57] EKR: this is a system not a protocol. Some of these replicate things IETF has done, perhaps badly [19:26:08] Two things: one is a method for granting delegated access to content [19:26:49] The other is a set of technologies for doing user authentication mechanisms. [19:26:55] He believes the first is interesting [19:27:07] The second is not coupled to the first necessarily [19:27:15] frumioj joins the room [19:27:41] Mark and Sam are trying to ask the question "Is there IETF interest in the first?" Sam clarifies that of those two, they are asking about the first, and ekr is interested in teh first. [19:27:49] Hannes says he believes that this is an important problem. [19:28:09] It comes up more and more,and there is some work that has to been (though much has already been done) [19:28:25] Mic line is currently 5 long, if folks are thinking of piping up questions [19:28:45] Ted: now 7 [19:28:49] Hannes is interested in getting UI folks interested in this area plus others. [19:29:02] Hannes does not believe that UI should be blocking [19:29:05] The document says: "An example use case is allowing printing service printer.example.com (the Consumer), to access private photos stored on photos.example.net (the Service Provider) without requiring Users to provide their photos.example.net credentials to printer.example.com." . I'm not aware of any other protocols that permit this. I don't see how openid, etc. handles this. PHB suggested that this has been done already, just badly. [19:29:13] Dave Crocker: thanks for the summaries. [19:29:22] Dave Crocker: vigorous yes. [19:29:51] He also believes that having UI folks look at this is separate expertise and separate standards work. [19:30:07] vstirbu leaves the room [19:30:13] +1 to separation of UI from protocol work -- we're not experts on that! [19:30:23] can someone clarify, at least in jabber why SAML doesn't already do this, OR just tell me "everyone else already gets why, and I'll explain it to you offline." [19:30:25] Leif also supports this work, and he believes the oauth group could teach the IETF work here [19:30:40] I'm not tring to suggest that our existing HTTP auth mechanisms do or don't suck. [19:30:46] I just think that's a bigger question. [19:30:48] Jeff Hodges gives a yes to work and that UI is separable [19:30:51] RLBob +1 [19:31:02] lebobits: are you in Minneapolis? [19:31:03] Adds that higher ed. is seeing more and more of a need here. [19:31:25] lebobits: if not I can relay your question [19:31:37] his sector needs this to have a good security review and well integrated into larger architecture [19:31:42] ludovic.poitou leaves the room [19:31:47] yeah, I'm in room [19:31:49] mcharlesr is mcr@sandelman.ca, and is not in MNP. [19:32:02] Vlad Stirbu joins the room [19:32:04] but, I still want to know the answer to lebobits' question. [19:32:05] mcharlesr: ok we can relay questions if needed [19:32:06] just don't want to bother mic if everyone already knows this answers [19:32:10] So, SAML *is* advertised as being able to do this. [19:32:13] ahhh... there we go [19:32:25] Joe Hildebrand believes HTTP auth's use of this may not be the only use case: xmpp might have [19:32:27] Though of course SAML is hugely more complicated/powerful/baroque, whatever [19:32:49] The question of whether this already exists is deferred to later. [19:32:55] EKR: wasn't when we started [19:33:02] Ted: just to elaborate on that, there are XMPP systems that are using OAuth now. [19:33:04] ekr: baroque is good :) [19:33:06] EKR: we could roll back to 1.0 [19:33:08] ludovic.poitou joins the room [19:33:33] Methods like OpenID desperately need cryptographic solutions to avoid phishing. This type of work is needed. Humm [19:33:35] I'm going to start a new protocol called shibboml [19:33:42] I take that as consensus [19:33:42] The chairs of the BoF call consensus that there appears to be sufficient interest for working in this area; strong hum for, and no opposed [19:34:08] PHB: the thing that most people seem to object to in SAML is that it is XML-based, and it has been that way from the beginning [19:34:08] Eran is no going up to describe the current oauth protocol [19:34:17] excuse me oauth_protocol [19:34:42] rlbob: XMPP is XML-based too, as are many other technologies we use at the IETF (PIDF etc.) [19:34:57] So, I'm not taking a position on SAML, etc. [19:35:00] Jim Fenton joins the room [19:35:07] I'm just trying to answer lebos question. [19:35:13] Asks for show of hands for having read the spec; about half (speaker at front said two-thirds) [19:35:17] re: SAML: I've had some SAML experts go through the delegated model with me in the past. Most of it went over my otherwise network layer focused head, but I did walk away with a strong sense that there were VERY clear mechanisms and implementations for SAML to do this [19:35:26] do others see it differently? [19:35:28] eronenp joins the room [19:35:34] http://oauth.googlegroups.com/web/OAuth_IETF_Protocol_Presentation.ppt [19:35:36] Oauth defines 3 roles: service provider, consumer, user. [19:35:41] Let's see what happens with that discussion later. [19:35:54] Resource is owned by user, held by the service provider, and the consumer would like to access it. [19:36:19] just in case anyone is confused about Shibboleth: it is a piece of software that is primarily an implementation of SAML, it is also an implementation of other standard web signon protocols, it is not in any way its own protocol [19:36:24] ping [19:36:31] We're trying to avoid the user giving the credentials she uses to talk to the service provider directly to the consumer [19:36:47] going through workflow now: consumer gets a request token [19:37:08] Ekr points out that the chairs didn't state ground rules for questions. Same as previous presentation [19:37:16] redirect user to authorize request token [19:37:32] user grants the authorization, then redirected by to the consumer [19:37:43] This would be a lot better with some arrows [19:37:47] Just saying [19:37:53] I even sent these guys a ladder diagram [19:37:55] this would be better in a font 3 sizes larger [19:38:01] lebobits leaves the room [19:38:01] lebobits joins the room [19:38:10] Ted: yeah [19:38:26] Larger font AND not light grey. [19:38:28] the consumer trades the request token for an access token [19:38:46] <=JeffH> oauth protocol flow diagram is here: [19:38:49] <=JeffH> http://groups.google.com/group/oauth/tree/browse_frm/month/2008-11/4de93deaeb53a264?rnum=51&_done=%2Fgroup%2Foauth%2Fbrowse_frm%2Fmonth%2F2008-11%3F#doc_bf41f2608db9f6bc [19:38:49] Eric: the ladder diagram was great, thank you! :-) [19:38:58] out-of band configuration [19:39:24] Consumer credentials terminology can be confusing: consumer key is just an identifier [19:39:42] Please for the love of god stop saying "signature" my head assplodes whenever I see this... [19:40:15] And I'm all out of duct tape to put it back together [19:40:27] <=JeffH> i have some around here somewheres.... [19:40:30] It is a term of art in their spec. . . I agree that changing to a term that did not conflict for the rest of the universe would be good long term. but I'd rather them be consistent with their document at least until it changes. [19:40:32] oauth endpoints are described; these seem to the interfaces on the various servers [19:40:50] (HTTP interfaces, in particular) [19:41:03] hartmans@jis.mit.edu/owl loves the plaintext "signature" method [19:41:05] Notes that learning where to go is currently out of scope, though there is a proposal in the wings [19:41:32] Shows a 401 challenge [19:41:41] Well, I guess. This protocol lives within the broader space of COMSEC, where signature is already a term of art [19:41:43] <=JeffH> for prot flow diagrams, here is shorter URI: http://identitymeme.org/archives/2008/10/22/oauth-protocol-flow-diagrams/ [19:41:55] marcos claps at Ted [19:42:04] And I don't think it's being Hugo to point that out [19:42:15] What slide are they on? [19:42:16] Hugo? [19:42:34] ekr: agreed. I agree they should fix it. [19:42:41] <=JeffH> oauth-proto.pdf slide 3 of 6 [19:42:45] Hugo Krawczyk [19:42:49] ah [19:42:50] Resident IETF cryptographer and pedant [19:42:51] Showing some of the elements in the auth request; showing the elements in the Authorization header [19:43:03] Jeff: are these already up? [19:43:04] Just sent me a long letter explaining how I shouldn't use the term "Extractor" in a document because it's a crypto term of art [19:43:08] When I checked, I missed them [19:43:10] <=JeffH> ted: dunno [19:43:16] okay. [19:43:36] Signatures is constructed by signing most of the elements in the request [19:43:43] These presentations should be on the website. The next short one is not [19:43:50] Which shared secrets and how seems to vary by method [19:43:58] thanks, sam, I will check again. [19:43:59] Mark Nottingham leaves the room [19:44:01] http://oauth.googlegroups.com/web/OAuth_IETF_Protocol_Presentation.ppt [19:44:35] By 'consider the UI, I think I mean, produce a complete spec' [19:44:40] <=JeffH> now on oauth-proto.pdf slide 4 of 6 [19:44:45] Too many pieces of information to configure here [19:44:59] you'll note that this HMAC SHA-1 signature is more or oless isomorphic to RFC 2617 Digest [19:45:01] how does a user get their mind round it [19:45:15] if they don't get their mind round it how have they agreed to anything? [19:45:30] If there is no user there is no delegated auth [19:45:33] lebobits leaves the room [19:45:33] lebobits joins the room [19:45:34] its just auth [19:45:41] GET /oauth/request HTTP/1.1 Host: photos.example.net Authorization: OAuth realm="http://photos.example.net/" oauth_consumer_key="dpf43f3p2l4k3l03" oauth_token="" oauth_nonce="t39ojf40pd9533jh" oauth_timestamp="1191242098" oauth_signature_method="HMAC-SHA1” oauth_signature="tTFyqivhutHiglPvmyilZlHm5Uk%3D" [19:45:53] reply contains [19:45:54] oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03 [19:46:06] The configuration is on a consumer, which is *not* a user, and can afford a fair bit of config, although probably not this much [19:46:22] yaron.sheffer leaves the room [19:46:23] Then the user is redirected [19:46:27] phb: users somehow understand today's UIs which permit getting to resource X from service Y, eg "import my contacts from gmail" [19:46:28] Mark Nottingham joins the room [19:46:44] It's very hard to work out (I spent a while trying) what each of the protocol elements in this system does. [19:46:47] so, it's not that different in flow to paying for something via paypal. [19:46:47] I assume this is in a 3XX message, but the slide just says: [19:46:48] http://photos.example.net/oauth/authorize?oauth_token=hh5s93j4hdidpola&oauth_callback=http%3A%2F%2Fconsumer.example.com%2Foauth%2Fready [19:46:53] for the redirect [19:47:10] As Joe Hildebrand says, it would be nice to have a system less closely coupled to HTTP [19:47:27] EKR: couple it to SSL instead [19:47:30] better [19:47:34] <=JeffH> ekr: yes, can layer it more cleanly [19:47:37] And less dependent upon redirects. [19:47:44] ekr: they have it working on XMPP: http://xmpp.org/extensions/xep-0235.html [19:47:46] ekr: makes sense; in another system, it might not be 3xx style request at all [19:48:02] The redirects really need to go away, but I don't see that happening in the near future. [19:48:14] kdz joins the room [19:48:16] Well, I think it's probably useful to think of the credentials granted to the consumer as being self-contained and as a distinct concept from the workflow required to get them. [19:48:18] kivinen joins the room [19:48:24] lellel joins the room [19:48:25] (Cf my review comments about delegation certificates) [19:48:26] The first best thing I see us working towards is the rebirth of HTTP 401 [19:48:26] Eran notes that this is not a smooth when redirects don'twork [19:48:30] the use case in XMPP is: peter authorizes me to join this chat room, where me, peter, and the room are on 3 different servers. [19:48:41] A pointer ahead: my slides are at: http://down.dsg.cs.tcd.ie/misc/bof-farrell.ppt [19:48:44] er, "not as smooth" [19:49:00] Going through the signature mechanism now [19:49:08] hta joins the room [19:49:24] It's also important to recognize that all this token shuffling is sort of confusing, since it's in some places a correlator and in others a state offload onto the client [19:49:24] GET /photos?size=original&file=vacation.jpg HTTP/1.1 Host: photos.example.net:80 Authorization: OAuth realm="http://photos.example.net/" oauth_consumer_key="dpf43f3p2l4k3l03" oauth_token="nnch734d00sl2jdk" oauth_nonce="kllo9940pd9333jh" oauth_timestamp="1191242096" oauth_signature_method="HMAC-SHA1" oauth_version="1.0" oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D" [19:49:33] (A la [SBR04] [19:49:39] GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal [19:49:42] post-facto [19:50:13] AGENDA Bash [19:50:31] Now a mobile use case for discussion [19:50:36] Stephen Farrell [19:50:38] spekaing [19:50:45] OAuth Developers: http://oauth.net/ Google Efforts: http://sites.google.com/site/oauthgoog/ [19:51:11] inaudible [19:51:23] better, thanx [19:51:30] Public keys on the auth server and encrypted private keys held by users can construct request exchanges without the use of redirection. [19:51:31] You can just restate that as "a lot of phones don't work well enough" [19:51:34] These redirects given in the last preso don't work on phones, or don't work well enough [19:51:50] eKR or as 'get n iphone [19:51:57] I believe the draft is http://tools.ietf.org/html/draft-dehora-farrell-oauth-accesstoken-creds-00 [19:52:12] (But I wasn't able to grab it from the slide, so this is secondary search) [19:52:18] NewBay Use case being presented now [19:52:36] Ted: that's what the slide says, yes [19:52:37] User Generated Content from phone to mobile to service provider [19:53:00] He would like to have a specific requirement to support mobile users with current devices [19:53:01] I have an iphone!!! [19:53:06] Thats what I meant by didn't work [19:53:14] Separate RFC that henadles the relevant use case [19:53:23] what it is about the phones that make redirects hard? [19:53:36] fix the phones [19:53:37] their HTTP stacks suck, and are hard to replace. [19:53:52] Java MIDP 1.0 is one of the problems. [19:53:54] certs hard to manage too [19:53:55] Richard L. Barnes leaves the room [19:54:01] mic: what are the restrictions on what the mobile phones can do? [19:54:01] bandwidth, latency for many mobile networks is not great [19:54:03] Also, my iphone keeps playing porn [19:54:05] if "current devices" are "iphones and androids", I'm all for it :-) [19:54:09] danbri joins the room [19:54:15] though that may be my fault [19:54:16] Are we talkingin here about making this protocol into a standard or looking at the problem it solves and doing the job right? [19:54:17] richard.barnes joins the room [19:54:26] EKR everything is your falt [19:54:35] danbri rediscovers life after IRC [19:54:36] phb: perhaps both, individually? [19:54:52] ekr: better keep that phone out of Darwin's hands [19:54:59] May need a strong applicability statement to mobiles [19:55:02] keeping in mind that the user base for this protocol is not uninteresting. [19:55:13] s/this protocol/existing oauth/ [19:55:52] BTW, http://xmpp.org/extensions/xep-0235.html defines a use of OAuth over XMPP [19:55:53] jhildebrand: can't see it likely that what comes out is compatible [19:56:19] Randy Gellens at the mic; ask for clarification whether the user will ever need to change (consumer and service provider take the burden of change, Sam answers) [19:56:29] phb: well, it seems like backwards-compatibility should be a goal, until proved impossible. [19:56:36] Review's eye chart, which he claims is a charter [19:56:45] er, Mark reviews [19:57:13] Charter text being reviewed. [19:58:17] The charter says that there is a baked-in assumption that the existing draft is the starting point and that interoperablity is important [19:58:23] bear joins the room [19:58:25] how are IETF<->W3C coordinations going these days? would an IETF OAuth plug into the RF work of http://www.w3.org/2008/webapps/ reasonably easily? [19:58:30] jhildebrand: backwards compatibility should be sought unless its even slightly hard. [19:58:41] The charter has no 2 leg scenario [19:58:47] rbarnes joins the room [19:59:02] Dave Crocker asks for review of the first paragraph [19:59:07] Simon Josefsson joins the room [20:00:00] Is ttp://www.ietf.org/proceedings/08nov/slides/oauth-0.txt current as the charter text? [20:00:27] lebobits leaves the room [20:00:33] Dave is suggesting some frankly non-technical language to introduce the problem [20:00:53] Dave is stuckee for helping craft language for paragraph one. [20:01:02] aaronstone: i think we aim a little higher. [20:01:16] Ekr believes that the problem is important, but this charter is so wrong that he doesn't want to start from this charter [20:01:24] This has 3 technical aspect [20:01:35] current phones come in two varieties: ones that suck, and ones that are showing what's to come. [20:01:50] http handshake; set of mechanisms for token passing to retain that state and export that state; a set of authentication mechanisms [20:02:09] I think we should target the what's to come, because the restrictions of mobile stacks that suck are so great [20:02:25] chris_griffiths leaves the room [20:02:30] (btw, I'm talking about phone stacks in particular) [20:02:43] this charter bakes in some connections [20:02:59] While we shouldn't gratuitously break existing oauth [20:03:10] not all phones will be great in 3-4 years time [20:03:14] We shouldn't bake in some of these connections [20:04:03] incl. with phones should be set-top boxes and embedded devices, etc. [20:04:31] ekr and Sam discuss how to summarize this. [20:04:35] sure - I just know squat about most of those [20:05:00] approximately all existing phones will be dead in 3 years. [20:05:14] they die faster than laptops. [20:05:20] ekr doesn't want us to start with something as unfactored as this, but he's happy to re-use the things in this that can be re-used [20:05:26] the W3C Webapps group is doing widget packaging for desktop and phones; having something-like-oauth for accessing geo and addressbook data APIs is very much of interest there [20:05:27] hta: sure and you think all the new phones will be great? [20:05:42] no, they will suck differently. [20:05:49] counter-argument to ekr: WebDAV [20:06:03] agreed on sucking differently, and sucking with more features. [20:06:15] ekr doesn't feel Sam is grokking his point, and Sam agrees that he does not [20:06:25] Sam would like to get people to respond to the question ekr raises [20:06:31] Joe: how is WebDAV a counter-argument to Ekr? [20:06:44] So, in particular, I think it's really problematic to have this new HTTP authentication protocol. [20:06:47] To what extent is desirable to consider compatibile with oauth, even if it is not as architecturally nice. [20:07:10] We already have a large number of technologies of this kind [20:07:11] lisa: sorry... there was meant to be a :) in that. once i actually thought about it, it didn't make sense after all. [20:07:12] PHB -- what is the likelihood that they will be compatibile? Not very. We'll inevitably make changes [20:07:13] A safe and less than safe mode? [20:07:20] Phill's point is actually important. [20:07:33] Even TLS, which was really very baked when it came into IETF, came out only semi-compatible [20:07:33] it may look similar, but it won't be interoperable [20:07:52] Clarity of problem is important, and don't build backwards compatibility as "must have" [20:07:53] i *really* need a standardized third-party *authentication* system for XMPP. i have a burning need. [20:08:09] Joe: i think that's actually a separate question. [20:08:20] this system presumes the existence of an authentication framework [20:08:25] It's purely an authorizaton system [20:08:26] Similar situation as DKIM wrt backwards compatibility and existing implementations. The IETF WG made an incompatible change, and IMO DKIM is a better protocol as a result. [20:08:28] lebobits joins the room [20:08:31] Mark presses PHB on the underlying reasons for his discomfort [20:08:41] eric: ok. then, i need to push harder on a SAML mechanism for SASL. [20:08:45] or something. [20:08:52] Well, you and I can talk offline [20:08:55] :) [20:09:01] richard.barnes leaves the room [20:09:08] But lemme phrase it this way [20:09:13] there are basically two styles of systems: [20:09:16] rbarnes leaves the room [20:09:17] <=JeffH> jhildebrand: am writing one [20:09:22] OAuth has been designed to allow for alternative signature methods, and there are a number of different ways to negotiate the various tokens. [20:09:35] PHB repeats that the need for this real and the "valet key" metaphor is easy for folks to understand [20:09:42] Online style systems like kerb and offline systems like certs. [20:09:45] So I think there's a way to maintain backwards compatibility, while adding support for new stuff that's better, or sucks less. [20:09:47] which ones do you want? [20:10:01] But he doesn't want backwards compatibility as the number one priority; number one is solve the problem [20:10:05] =JeffH: assuming one == SAML/SASL? [20:10:15] Blaine, so as a hypo, why couldn't this work with Digest [20:10:23] I'm not pitching digest, I'm just exploring the space. [20:10:27] <=JeffH> saml sasl mech [20:10:35] Stephan Wegner quotes from the oauth web page, which appears to say that this is done and only extensions are likely now [20:10:36] (and don't tell me that everyone hates digest, I'm talking protocol issues) [20:10:38] I certainly agree with PHB that either requiring or even encouraging backward compatibility will make the effort take longer. [20:10:39] isn't a point to OAuth that the consumer (urgh what a name) doesn't have to know the user's identity at all? [20:10:41] ekr: i'll explain my use case offline, and you can tell me. [20:10:45] (I'm not in the room) [20:10:51] hta: sort of. [20:10:52] <=JeffH> k [20:11:08] Stephan is asking, given that, if the working group sees a need, will the oauth guys change? [20:11:11] Eric: the only reason we didn't go with Digest was because we needed message integrity without SSL over HTTP on VHosts [20:11:41] So, if Digest provided MI that would be fine? [20:11:44] At least we do have one big advantage here, this is the first time we have had a proposal of this kind where we have not had someone shouting that we absolutely must solve the problem by date X as is the usual thing [20:11:46] Speaker (Eran, I think) says there is no one who can speak for the entire community. We do want it reviewed and fixed [20:11:49] (I'm just trying to wrap my head around what you think you need) [20:11:50] if you're using SSL to make HTTP requests, we strongly recommend using PLAINTEXT, which could just as well be Digest or Basic, except there's a bit of mismatch in the terminology [20:12:15] Jim Galvin joins the room [20:12:19] I.e., I'm not aware of any cryptographic reason to tie the token into the auth [20:12:25] Eric: yes, absolutely. But my understanding is that it doesn't. [20:12:38] ted - that is eran, yes [20:12:44] the token is just in there as an identifier - it's not cryptographic. [20:12:50] Digest auth was designed to provide a particular level of security without recourse to encumbered technology. [20:12:54] He says that if this charter does get approved, most of the companies involved will have someone at the table discussing what changes are improvements. Things that make the community bigger will help. [20:13:07] Though you could actually want to design tokens that are cryptographic. [20:13:11] E.g., delegation certificates. [20:13:26] Yes - we have the RSA signature method, which does just that. [20:13:38] Pasi agrees that it is unlikely that we won't change a single bit; an oauth 1.1 that wasn't significantly, though, is likely [20:13:41] Well, the RSA signature method is a little different [20:13:54] Agreed. [20:14:10] Sam clarifies that there will be changes; the question is whether the architecture is simlar enough to be a drop-in replacement. [20:14:11] Part of the problem with this design is that it's not clear to me that the things you're treating alike are in fact alike [20:14:24] kdz leaves the room [20:14:49] Pasi is for oauth 1.1, and against starting from a clean slate. [20:14:52] What Pasi said. [20:14:54] Right; I definitely agree that our documentation and clarity is "in need of work", if not fairly terrible. [20:14:59] David Recordon joins the room [20:15:19] I also suggest that if the document accurately reflects what is actually deployed now, then just publish it *NOW* as Informational, and discuss 1.1. [20:15:30] But I think that with the opportunity to clarify, we can probably address all / most of the concerns. [20:16:02] (I point to IKE2.0 vs IKEv1 document rewrite. We would have been better off rewriting the 1.0 document to be readable, and then editing it to make it 2.0) [20:16:10] Dave Crocker agrees with 3 previous speakers. He suspects that the group doesn't have quite information yes, which is getting you religious yes and religious no, without realistic data on what the rules are for retaining compatibility and the rules for changing it. [20:17:01] ekr: How's this as a summary of your position: "Backward-compat with parts of OAuth is fine, but backward-compat with the entire OAuth architecture is a non-goal."? [20:17:02] Dave still doesn't have a sense of how strong the installed base; he knows its real, but he doesn't know how flexible it is [20:17:08] resnick: ekr is in line [20:17:16] Damn. :-/ [20:17:20] Eran Hammer-lahav leaves the room [20:18:09] Steve f [20:18:21] ldondeti leaves the room [20:18:26] Farrell is for an oauth 1.1 style development makes sense [20:18:32] res: wether it matches what EKR meant to say, I agree with your summary, i.e. that's what I'd like to see in charter [20:18:53] He's not concerned about the bits on the wire [20:19:05] I think Farrell just disagreed with us. [20:19:09] Hannes hopes that we still like the idea of running code [20:19:15] I don't actually think that changing anything changes everything. there's a mechanism for adding new name/value pairs that get signed, right? [20:19:15] I'd be worried about underestimating the current installed base. Both Google and Yahoo are using it in production APIs, it's being built into development frameworks, relied on in things like OpenSocial, and being used by many smaller sites today along with design decisions being made for new APIs that are being planned from small sites up through large enterprises (not all of which are public). [20:19:41] ldondeti joins the room [20:19:45] Eran Hammer-lahav joins the room [20:19:56] Lisa D. up as sponsoring AD for the BoF [20:20:12] DC: sounds like a vote for "publish info on what's shipping then get to work on 1.1"? [20:20:17] david: sure, but are those deployments being done on the assumption that there will never be an OAuth 1.1, whoever produces it? [20:20:25] Recordon: Are you saying that IETF can't make any incompatible improvements? [20:20:27] jhildebrand: yup, we can definitely add additional name/value pairs that get signed. that was definitely a primary design goal. [20:20:30] She has personally talked to the oauth people here and others in that community. Nobody that she has talked to expected bit for bit compatibility [20:20:46] that's a false opposition, let's leave it behind [20:21:29] this is a big thing, there is a lot of buzz, and a lot of people with good web taste like it [20:21:30] I see no problems with additional parameters for a 1.1, but changing the underlying model, protocol flows, etc feels difficult. Obviously it all depends on the extent of the changes and additional benefit offered. [20:21:39] it's also not terribly hard to change some of the code [20:21:42] And buzz is supposed to be a good thing? [20:22:07] pete: deployment is a good thing, yes [20:22:11] Pete: If this was a BarBOF, yes. [20:22:12] resnick: which kind of buzz? [20:22:13] They can cycle their code, if doesn't involve throwing out their database (I presume of user info?) [20:22:41] The buzz that Lisa was just talking about seems not about deployment but excitement. [20:23:12] <=JeffH> from my perspective, the spec can be "improved" quite a bit by re-factoring and clearly layering/binding, w/o changing impls (tho I'm not opposed to casuing such change) [20:23:15] ekr discussing the charter; it says "to the greatest extent possible, we'll retain backwards compatibility" [20:23:33] he has some concerns about that. [20:23:34] ekr: the signature method definitely isn't just two-party. The fact that we incorporate all of consumer-user-service provider is important, at least as far as the original design goals are concerned. [20:23:47] Digest doesn't do that, without having some other mechanism for incorporating those bits [20:23:59] I don't understand the problem with changing the name of a field [20:24:26] ekr: We have two shared secret authentication mechanisms. Why should we have two? Sam says "Why is this a problem" [20:24:30] duplication isn't bad? [20:24:34] sftcd: signatures make it problematic. [20:24:40] CMC vs CMP = nothing in real use [20:25:00] Here's how we dealt with backwards compatibility in the DKIM charter: [20:25:02] What two mechanisms are being discussed? [20:25:03] Experimentation has resulted in Internet deployment of these specifications. Although not encouraged, non-backwards-compatible changes to these specifications will be acceptable if the DKIM working group determines that the changes are required to meet the group's technical objectives. [20:25:12] lebobits: as a CMP author, there were other reasons for that [20:25:25] david: digest and oauth signature [20:25:41] Sam believes that there is a rough, but not complete consensus, that we do not need to resolve the question of whether having one or two mechanisms needs to be resolved. [20:25:57] Jim Fenton: that's probably close to what we did for XMPP. [20:26:01] before deciding whether or not to work on oauth 1.1 [20:26:14] sftcd: yes, but that was a big part of it, at least as I faced it being originator and chair of PKI4IPsec [20:26:26] Sam tries to describe what will get pushback and what won't. [20:26:36] Can someone scribe a moment, while I get in line? [20:26:45] sure [20:26:47] go ted [20:26:49] Eric Rescorla leaves the room [20:26:54] ekr: don't know [20:26:59] Pasi at mic [20:27:00] Eric Rescorla joins the room [20:27:10] took quick look at signature in use [20:27:28] seems designed to satisfy specific constraints on how its used [20:27:55] some of it seems strange to him, like done for optimizing coding in PHP vs changing apache code [20:28:04] [if I understood him correctly] [20:28:09] perhaps we *should* make those distinctions, if we want our stuff to be implemented!!! [20:28:23] it's not fair to throw the implementor to the woves. [20:28:26] wolves, even. [20:28:28] +1 [20:28:34] Chris Newman leaves the room [20:28:34] +1 [20:28:43] just need to call it out [20:28:50] explicitly [20:29:02] sure ;-) [20:29:07] I'm here for ya, man [20:29:11] the +1's were to it's ok to optimize for implementation, right? [20:29:13] scribing... [20:29:24] Ted at mic [20:29:27] well, I'm not against duplication with reason [20:29:28] concerns [20:29:29] +1 Ted [20:29:33] but I'm against duplication because of NIH [20:29:43] have something working in wild [20:29:54] now bringing it in to get doc'd and spec'd [20:30:07] don't want gratuitous changes, understandable [20:30:08] Eric: agree. the reason here i think is 3rd party. existing digest doesn't do that, and existing X509 is too hard to deploy in practice. [20:30:22] but remember, the people bringing it in ARE IETF [20:30:31] you are the ones that have to do the work [20:30:32] Well, but maybe that tells us that we should be replaceing our existing mechanisms with these. [20:30:40] [that was to Joe] [20:30:46] But actually, I don't agree with that anaysis [20:30:47] so don't run off [20:30:53] SAM talking [20:31:05] we met with the folks bringing it in [20:31:13] at lunch [hope it was tasty] [20:31:18] Eric Rescorla: cool, willing to be dissuaded. that's our offline. however, that seems to be what the refrain is out in the world. [20:31:18] they are good folks [20:31:28] Dave Crocker at mic [20:31:32] Sam shuts him down [20:31:32] One thing is it's not clear you need X.509 to make RSA work [20:31:37] Thanks for taking over the scribing [20:31:43] After all, they're not [20:31:50] Sam lets Dave talk [20:32:06] Sam trying to clarify what dave can talk about [20:32:09] Dave talking [20:32:13] Ted? [20:32:16] take over? [20:32:19] yes, I'm back if you want me to [20:32:26] out [20:32:34] me out [20:32:36] you in [20:32:46] Gads, I hate that distinction. It's not "1.1 versus starting fresh". It's "requiring backwards compat versus not requiring it." [20:32:48] Dave is going through the history that we always have some tension here [20:33:22] Randy Gellens notes it was brought up in the jabber room to re-use the text from xmpp and dkim [20:33:50] http://xmpp.org/about/wg-charter.txt [20:33:57] that's the XMPP WG charter [20:34:15] First Hum: 1.1, start fresh, or we need more information (sponsored by Dave Crocker) [20:34:24] Do people understand? [20:34:37] No "start fresh" [20:34:39] hum from me for 1.1. [20:34:59] This is the stupidest voting system ever [20:35:10] i hummed for both 1.1 and more info [20:35:15] Lets get Norm Coleman in here to ask for a re-hum [20:35:23] Sam is saying "possibly rough consensus" for 1.1, but weak [20:35:24] more information needed about more information needed. [20:35:28] info needed: size of installed base. Who is involved? [20:35:29] Where can this be exploited would be good to know. [20:35:29] eric.brunner joins the room [20:35:30] from the XMPP charter: "Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them." [20:35:34] Pete Resnick, especially loud information hummer at the mic [20:35:40] pete needs new business cards to that effect. [20:35:41] He hates the question [20:35:50] joe the plumber, pete the hummer [20:36:06] Be careful, there, Ted. [20:36:19] stpeter: I think that's what is needed here, yes. [20:36:20] He wants to know how far off we can go. [20:36:32] dirkx@jabber.org joins the room [20:36:36] if there was some analysis about how to *do* backward-compatibility, it might be enough [20:36:53] other charter issue: [20:36:59] Dave Crocker believes that this question can be resolved on the mailing list, and does not need a new BoF and it cannot wait for the wg [20:37:01] for example, the XMPP version='1.0' stuff would have been enough to get past this issue. [20:37:33] re: assure good security practice, or document gaps in its capabilities [20:37:38] I would prefer: [20:38:36] assure good security practice, or document gaps in its capabilities and define a roadmap for addressing those gaps, including that roadmap in the charter and milestones [20:38:41] goal: [20:38:50] it's okay to not be 100% secure at the get go [20:38:55] HTTP wasn't, and it lived [20:39:14] what does 100% secure mean? [20:39:18] based on what threat model? [20:39:20] dirkx@jabber.org wonders if http is a good example :) [20:39:35] but it is really important in order to make steps without getting blocked for known security issues to state you know them and put a commitment in place to address them [20:39:38] make sense? [20:39:40] I wonder if SSL is an example, since we actually totally gratuitously broke htat [20:39:43] danbri tunes into audio [20:39:55] +1 to Phill [20:39:58] sorry LD. You're right [20:40:03] i think SSL is a perfect example [20:40:16] am I LD? [20:40:18] s/100% secure/as secure as we can see at present, by consensus [20:40:36] no Lakshminath was the LD I referred to [20:40:44] well, I was looking at this doing more than other protocols we have developed in the IETF [20:40:48] buy you can also be and LD [20:40:50] perhaps I am wrong [20:40:51] if you want to [20:41:09] Can I be LD? [20:41:13] Ted says: let's put the negotiation stuff in the charter to move forward. [20:41:17] ted says: where is the negotiation and extensibility to permit 1.0->NG transition [20:41:38] ldondeti: but in most protocols had significant security requirements in their charter - or had some AD make very clear that such should go in there :) [20:41:46] and rlbob agrees that this is a significant issue [20:41:55] Sam asks whether the charter is good enough as a starting place for discussion? [20:42:09] since OAuth discovery is itself a work in progress [20:42:22] Sam believes that there will be discussion on the list [20:42:34] negotiation of versions might be hard if there web browser must also be compatible. [20:42:56] Lucy asks that we get folks name what their blocker is in the charter, so it is noted for discussion on the mailing list. [20:43:28] Ted: milestone them please ! [20:43:37] Sorry - thanks ! [20:43:38] Greg's issue: "assure good security practice and document gaps". He wants to have us commit to fixing the gaps in some time frame, possibly incrementally [20:43:45] Can we take it as read that I have a blocker as previously stated, namely that I don't know what this excludes, so I don't have to stand up and ruin my voice? [20:44:07] <=JeffH> farrell speaks at .8 ekr [20:44:18] Stephen Farrell believes that there is a lack of discussion and mobile use cases are blockers [20:44:42] eric.brunner leaves the room [20:44:47] chairs: please just note ekr's existing objection. [20:44:48] the lack of discussion (didn't) happen on the mailing list (or maybe it did:-) [20:44:52] RLBob believes that the need for negotiation is implicit and he has a blocker for service discovery being separate [20:45:22] People agree with RLBob, but he's still sighing at the mics [20:45:23] for mobile, please liaise with these guys: http://www.w3.org/2008/webapps/charter/ [20:45:40] c'mon people, it's really got to be "OAuth 2.0" [20:45:40] I would like the charter to state that I get a pony. [20:45:43] Sam's blocker is channel bindings [20:45:53] ekr's blocker is that he has no pony [20:46:03] I actually wouldn't know what to do with a pony. [20:46:05] dirkx@jabber.org is now known as Dirk-Willem van Gulik [20:46:06] Other than like bbq [20:46:07] Lisa is asked if she needs anything else [20:46:13] Braised, in a nice sauce? [20:46:16] Isn't ekr always discussing his pony on bad-attitude? [20:46:28] Who is willing to work as a document author is asked by Same. [20:46:39] Dirk-Willem van Gulik observed that horse is best had in thin slices; ideally smoked. [20:46:42] point out ekr's hand! [20:46:44] Jeff Hodges, Eran, Blain, Larry, ekr, Hannes [20:46:57] Stephen Farrell too [20:47:01] Aaron stone, Stephan Farrel [20:47:01] ekr, pony is for darwin. [20:47:07] I'm willing to help write [20:47:08] er, Farrell, sorry [20:47:18] Who is willing read and review [20:47:20] 20-25 hands. [20:47:55] Wo is willing to chair a working group. Lisa stands and looks, Dave raises his hand [20:48:06] er, Who is willing. [20:48:26] i think crocker would be a great choice. [20:48:44] Sam asks whether we should address security gaps rather than document them? [20:48:45] =JeffH <-- wants to have a hum on best local ale [20:49:05] Mark objects, Greg comes up to discuss. [20:49:51] Greg says he believes documenting the recognition is important for moving things forward in the IETF. [20:50:09] Dirk-Willem van Gulik observes that oAuth has a different relation with security than, say, http or Jabber. [20:50:17] < Dirk-Willem van Gulik > Security is the very core of OAuth [20:50:38] +1 on Greg. incrementalism is very important. [20:50:38] <=JeffH> ted: Greg who? [20:50:39] Is a security requirements doc planned? [20:50:55] It's a good thing that 2026 requirement isn't enforceable [20:51:00] PS is not the first step. [20:51:04] it would be nice if we had such a thing as sec reqs [20:51:17] < Dirk-Willem van Gulik > I think what is meant there is 'known' 'unknown' ones. [20:51:17] Pasi notes that "no known technical ommissions is not enforcable and we'd having nothing if we tried" [20:51:18] I'd think it is mandatory, but that's just my opinion [20:51:24] stupid me. PS is. I thought he said DS. [20:51:25] The first version doesn't have to be perfect. [20:51:37] Jim Galvin leaves the room [20:51:37] Clear that this is not a simple hum [20:51:42] marcos leaves the room [20:51:50] Now open mic, for anything that helps us move forward. [20:52:00] The protocol shouldn't have known omissions relative to the requirements agreed upon. [20:52:26] Melinda leaves the room [20:53:35] < Dirk-Willem van Gulik > To the speaker: do bear in mind that OAuth its core is arguably 'security' - rather than 'security' is just part of a protocol accomplishes something _else_ which happens to need security./ [20:53:35] Man, Jim, we would never have any standards under those condiitons [20:54:32] ekr: Maybe; I'm suggesting that just to bound the problem and eliminate the "metal safe" issues [20:54:38] hta leaves the room [20:54:38] cyrus leaves the room [20:55:19] Eran notes that there is already some limitation to the interop; we can take a direction that restricts things further and creates full compatibility but less rich [20:55:26] Or we can push extensibility even further [20:55:48] cyrus joins the room [20:55:52] Jeff H: Gregory Lebovitz [20:55:56] Mark notes that it is not terribly "restful" right now, and that oauth can change further to become more restful. [20:55:58] that's Blaine talking. [20:56:13] Barry Leiba leaves the room [20:56:18] right, Blaine Cook at the mic [20:56:20] the security gaps discussion here seems a bit arbitrary.. I don't know if we are commiting to a sec req.s document.. the charter currently says "Submit documents suitable for publication as standards-track RFCs" [20:56:21] Barry Leiba joins the room [20:56:23] Blaine is noting that the community is very open to change where the reasons for change have been given and have made things better [20:56:45] I think a sec req document would be basically useless. [20:56:54] But I think someone needs to do ana analysis of this protocol. [20:57:01] Mark asks if anyone is feeling repressed? [20:57:04] ekr comes up [20:57:40] Someone said to me that a core requirement was that the service provider must be in the loop; Eran notes that it is not a requirement. [20:57:52] i thought there was a requirement for CRL-like functionality, though. [20:57:59] That's compatible. [20:58:01] Eran goes to the mic: the central role of the service provider came from the use case, not an architectural choice or requirement [20:58:40] Barry Leiba leaves the room [20:58:42] Blaine clarifies that the consumer key mechanism that is allowed to pass out new credentials, there are ways to make this possible. [20:58:52] lellel leaves the room [20:58:54] lhalff leaves the room [20:58:57] cabo leaves the room [20:59:00] PHB leaves the room [20:59:03] kivinen leaves the room [20:59:03] cyrus leaves the room [20:59:09] Eran Hammer-lahav leaves the room [20:59:10] < Dirk-Willem van Gulik > Thanks for the chairing. [20:59:13] Randall Gellens leaves the room [20:59:15] sftcd leaves the room [20:59:16] resnick leaves the room [20:59:16] ludovic.poitou leaves the room [20:59:19] Eric Rescorla leaves the room [20:59:24] Doug Otis leaves the room [20:59:25] thanks all, bye [20:59:30] Ted leaves the room [20:59:34] Simon Josefsson leaves the room [20:59:36] Well done all [20:59:36] (will this chat room stay active?) [20:59:48] frumioj leaves the room [20:59:48] danbri: all rooms are always available [20:59:55] rlbob leaves the room [20:59:56] Jim Fenton leaves the room [20:59:59] but usually everyone leaves [21:00:02] David Recordon leaves the room [21:00:21] always nice to hear the chairs chatting while the MIC is still on. [21:00:38] < Dirk-Willem van Gulik > :) [21:00:41] that's why I just unplugged it :) [21:00:43] Lisa leaves the room [21:00:50] Blaine Cook leaves the room [21:01:12] heh [21:01:31] eronenp leaves the room [21:01:34] < Dirk-Willem van Gulik > Hmm - so now we know the delay -- me still hearing them talk [21:01:48] lebobits leaves the room [21:01:48] lebobits joins the room [21:01:57] Vlad Stirbu leaves the room [21:03:47] stpeter leaves the room: Logged out [21:04:02] lebobits leaves the room [21:04:59] =JeffH leaves the room [21:05:13] Mark Nottingham leaves the room [21:05:14] jonas leaves the room [21:06:11] < Dirk-Willem van Gulik > Hmm - intersting - still hearing the room :) [21:07:23] jhildebrand leaves the room: Disconnected. [21:11:16] < Dirk-Willem van Gulik > darn - they even have beer -- life is soo unfair [21:11:44] stefans leaves the room: Replaced by new connection [21:12:28] stefans joins the room [21:16:28] bhoeneis leaves the room [21:16:43] slowhog leaves the room [21:16:45] Mark Nottingham joins the room [21:17:20] Mark Nottingham leaves the room [21:17:30] slowhog joins the room [21:18:32] vidya leaves the room [21:18:57] ldondeti leaves the room [21:21:29] hello, i hear a voice! [21:21:44] aaronstone leaves the room [21:23:02] PHB joins the room [21:23:06] PHB leaves the room [21:28:28] bhoeneis joins the room [21:29:56] jhildebrand joins the room [21:30:35] slowhog leaves the room [21:30:56] jhildebrand leaves the room: Replaced by new connection. [21:31:01] jhildebrand joins the room [21:31:30] stpeter joins the room [21:32:17] tonyhansen leaves the room [21:33:17] ludovic.poitou joins the room [21:35:09] Lisa joins the room [21:43:14] jhildebrand leaves the room: Replaced by new connection. [21:43:14] jhildebrand joins the room [21:43:14] jhildebrand leaves the room [21:44:46] Mark Nottingham joins the room [21:45:24] eric.brunner joins the room [21:45:31] eric.brunner leaves the room [21:45:43] Mark Nottingham leaves the room [21:46:04] cabo joins the room [21:46:15] sal leaves the room [21:47:50] cabo leaves the room [21:53:02] mcharlesr leaves the room [21:57:02] Lisa leaves the room [21:59:34] bhoeneis leaves the room [22:07:56] ludovic.poitou leaves the room [22:08:16] cabo joins the room [22:09:01] cabo leaves the room [22:12:33] Eric Rescorla joins the room [22:18:06] ludovic.poitou joins the room [22:18:18] ludovic.poitou leaves the room [22:21:53] eric.brunner joins the room [22:22:05] eric.brunner leaves the room [22:22:20] PHB joins the room [22:22:21] stpeter leaves the room [22:23:14] PHB leaves the room [22:26:46] Eric Rescorla leaves the room [22:34:32] PHB joins the room [22:34:49] PHB leaves the room [22:35:30] PHB joins the room [22:37:32] PHB leaves the room [22:46:59] PHB joins the room [22:49:49] PHB leaves the room [22:52:42] cabo joins the room [22:55:33] Blaine Cook joins the room [23:14:07] Blaine Cook leaves the room [23:17:46] cabo leaves the room [23:20:20] Eric Rescorla joins the room [23:22:20] PHB joins the room [23:23:28] PHB leaves the room [23:24:29] Dirk-Willem van Gulik leaves the room [23:26:21] Blaine Cook joins the room [23:26:52] Blaine Cook leaves the room [23:27:23] dirkx@jabber.org joins the room [23:35:47] Eric Rescorla leaves the room [23:41:15] Eric Rescorla joins the room [23:41:46] Eric Rescorla leaves the room [23:44:05] Eric Rescorla joins the room [23:47:27] dirkx@jabber.org leaves the room [23:50:30] ludovic.poitou joins the room [23:50:33] ludovic.poitou leaves the room [23:52:50] cabo joins the room [23:56:14] PHB joins the room