[06:00:22] EHL joins the room [06:47:21] yone joins the room [06:59:47] Wolfgang Beck joins the room [07:00:03] Cary Bran joins the room [07:00:40] tlyu joins the room [07:01:06] Kepeng Li joins the room [07:01:53] ywang830 joins the room [07:01:59] lef joins the room [07:03:52] Melinda joins the room [07:04:18] lellel joins the room [07:05:04] Blaine Cook joins the room [07:05:59] Peter just came into the meeting with a bunch of ADs. [07:06:07] And is staging a coup - wait, no - ... [07:06:38] The OAuth WG is moving to the security area, so that we can ensure that we're getting the input from the security folks. [07:06:41] Jacky Yao (Health Yao) joins the room [07:07:00] not the WG, the spec [07:07:09] yoiwa joins the room [07:07:33] the group, I believe [07:07:35] sandoche joins the room [07:07:48] yes - S Farrel is the new ad [07:08:09] I should not be the scribe. :-) We'll ask for someone to scribe here in the room unless someone here already wants to do it [07:09:22] spturner joins the room [07:10:02] in case you're not in the room, an AD interrupt has occurred [07:10:08] stephen farrell: new charter should read "OAuth 2.0, in 2011." [07:10:18] stephen: let's get to that quick. [07:11:03] Torsten's back up, discussing the security considerations [07:11:23] sftcd joins the room [07:11:39] barryleiba joins the room [07:11:49] semery joins the room [07:12:00] oauth is now a security WG [07:12:15] =JeffH joins the room [07:12:38] Simon Josefsson joins the room [07:13:51] stpeter joins the room [07:24:55] Are slides available online? Assuming slides are used now... [07:25:15] Slides are in use, but have not been posted to meeting materials. :-( [07:25:20] sandoche leaves the room [07:25:26] Ok. :-( [07:25:46] can chairs please send slides to meeting materials? [07:26:31] i thought it was showing the HTML version of an I-D… anyone know which it is? [07:27:05] same as any other registry we define [07:27:11] all linked together [07:27:31] I can shout! [07:28:03] no, its a case of figuring out the rquirements [07:28:08] The one that is being shown right now is the registry document [07:28:16] before designing a solution [07:28:40] not months [07:28:45] a few weeks [07:28:54] with little interest by most WG members [07:29:02] and a resolution is pending [07:29:12] given new use cases from yaesterday [07:29:24] not really an issue anymore [07:29:34] harry joins the room [07:29:51] yone leaves the room [07:29:59] decisions are made on the list, not in meetings [07:30:03] give me a break [07:30:31] there are no decisions being made here regarding the technical direction [07:30:39] resnick joins the room [07:30:42] rlbob joins the room [07:31:17] the only potential open issue with this is whether the error codes for the code spec should be extensible. I'm saying no. only extensions can extend the set. [07:31:26] if you implement v2 as is, you should never get a new error code [07:31:28] ever! [07:31:39] unless there is an extension defined as well [07:31:43] that's the way we do interop [07:31:53] all decisions need to be taken to the list for consensus -- however, it's acceptable to take the measure of the folks in the room as a way to figure out what direction might be appropriate [07:32:19] I was commenting about the digs of not traveling around the world for 2 hours. [07:32:43] alexey.melnikov joins the room [07:32:46] not worried about decisions being made elsewhere [07:33:21] ꈲ joins the room [07:33:26] so I'm +1 on jones' proposal [07:33:33] with that added restriction [07:33:34] yone joins the room [07:33:37] that's a compromise! [07:34:09] we don't really have consensus calls [07:34:15] mostly just hums [07:36:29] also added to the document without consensus call [07:36:32] so my bad [07:37:30] EHL: both consensus calls and hums are an established way to figure out if people are in agreement [07:37:49] sure, we just rarely do consensus calls [07:37:58] just how our WG seems to operate [07:41:35] where was this in WRAP? [07:41:42] what section in http://tools.ietf.org/html/draft-hardt-oauth-01? [07:42:39] there is no consensus [07:42:52] well, there is consensus that we need better text [07:43:01] something that actually accomplished interop [07:43:20] Eran, can you suggest what you think is better text? [07:43:27] (Or maybe you have already?) [07:43:37] there was no consensus to add it!!!! [07:43:44] NO [07:43:49] it was there for one month! [07:44:09] this is a total distortion of the facts [07:44:14] and this is a waste of time for this meeting [07:44:57] no it wasn't [07:45:11] and tony has confused two diff features together [07:45:15] in the past [07:45:23] (grants and client creds) [07:45:27] martin.thomson joins the room [07:45:49] barryleiba: better text would accomplish interop, not just define a hook for others to profile [07:45:59] tony.l.hansen joins the room [07:46:03] by itself the proposed text was not implementable [07:47:20] process wise: section was added solely on my own accord, that was a mistake and corrected the following revision [07:48:05] yuioku joins the room [07:48:40] Eran: ack; thanks. [07:48:47] Karen O'Donoghue joins the room [07:48:58] 1.1 ended being RFC 5849 [07:50:25] thanks for that point, eran [07:51:04] jones: there is not enough deployment experience to write normative text for native apps [07:51:17] it would be premature standardization [07:52:35] google just announced work on a new JS profile [07:52:58] without redirections [07:53:07] today [07:53:09] :-) [07:53:28] they just made a comment that they are working on a new way to do oauth on JS apps [07:53:32] that is not what v2 does [07:54:22] great - how about turning those deployment experiences into proposed text! [07:54:32] hope I'm not asking for too much [07:55:53] the section jones/nadalin were talking about removed was http://tools.ietf.org/html/draft-ietf-oauth-v2-11#section-3.2 [07:56:03] which was taken out a month later in -12 [07:57:17] what was removed about native apps? [07:57:58] sandoche joins the room [07:59:35] this is the closest we got: [07:59:35] http://tools.ietf.org/html/draft-ietf-oauth-v2-06#section-2.11 [07:59:40] which is useless [07:59:55] anything else will mean another 3-6 months delay [08:00:03] for something that can be defined in a followup [08:00:06] I'm fine either way [08:00:51] re: arguing, we have two minor issues to close and we're pretty much done [08:02:18] 1. error registry rules [08:02:32] @EHL: + sec considerations, right? [08:02:35] 2. MUST vs SHOULD on redirection URL endpoint on the client side [08:02:37] yeah [08:02:54] but that's assumed not to change implementations [08:03:12] so it is critical but the rest is considered mostly done [08:03:26] That's not generally true, here it may be, or maybe not - we fix security problems that need fixing when we find them [08:03:27] complete protocol-wise, not spec-wise :-) [08:03:29] EHL: regarding "anything else will mean another 3-6 months delay for something that can be defined in a followup", I think that is what Stephen Farrell is in part saying -- get the base spec done and work on a follow-up or extension after that to incorporate further implementation and deployment experience [08:03:49] sftcd: it's never done until the IESG approves it :-) [08:03:50] @EHL: yes, get the base done is part of the meta-message [08:06:16] Andrew joins the room [08:06:21] we don't know what the security of the client creds is because it is way under-specified [08:06:23] its a hook [08:06:30] not a fully interop feature [08:07:01] native apps are a whole new bucket [08:07:14] client cred same [08:07:17] we can delay the work [08:07:25] but this is not closing issues [08:07:30] it is starting whole new items [08:07:34] which is fine [08:07:45] but let's not pretend this is just 'open issues' [08:08:02] no [08:08:07] two open issues [08:08:18] two examples of new functionality [08:08:29] native apps and client creds are not open issues [08:08:42] Hugh_Daniel joins the room [08:08:46] they are requests for expanding the scope of the protocol as currently written [08:08:56] please don't confuse this [08:09:09] EHL: I can channel that to the room for you [08:09:09] (sounds like the room is very confused) [08:09:20] stpeter: thanks [08:09:53] @EHL: Probably best to start things you intend for the mic with "mic:". Folks are doing their best to channel you to the room. [08:10:36] i'm at the mic for Eran [08:10:38] mic: the list of open requests will take 5 years to finish, these are not open issues but open requests (native apps, client cred, discovery, etc.) [08:12:19] weiber joins the room [08:12:22] Torsten at the mic [08:13:05] Torsten is referring to http://tools.ietf.org/html/draft-ietf-oauth-v2-11#section-2.3 [08:13:26] mic: native apps can use every grant type defined [08:13:44] mic: this is why I renamed them so they are not called 'user-agent' and ' [08:13:49] web-server' [08:14:14] mic: that text is useless. it is just lip service to say we address native apps [08:14:47] (I like my new voice) [08:14:52] we need two screens up here, one for the presentation and one for the chatroom :) [08:14:57] :-) [08:14:58] EHL: you have three new voices [08:15:07] sweet [08:15:20] some people say one is already too much [08:16:16] mic: I don't recall such a request to put the old native apps text back, please provide link to post [08:16:49] EHL: we do the dual-screen thing in some security area WGs and it helps a lot with remote participation [08:17:14] mic: I'm not blocking on the native apps text [08:17:39] mic: as long as someone else builds consensus [08:17:43] Hannes Tschofenig joins the room [08:17:46] Barry at the mic for EHL [08:18:15] EHL: right, someone else can build consensus on this [08:18:42] http://benward.me/blog/oauth-flow [08:19:02] sounds like a bcp for natives apps would be needed [08:19:27] native apps are hard... [08:19:40] there's JS, mobile, desktop, etc. [08:19:46] java applets [08:19:49] flash [08:19:52] Which is why I believe that this should specified, but separated. [08:20:06] stpeter nods to EHL -- perhaps an informational document would be helpful [08:20:26] semery: do feel free to say that at the mic, since you have the ability [08:22:07] jabber room now on projector [08:22:32] Sorry, I was speaking while I posted that link - the point is that Ben's post is non-normative, but by far the most useful reference (far moreso than the spec will *ever* be) on doing web-based flows of OAuth [08:22:43] re speaker: there is only one section that was added and removed [08:23:02] That was Tom Yu speaking [08:23:10] there is no issue about the dropped text for native apps [08:23:19] I don't recall a request to put the prose back [08:23:27] and I dont recall rejecting such a request [08:23:34] (since I really don't care) [08:23:34] A similar document on how to (in the real-world, with pretty pictures) do native apps would be 1000x more useful than trying to encapsulate these things to everyone's satisfaction in the spec itself. [08:23:48] (but as I said earlier, we should probably include some guidance text) [08:23:50] its requested now at least let's try deal with it then confirm on the list [08:24:02] hey this is a good way to skip the line at the mic [08:25:01] mic: someone should take the old native app text, clean it, and repost it [08:25:10] mic: and maybe make it a bit more useful [08:25:17] mic: prose wise [08:25:31] mic: this is not an open issue, just a potential pending request [08:25:58] there is no known difference between open issue and pending request here [08:26:07] +1 [08:26:44] sftcd: issues == no consensus. requests == likely easy decisions [08:27:56] there was consensus in the room that the native app text would go back in . this will be confirmed on the list (obviously) [08:28:15] evan gilbert from goog wrote it and should be included [08:28:18] if he wants [08:28:27] sandoche leaves the room [08:28:44] @ehl: ack [08:28:58] http://tools.ietf.org/html/draft-ietf-oauth-v2-11#section-3.2 is the client assertion text [08:29:02] Is the client assertion credentials just analogous to using digest instead of basic? [08:29:16] mic: key here is *some form* [08:29:28] mic: but the section does not go beyond this [08:29:49] mic: it literally say "stick some credentials in here --> ______" [08:29:58] mic: credentials are undefined [08:30:52] mic: process wise: Yaron Goland ask me to include it. I made a mistake and added it in -11 without WG debate. I removed it in -12 a month later without consensus. [08:31:03] mic: so process wise I messed up and I own that mistake [08:31:13] OUT! [08:31:18] ehl: I will channel [08:31:47] Is there an active issues tracker? The one on the tools page doesn't seem to be being used. [08:32:03] mic: odd to hum on an undefined feature... :-) [08:32:08] Melinda: I noticed that too. [08:32:16] <ꈲ> Fix it... [08:32:32] issue tracker is not used [08:32:41] tlr joins the room [08:32:54] mic: SAML is not about this!!! [08:32:55] the issue tracker could be used, naturally [08:33:05] mic: it is about grant type, not this section [08:33:12] <ꈲ> stpeter: I'd make that a SHOULD. [08:33:17] It seems to me that given the pretty serious process problems here, it might not be a bad idea to start using it. [08:33:29] <ꈲ> Quite obviously, issues are getting lost here. [08:33:34] consensus in room for client assertion text to be in ….. is put it in [08:33:38] no issues are lost [08:33:50] this is the only process problem we have [08:33:58] ꈲ: talk to the WG chairs and AD -- personally I like issue trackers and would recommend to them that we use it [08:34:01] about a one page section [08:34:08] It seems to me that no issues are resolved, and that's the process problem [08:34:33] please (!) read it before you decide about it [08:34:47] EHL: I agree [08:34:53] all of these will be taken to the list [08:34:53] mic: I am 100% sure people are confused about this [08:35:02] mic: and they don't know what they are humming about [08:35:04] EHL: I will channel that in a minute [08:35:30] mic: all I ever said was that someone needs to give BETTER text that is well defined [08:35:41] mic: and if we get the text in time, we'll put it back in [08:35:50] <ꈲ> See, we have an issue that was lost. [08:35:58] mic: however, those pushing for it rather argue than do the work [08:36:06] mic: I asked, the chairs asked! [08:36:20] Cary Bran leaves the room: Disconnected. [08:37:37] sure as long as something is mandatory to implement [08:38:02] mic: there is NOTHING in the spec today to prevent this EXACT section from being published as an extension [08:38:24] mic: we work hard to make it extensible and put the right normative language around it [08:38:42] canter: an extension point has to have some interop value up front [08:38:50] canter: and this text does not provide it [08:40:32] Cary Bran joins the room [08:40:48] to speaker: that would be great but not possible for current text [08:42:17] mic: we are not talking about grant types using assertions [08:42:40] mic: we are talking about client authentication which is already barely defined, and this makes it even less clear [08:45:15] please read: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03 [08:45:29] and note that it has NOTHING to do with this client credential text [08:45:36] I think that is half the confusion [08:46:27] jones: I never said that about the rest [08:46:31] jones: just that section [08:49:04] any new text HAS to explain how this is different from http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03 [08:49:22] EHL: I will channel your last few messages [08:50:44] EHL: i will look at the bearer spec [08:51:51] could you use X.509 as an example? [08:52:07] <=JeffH> tonyN said he didn't understand what EHL meant at all [08:53:08] also note that there were other objections to this [08:53:27] section which included the view that all client authentication MUST use HTTP authentication [08:53:39] and not any of these body parameter schemes [08:53:47] which are really a hack [08:54:05] so we had technical issues about this text raised [08:54:42] mic: why is this section not defined as a general purpose HTTP auth scheme? [08:54:52] mic: since it has the exact same functionality [08:55:01] (please read that last comment, its important) [08:55:25] ok [08:56:31] this is client auth [08:56:40] classic client-server auth [08:56:43] as in HTTP auth [08:56:52] this is RFC2617 teritory! [08:57:00] territory [08:57:13] EHL: good point [08:57:18] the client password credentials is clearly a nasty hack [08:57:30] which seems to inspire more :-) [08:59:22] speaker: not for this! [08:59:33] speaker: this was an issue 3 years ago, not anymore. [08:59:50] speaker is tom yu [08:59:59] this is 100% http client authentication [09:01:04] the client password section is there to make the twitter/facebook crowd happy [09:01:10] not because it is right [09:02:35] I don;t think anyone is suggesting that form encoded parameters are the answer to issues with http auth header! :-) [09:02:45] EHL: so why is it that client password makes them happy? [09:03:11] tlyu: because it is easier to type into curl than using the header option on the command line [09:03:14] not kidding [09:04:20] EHL: that's ridiculous. [09:04:32] EHL: so then it's an implementation (or more precisely, implementor) constraint, possibly an unreasonable one. [09:04:33] curl -u http://x.y/z [09:04:53] will prompt for a password - or you can specify the password on the command line [09:05:04] mic: I changed my mind. I want to reopen the entire section 3 for discussion [09:05:15] mic: make section 3.1 an extension [09:05:21] mic: and drop all client auth out [09:05:40] mic: so I'm now opposed to this spec specifying any client auth scheme [09:06:15] I guess we now have 3 open issues [09:06:48] EHL: I recommend that you post to the list about that after this meeting is over :) [09:07:03] stpeter: already drafting it [09:07:10] EHL: excellent [09:13:16] to the room: if you are confused about *anything* please just ask. I am happy to post sum. posts about any topic to help get people up to speed [09:13:16] Karen O'Donoghue leaves the room [09:15:29] http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01 [09:15:52] http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-01 [09:16:06] second one is the proposal for security considerations section [09:19:17] one is how and the other is why [09:20:52] Andrew leaves the room [09:22:41] Igor at the mic [09:23:47] Hannes Tschofenig leaves the room [09:24:51] just reading through the security considerations doc and noticed a problem in Section 2.2. The section talks about an adversary gaining client secret and then suggests the remedy for this is to authenticate. This is tied into the earlier discussion and actually seems like a pretty silly thing to include. [09:25:59] semery leaves the room: Disconnected [09:26:17] Cary Bran leaves the room [09:26:24] Blaine Cook leaves the room [09:26:52] to be clearer, between the client and the authorization server, the only secret they have relates to the authentication of the client. Requiring HTTP auth plus something else is just a way of increasing the entropy of the secret that the adversary needs to acquire [09:29:13] barryleiba leaves the room [09:29:14] weiber leaves the room: offline [09:29:36] Wolfgang Beck leaves the room [09:30:05] several people volunteered to review and comment on the use cases document [09:30:54] yoiwa leaves the room [09:30:54] lellel leaves the room [09:31:16] tlyu leaves the room [09:31:21] =JeffH leaves the room [09:31:22] alexey.melnikov leaves the room [09:31:26] thanks to my many voices [09:31:27] thanks for participating [09:31:31] martin.thomson leaves the room [09:31:31] lef leaves the room [09:31:38] resnick leaves the room [09:31:43] EHL: I hope we were able to represent you accurately [09:31:48] yep [09:31:56] what time is it there?!? [09:31:58] who said I need to attend in person! :-) [09:32:02] 2:30am [09:32:04] we'll send you the bill later ... [09:32:05] yow [09:32:11] get some sleep [09:32:15] rlbob: send it to MS [09:32:42] rlbob leaves the room [09:33:13] yone leaves the room [09:33:41] yuioku leaves the room [09:33:47] ywang830 leaves the room [09:33:52] tlr leaves the room [09:33:52] the meeting is adjourned [09:34:09] EHL: thanks for participating remotely [09:34:39] EHL leaves the room [09:34:43] stpeter leaves the room: Disconnected: connection closed [09:34:52] Jacky Yao (Health Yao) leaves the room [09:35:05] tony.l.hansen leaves the room [09:37:09] harry leaves the room [09:40:23] sftcd leaves the room [09:41:53] Melinda leaves the room [09:46:53] spturner leaves the room [09:55:02] Kepeng Li leaves the room [10:02:52] Karen O'Donoghue joins the room [10:06:24] Karen O'Donoghue leaves the room [10:08:37] Melinda joins the room [10:10:29] Melinda leaves the room [10:13:07] ꈲ leaves the room [10:25:14] semery joins the room [10:29:38] semery leaves the room [10:32:47] Hugh_Daniel leaves the room [10:47:45] stpeter joins the room [10:50:06] stpeter leaves the room [10:50:57] ywang830 joins the room [10:55:19] ywang830 leaves the room [10:55:44] sftcd joins the room [10:59:49] sftcd leaves the room [11:00:42] Andrew joins the room [11:01:01] Andrew leaves the room [11:01:16] Simon Josefsson leaves the room [11:02:32] Jacky Yao (Health Yao) joins the room [11:06:44] =JeffH joins the room [11:16:39] =JeffH leaves the room [11:54:04] =JeffH joins the room [12:00:18] Jacky Yao (Health Yao) leaves the room [12:13:31] Jacky Yao (Health Yao) joins the room [12:26:54] Jacky Yao (Health Yao) leaves the room [13:26:44] =JeffH leaves the room