[OAUTH-WG] draft minutes of OAuth WG interim meeting, 2010-01-21

[Peter Saint-Andre <[e-mail]>]

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!

========================================================================