OAUTH 2 for SASL

Monday – Session 5 - I

Convener: Bill Mills, Allen Tom, Joseph Smarr

Notes-taker(s): Bill Mills

A. Tags for the session - technology discussed/ideas considered:

B. Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Extended discussion will continue at http://tech.groups.yahoo.com/group/sasl_oauth/

The proposed spec is at http://docs.google.com/View?id=dhjg77m3_0gsn2psdq

We walked through various parts of the proposed spec. There were questions about how it fits in and how SASL fits in to other protocols. The general feeling was it's better to use SASL than to implement OAuth separately in each protocol.

It was pointed out that the IETF drafts:

   draft-lear-ieft-sasl-openid-01.txt
   draft-wierenga-sasl-saml-00.txt

Both will have useful as they are very similar problems.

Interesting questions asked:

How do we sort out what OAuth 2.0 auth flows are supported? Much of this may shake out in the OAuth 2.0 discovery information stuff. If not, then the SASL spec should patch this up until OAuth 2.0 gets there?

Is there anyone out there that want's to do OAuth 1.0a over SASL or will you just go to 2.0 to get SASL? Consensus was that everyone will go to 2.0.

There was a lot of discussion around the question of taking an OAuth token and authenticating a session with it, and the implications of that. Major points of concern still to be hashed out are:

What if you us OAuth an XMPP session that allows password change? Should sessions be limited to token life/expiration? How does does a desktop client get a client_id and secret when desktop clients can't really keep a secret?

Quite a bit of good feedback.