[12:58:12] joseph.yee joins the room [13:03:42] katrin joins the room [13:04:49] stpeter joins the room [13:05:28] stpeter has set the subject to: OAuth WG | https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ [13:13:07] weiber joins the room [13:15:07] sandoche joins the room [13:16:04] =JeffH joins the room [13:16:45] sandoche leaves the room [13:21:52] ray_atarashi joins the room [13:21:55] mtcarrasco joins the room [13:22:02] wolfgang.beck01 joins the room [13:22:06] JLCjohn joins the room [13:23:32] David Cooper joins the room [13:23:49] audio streaming at http://videolab.uoregon.edu/events/ietf/ietf784.m3u [13:25:32] Igor Faynberg @ mic [13:26:41] sandoche joins the room [13:26:57] wilmer joins the room [13:27:05] https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth/ [13:27:33] Sampo Kellomäki @ mic [13:28:30] spturner joins the room [13:30:52] Igor: I think the use cases are lagging the protocol, and Zachary wants to fix that by updating his document soon [13:31:26] Hannes: mentioned https://datatracker.ietf.org/doc/draft-hardjono-oauth-kerberos/ [13:32:07] also mentioned https://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ [13:32:34] yoiwa joins the room [13:34:02] Torsten at the mic [13:34:08] would like to discuss oauth discovery [13:34:20] tlyu joins the room [13:34:56] tifflen joins the room [13:35:19] Torsten.... [13:36:32] Aaron Stone joins the room [13:36:38] (1) how does the client discover authorization server? [13:36:43] jabber-wile joins the room [13:36:49] semery joins the room [13:36:57] resnick joins the room [13:37:16] (2) how does client discover end point and capabilities of authorization server? [13:37:32] (3) discover capabilities of resource server [13:38:08] Hannes: do you have a proposal? [13:38:15] Torsten: no, only requirements [13:39:00] Torsten proposes finding a way to split up the server discovery with the endpoint discovery. [13:39:58] possible to use webfinger [13:40:08] Hannes discusses WebFinger as a possible mechanism for doing these discoveries. [13:40:30] http://code.google.com/p/webfinger/ [13:40:37] A Well-Known URI is registered, "host meta" [13:40:57] https://datatracker.ietf.org/doc/draft-hammer-hostmeta/ [13:41:09] tlr joins the room [13:41:30] dthaler joins the room [13:42:46] Sampo: assumption of globally unique user ID? [13:45:31] Aaron Stone at the mic [13:45:56] talking about web user flow [13:46:19] http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-1.4.1 [13:47:44] Torsten: resource server should be first step [13:52:20] Torsten will work on a document or list post about discovery [13:54:03] semery leaves the room: Disconnected [13:54:25] TL: is there an assumption about how many resource servers can be serviced by an authorization server [13:54:39] ^ open issue [13:55:24] Sampo: overview figures are not consistent [13:56:04] specifically: labels (a) - (f) (or other last letter) are different in each diagram [13:56:27] also that each diagram does not have all of the same flow points identified [13:56:59] unclear if it is because different names are being used, or if the actions are actually different in each scenario. [13:57:59] TL: Section 1.4.2 [13:58:30] https://datatracker.ietf.org/doc/draft-abarth-origin/ [13:58:47] TL: what does "These clients cannot keep client secrets confidential and the authentication of the client is based on the user-agent's same-origin policy." mean? [14:00:20] ekr: 1.4.1 is confusing because "web client" sounds like a browser [14:01:11] EKR: "web client" to most people means a browser. but in this document, it means the web server with the cool feature that wants access to your cool photos on resource server. [14:01:33] =JeffH leaves the room [14:01:59] Sampo: so really, who initiates the flow, the user at the browser, or the site that wants access to the data? [14:03:20] EKR said "maybe ladder diagrams would help" [14:03:49] =JeffH joins the room [14:04:06] EKR volunteers to help update the documents. [14:04:29] martin.thomson joins the room [14:05:17] HT: are people interested in all the flows, or mainly web server? [14:05:25] lellel joins the room [14:06:04] Sampo: interested "back channel" flow, similar to Native Application [14:06:07] Klaas Wierenga joins the room [14:06:37] Section 2 [14:06:52] Torsten: what is meant by "[[ OAuth Discovery provides one way of obtaining a client password ]]" [14:06:59] HT: that should be removed [14:09:12] Uli joins the room [14:09:22] StPeter: seems like many in the IETF would like to see non-password authentication mechanisms, SAML, for example [14:09:34] XML-Source can be fount here: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ [14:11:00] Myself: nit: in Section 2.1, the caption of the figure says, "line breaks are for display purposes only", however the only line breaks shown are those natural to HTTP. [14:11:27] richard.barnes joins the room [14:11:30] The figure could be made more clear by breaking up the url-formatted content with line breaks that are marked as not-really-there. [14:12:02] <=JeffH> so are any of the spec co-authors at least here in the jabber room ? [14:12:38] do we not assume that the client and server already have a pre-arranged authentication agreement? Such would be necessary to establish user/pw [14:13:49] torsten: the web server flow and the end user flow both use the same authorization endpoint. perhaps we should split these up. [14:16:29] (i didn't fully understand this:) note that in web server flow and user agent flow, only one needs an additional authorization token to exchange for access token. [14:17:58] use case can be authorizing a mobile device from a primary computing device, e.g. mobile phone receives authorization via end user's web browser on a laptop. [14:18:47] to Aaron's nit (16:11): display-only line-break in Sec2.1 appears in the content body. [14:21:18] yoiwa: thank you, i simply assumed line wrapping and did not think that text was describing the line wrap. so, i suggest to the author either to specify that it's just line wrapping, or to actually insert extra line breaks to make the url encoding easier to read by a human. [14:22:37] Harald Alvestrand @ mic [14:22:50] Harald: "don't put a MUST in there that you cannot test." [14:23:26] HA: say something like "the client can assume..." [14:23:41] on that point, there are a few other MUSTs that appear as existence tests, you should instead say what you expect an entity to emit, or accept [14:24:10] =JeffH: no, and I don't see any of them online either [14:24:11] Harald suggests to document what an assumption is, but not to require it. This is regarding Section 4, "If the access grant being used already represents an approved scope (e.g. authorization code, assertion), the requested scope MUST be equal or lesser than the scope previously granted." [14:25:52] Torsten: question regarding error codes. There's an Unauthorized Client error code, in conjunction with HTTP 400. Why not HTTP 403? [14:25:55] why do we have a mix of application/json and application/x-www-form-urlencoded? [14:26:05] BTW http://tools.ietf.org/html/draft-hardjono-oauth-kerberos-00#section-3.5 has some helpful recommendations [14:26:23] martin: that's a good point, lemme channel you [14:26:27] thanks [14:29:34] multiple encodings is not good for interoperability [14:30:12] thanks to sampo for saying that! [14:30:16] Sampo: how can achieve interop? [14:30:19] martin.thomson: :) [14:34:07] I hope that messing with tokens doesn't invalidate any security protections, rather it voids any hope of using the token to access anything [14:34:26] understanding the source and sink of each parameter might help [14:38:30] self: advocates explicitly stating that tokens are opaque with respect to oauth, but might have special meaning to the services which generate those tokens. [14:39:11] self: advocates explicitly stating urlencoding, and/or other encoding (e.g. json). [14:40:54] torsten: back on the topic of error codes: either fully utilize HTTP status codes, e.g. 401, 403, etc., or fully tunnel, with HTTP 200 for all responses, and error codes specified in the body for the client to interpret. [14:40:56] tlr leaves the room [14:41:15] spturner leaves the room [14:42:03] that was Martin at the mic [14:42:31] his point point was, we're tunneling and should just admit that (even if some of us don't like it) [14:42:43] tlr joins the room [14:43:41] torsten: section 5: what is an unfamiliar resource server? [14:43:51] hta joins the room [14:47:40] characterize what properties you expect from the "secure" channel [14:48:01] Yuri Demchenko @ mic [14:48:05] yuri: why shouldn't access tokens be sent in the clear over an unsecured channel? [14:48:21] hannes: because you just shouldn't do that! [14:48:43] shoiuld not MUST be explained... [14:49:17] ekr: SHOULD NOT isn't good enough for me, it needs to be MUST NOT, and we need to require TLS. [14:49:53] ekr: it cannot be the case that you are sending reusable credentials over the network in the clear. [14:50:50] hannes: counter argument is a url for mailing list subscription. often there's a one-time-use or limited-time-use token in the url, and there's no problem accessing that over HTTP insecure. [14:51:17] ray_atarashi leaves the room [14:51:31] Lucy Lynch @ mic [14:51:35] weiber leaves the room [14:53:00] so if this token is sensitive, require secure channel. if it's not sensitive, explicitly state so; make sure authorization services are aware that these tokens are considered non-sensitive, lest they expose anything within their token format. [14:54:40] Sampo @ mic [14:54:58] Sampo: just bearer token is good for me [14:55:12] Torsten: in favor of bearer tokens for simplicity [14:56:25] resnick leaves the room [14:56:46] resnick joins the room [14:57:00] martin.thomson leaves the room [14:59:26] Yuri and Torsten remind that token revocation is important, and remains an open issue. [15:00:19] richard.barnes leaves the room [15:00:41] resnick leaves the room [15:00:50] Uli leaves the room [15:01:16] lellel leaves the room [15:01:25] katrin leaves the room [15:01:27] ekr asks if revocation refers to, say, a web site giving the end user access to some page that lists the third-party applications that have received access tokens, and the ability to individually reject those. room says yes. [15:01:30] hta leaves the room [15:01:37] wolfgang.beck01 leaves the room [15:01:43] tifflen leaves the room [15:01:57] mtcarrasco leaves the room [15:02:16] sandoche leaves the room [15:03:03] taking a 10 minute break here [15:04:31] Bearer tokens are good, but I have a small concern that the current "naked" bearer-token format which makes it difficult to extend in future (e.g. use signed token for specific purposes with suppliment specifications). I personally prefer token="xxxxx" format. [15:05:06] yoiwa leaves the room: I'm happy Miranda IM user. Get it at http://miranda-im.org/. [15:06:50] spturner joins the room [15:07:09] Klaas Wierenga leaves the room: Disconnected. [15:11:15] =JeffH leaves the room [15:11:46] dthaler leaves the room [15:13:32] martin.thomson joins the room [15:13:46] jabber-wile leaves the room [15:15:33] we are now back in session [15:15:37] and we have a whiteboard! [15:15:46] ekr is at the wireless mic. [15:15:54] yoiwa joins the room [15:16:07] hannes calls up section 1.4.1 on screen. [15:16:39] ekr is not excited about the new terminology in use in this iteration of the document. [15:16:53] joseph.yee leaves the room [15:17:19] ekr, "i hated the oauth 1 terminology, i think i hate this terminology even more" [15:18:08] tom yu: what caused the term consumer to be removed? [15:18:20] weiber joins the room [15:18:29] shout in back of room: "consumers are humans and clients may not be" [15:19:55] ekr is drawing the diagram from section 1.4.1 on the whiteboard, plus the missing box from 1.4.1, the resource server. [15:21:04] tlr leaves the room [15:21:13] ekr is gathering proposals for another name for the "web client" [15:23:30] EHL joins the room [15:24:43] stpeter has set the subject to: OAuth WG | https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ | http://videolab.uoregon.edu/events/ietf/ietf784.m3u [15:25:08] Klaas Wierenga joins the room [15:25:16] Klaas Wierenga leaves the room [15:25:23] sm joins the room [15:26:35] "swim lane" smells like UML terminology :-) [15:26:36] room looking at diagram in section 1.3, notes that "resource owner" might be the human user. [15:26:53] wants to see diagrams that involve the human user to make that human user primary. [15:27:34] hta joins the room [15:28:22] paul hoffman and st peter state: let us not build these diagrams in committee; let's go through them to make sure they make sense, but let's not draw them here. [15:29:18] 'resource owner' isn't always a human [15:29:33] joseph.yee joins the room [15:29:45] there is a reason why we have both terms [15:30:02] only the authorization endpoint is limited to end-user - a human [15:30:12] weiber leaves the room: Replaced by new connection [15:30:15] weiber joins the room [15:31:00] Geoff Thompson pointing to Figure 1 [15:31:32] eliot.lear joins the room [15:31:33] "Figure 1: Abstract Protocol Flow" [15:35:37] =JeffH joins the room [15:35:46] spturner leaves the room [15:44:22] joseph.yee leaves the room [15:46:10] joseph.yee joins the room [15:46:46] David Cooper leaves the room [15:47:02] richard.barnes joins the room [15:47:03] we may have decided upon a new set of names [15:47:07] there is a user, the human user [15:47:16] a user-agent, the user's web browser [15:47:31] a resource consumer, the web site that wants access to your data [15:47:46] an authorization server, that controls the credentials [15:47:56] sm leaves the room [15:47:57] and a resource server, that is hosting your data [15:49:25] stpeter notes that oauth 1.0 community edition called the "web client" the "consumer", but then oauth 1.0 rfc changed the name to "web client". [15:50:00] ekr says, "ok, let's try rewriting with this terminology, and see if it reads better" [15:50:49] torsten says, "ok, in the native application case, which is the user agent and which is the resource consumer?" [15:51:08] martin: the native application is the resource consumer, and the user agent remains a web browser. [15:56:01] tlr joins the room [15:56:16] spturner joins the room [15:57:14] eliot.lear leaves the room [15:57:17] lef joins the room [15:59:12] self and ekr converse about the diagram ekr is drawing [15:59:31] it is now labelled, "javascript app running in the browser" [16:00:06] ekr notes that another box is needed: the site that hosts the javascript which is requesting access, and to which that javascript has same-origin-policy access. [16:02:08] ekr also notes that if the javascript only has same-origin access to the site hosting it, then it cannot directly use the token it receives to talk to the resource server. i note that the hosting site could mediate that access, wonder how the scenario now differs from the mainline case. [16:02:51] i note that the security context of the javascript is important: it cannot have dom-level access to the actual password box you're about to type your password into, otherwise this is all for nought. [16:03:13] martin.thomson leaves the room [16:03:16] spturner leaves the room [16:03:46] spturner joins the room [16:03:53] user-agent flow was proposed by FB and supported by Twitter [16:04:46] richard.barnes leaves the room [16:05:09] richard.barnes joins the room [16:07:33] eliot.lear joins the room [16:08:09] user-agent flow does not require client secret [16:08:20] and token comes back immediately [16:08:47] i note that the native application and the embedded javascript are inverses of one another, and the main issues are mostly implementation notes: if the native application utilizes an embedded browser, it can see inside that process to get at the password, while if the embedded javascript can see "above" itself, it could also see the password being typed in. [16:08:54] Eran: I'll channel that. [16:08:58] oh wait, we're at time. [16:09:21] weiber leaves the room: offline [16:09:29] eliot.lear leaves the room [16:09:34] EHL leaves the room [16:09:37] stpeter gives closing notes [16:10:29] yoiwa leaves the room: I'm happy Miranda IM user. Get it at http://miranda-im.org/. [16:11:16] lef leaves the room [16:11:47] =JeffH leaves the room [16:12:22] joseph.yee leaves the room [16:12:53] tlr leaves the room [16:13:20] Aaron Stone leaves the room [16:14:19] stpeter leaves the room: Logged out [16:14:24] hta leaves the room [16:20:00] JLCjohn leaves the room [16:22:32] richard.barnes leaves the room [16:24:16] spturner leaves the room [16:26:41] richard.barnes joins the room [16:36:32] richard.barnes leaves the room [16:41:59] tlr joins the room [17:00:09] tlr leaves the room [20:33:40] lef_jp joins the room [20:38:25] lef_jp leaves the room [20:50:01] tlr joins the room [21:16:22] Aaron Stone joins the room [21:16:22] tlyu leaves the room [21:36:49] tlr leaves the room [23:49:38] Aaron Stone leaves the room