These are draft minutes of the OAuth WG's interim meeting held via WebEx on 2010-01-21. Please send corrections to the chairs, Blaine Cook and Peter Saint-Andre. Many thanks to Eve Maler for scribing.
======================================================================== OAuth WG Minutes of Interim Meeting, 2010-01-21 Chairs: Blaine Cook and Peter Saint-Andre Scribe: Eve Maler Minutes Editor: Peter Saint-Andre Agenda: http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html Audio: https://workgreen.webex.com/workgreen/lsr.php?AT=pb&SP=MC&rID=3662907&rKey=39ebc5009f8c0b12 Dramatis Personae (people who spoke during the meeting): Richard Barnes Blaine Cook Lisa Dusseault Dick Hardt Eve Maler Peter Saint-Andre Hannes Tschofenig Many other attendees, but no "blue sheets" to provide a record. ======================================================================== AGENDA 1. Introduction (5 minutes) a. NOTE WELL applies to interim meetings! http://www.ietf.org/about/note-well.html b. Welcome from the chairs c. Volunteer to scribe Eve Maler volunteered, many thanks! b. Agenda bashing Dick: Get clarity around authentication, authorization, web delegation concepts, and why specs are broken out the way they are. Blaine: Much debate in the past. Authentication is sending request with authn information saying "This is a request that is being made by token x." Authorization is the issuance of that token, and a successful request using that token once you have it. Dick: This is confusing. There's authn, and then there's "authentic authorization". The token is used to make an authorizing decision. Blaine: Just reporting OAuth community usage. Richard: (missed) Hannes: Ideal to reuse terms from other communities. E.g., see Handbook of Applied Cryptography. Blaine: Given the confusion around, let's clarify in the draft. Peter: Let's give Eran an action item to do this! :-) 2. Goals of the Interim Meetings (5 minutes) a. Accurately describe the problem space b. Gather scenarios / use cases / profiles c. For authentication, reach *rough* consensus d. For authorization and delegation, determine roughly which aspects are "core" and which are "extensions" e. Make significant progress before IETF 77 in Anaheim f. Any others? Peter: Blaine, Eran, I and others have talked about what to accomplish before Anaheim. WRAP, UMA efforts provide new input to "OAuth V2.0" effort. OAuth V1.0 problems have been identified. Problem space has shifted and expanded. Things like splitting out authorization servers have come to the fore. Clarifying architectural pieces, entities, and terminology would be good. Hannes: Originally wanted to quickly go through some open issues and be done with it, but then learned about WRAP and UMA. We have a thicket of use cases, some contradicting. E.g., simple extensions taken as a whole make things complicated. Liberty Alliance didn't stay focused enough and produced something complex. WRAP spec is easy to understand and is a little bit like Kerberos. Peter: Once a new tool is available, people start using it for more things. Can we factor out the common features of all those ideas? Hannes: Scenarios don't need to be a published RFC -- takes too long -- but it makes sense to do this factoring. Peter: Many people thought OAuth V1.1 would be easy and quick. So the idea is to deliberately do use case work to guide the scope expansion. Eve: UMA will submit use cases to this community shortly. Peter: The WRAP work that people like Dick, David, Allen, and Brian have done could be seen from one angle -- the profile work -- as use cases. Dick: WRAP motivations were looking at OAuth and giving it slightly different architectural parameters in solving similar design patterns. E.g., at scale, it helps to let the protected resource work with an authorization server. And using TLS as an alternative. Agrees with the idea of using a process to collect use cases. Taking into account implementation and deployment effort is good. WRAP can work well for people who have SSL, and original OAuth can work well when SSL isn't available. Existing libraries for OAuth are still there. Architecturally, OAuth and WRAP are quite different. In WRAP, the client gets a token directly from the authorizing server. Eve: Useful to see the use cases for each difference, to understand the benefit of each. E.g., SSL provides channel security but not data origin authentication. Peter: Using the photo site/photo printing example, there are only simple access choices. But if the protected resource (WRAP term) has a number of possible actions on it, the scope of authorization may need to be more sophisticated. Maybe those solutions need to be extensions on top -- or not. Blaine: Maybe do a feature matrix of what each of us thinks our protocol supports, then as a community build a common understanding. Eve: FWIW, here is the UMA technology comparison matrix: http://kantarainitiative.org/confluence/display/uma/Technology+Matrix No WRAP column yet. Note that UMA layers on top of three OAuth instances, "using" OAuth rather than being an alternative. If more functionality sediments down, that's great. ?: Security features are hard to argue about, because it depends so heavily on deployment details. Channel security can be there at a lower layer, but data origin authentication happens at a higher layer. Peter: Use cases are therefore critical. Eve: Yes, use "agile specification" to ensure each feature can be traced back to solving a use case. ?: At what level to specify use cases? The photo example is so broad it can accommodate lots of solutions. Peter: SSL isn't a use case. :-) Hannes: Assumptions such as having certificates available can be baked into use case alternatives. E.g., if you have an iPhone app with certain constraints, that motivates the use case sufficiently. [following agenda items covered above or delayed until next meeting] 3. Problem Space (10 minutes) a. Need a clearer definition of what we're trying to solve b. Has the problem shifted since OAuth 1.0? c. What problem are we solving now? d. Can we settle on consistent terminology, please? :) e. Architecture matters 3. Scenarios (15 minutes) a. Core scenarios, see draft-ietf-oauth-web-delegation-01 b. Scenarios from WRAP, see draft-hardt-oauth-01 c. Scenarios from User Managed Access (UMA), I-D on the way? d. How can we gather other scenarios? 6. Authentication (10 minutes) a. draft-ietf-oauth-authentication b. Open issues 7. Authorization and Delegation (10 minutes) a. What is core? b. What can we define as extensions? 8. Action Items (5 minutes) a. Gather more scenarios b. Review draft-ietf-oauth-authentication and work through remaining issues c. Input on authorization and delegation d. Time of next interim meeting Peter: What are next steps and action items? Rough consensus: Get more scenarios, use cases, and profiles on the table, and discuss further what level they should be at. Also, let's put together a matrix. Dick: Let's also get agreement on terms, so we can avoid confusion in the matrix. All: Agree! Richard: Is the goal to allow a user to delegate access to a resource? Is this the common thread? Dick: No, it's not. Peter: Why not? Dick: The first two WRAP profiles, where the client is acting autonomously, don't match that description. Eve: And the classic two-legged flow also differs. Is that on the table for OAuth V2.0? Paul: The "two-legged" flow is still to get an access token provisioned, so it might utilize the whole delegation flow but apply to an autonomous client. JeffH: Don't use "legs"; those refer to a flow diagram. Blaine: And depending on the "legs", you could have flows with a consumer token and no user token, and vice versa. So those are two separate use cases to consider. Dick: This is all why we see the use cases as broader than "user delegation". And BTW, we need clarity on token terminology! Peter: There's a plethora of authentication technologies, so I'm leery of offering OAuth as YAAT. If HTTP needs some better options, this seems to be where Eran was going with his authn draft. That's all okay, but let's be clear if we're doing that. The registration aspect is also interesting; IETF hasn't developed anything like this. In addition to the traditional delegation flows, let's figure out the true value of the underlying functions that are part of OAuth. Lisa: The OAuth BOF seemed to show that the HTTP group has a pent-up desire for better authentication options, and this would be valuable to do. Patching SASL onto HTTP has seen enormous work, but has failed. A limited-scope task of binding a well-known authentication mechanism to HTTP, improving on Basic and Digest, would be welcomed. Peter: Agreed. At this point, chairs will drill down on action items for terminology, matrix, etc. The group can use the wiki for some of this work. Meetings need two-week notice, so we'll meet again in two weeks. The current plan is to hold the next meeting on February 4. http://trac.tools.ietf.org/wg/oauth/trac/wiki Blaine: There are people not on today's call who would be good to have on future calls. Maybe we can do a Doodle poll to pick a better time. Peter: Spoke to a number of folks who simply couldn't make it this time, including Eran. Thanks to those who have contributed to date! All: Meeting was helpful and productive. Thanks! ========================================================================
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
