Subject: Re: [kitten] SASL OAuth: Next Steps

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 27 Dec 2011 11:25:57 +0100

Hi Simon,

 you raise an interesting point about the interaction between OAuth v1 and OAuth v2.

 Let us have a look at the architecture figure from the draft:

 ----+
 +--------+ +---------------+ |
 | |--(A)-- Authorization Request --->| Resource | |
 | | | Owner | |Plain
 | |<-(B)------ Access Grant ---------| | |OAuth
 | | +---------------+ |2.0
 | | |
 | | Client Credentials & +---------------+ |
 | |--(C)------ Access Grant -------->| Authorization | |
 | Client | | Server | |
 | |<-(D)------ Access Token ---------| | |
 | | (w/ Optional Refresh Token) +---------------+ |
 | | ----+
 | |
 | | ----+
 | | (Optional discovery) +---------------+ |
 | |--(1)------- User Name --------->| | |
 | Client | | | |
 | |<-(2)------ Authentication -------| | |
 | | endpoint information | Resource | |OAuth
 | | | Server | |over
 | |--(E)------ Access Token -------->| | |SASL/
 | | | | |GSS-
 | |<-(F)---- Protected Resource -----| | |API
 +--------+ +---------------+ |
 ----+

 The draft really only covers the interaction between the client and the resource server.
 Steps (1) and (2) are still sort of ideas rather than anything concrete given the status of the work in the OAuth WG.

 So, the draft focuses on presenting the token to a resource server (by the client) and to receive a response (potentionally an error).
 This is exchange (E) and (F) in the figure.

 Now, one can argue that there is similarity between OAuth v1 and v2 with regard to this step (if we believe in the idea that conveying the HTTP headers inside SASL will allow you to inherit all the functionality from the OAuth specification (such as the bearer token, the MAC authentication, or even the public key based version from OAuth v1).

 On the other hand you are right that these versions are substantially different and also the stuff that happens outside the context of the specification (namely the steps A-D) matter implementation wise since the code has to be there as well. So, the question shows up about how to indicate/communicate these feature and version differences. Interestingly, this is yet another issue that surfaced recently in the OAuth discussions under the topic of "mandatory-to-implement".

 In a nutshell, I don't really have a good response to you. If we switch to a JSON based encoding, as Leif had suggested, then the idea of simply inheriting the functionality from OAuth v1 and OAuth v2 does not work easily anymore and so the question does not show up. Whether this is a good thing or not I don't know. Your suggestion with being more precise about the supported functionality / version goes into a similar direction.

 Ciao
 Hannes

 > ----- Ursprüngliche Nachricht -----
 >
 > Von: Simon Josefsson
 >
 > Gesendet: 27.12.11 11:39 Uhr
 >
 > An: Tschofenig\, Hannes \(NSN - FI\/Espoo\)
 >
 > Betreff: Re: [kitten] SASL OAuth: Next Steps
 > "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
 > writes:
 >
 > > Hi all,
 > >
 > > Around IETF#82 I have submitted the SASL OAuth draft as a WG item. Here
 > > is the draft version:
 > > http://www.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt
 >
 > Thanks for this work, Hannes. I have been in a few discussions where
 > OAuth v1 vs v2 has been confusing -- the protocols are different and
 > incompatible. I think your document could be a bit more explicit that
 > it intends to work with OAuth version 2 only (I am assuming that this is
 > your intention -- correct me if I'm wrong) -- how about something like
 > this:
 >
 > OLD: (Title)
 > A SASL and GSS-API Mechanism for OAuth
 > NEW:
 > A SASL and GSS-API Mechanism for OAuth version 2
 >
 > OLD: (Abstract)
 > This document defines how an application client uses OAuth over the
 > Simple Authentication and Security Layer (SASL) or the Generic
 > NEW:
 > This document defines how an application client uses OAuth version 2 over the
 > Simple Authentication and Security Layer (SASL) or the Generic
 >
 > OLD:
 > application protocols.
 >
 > NEW:
 > application protocols. OAuth version 1 is not supported.
 >
 > OLD: (Introduction)
 > OAuth [I-D.ietf-oauth-v2] enables a third-party application to obtain
 >
 > NEW:
 > OAuth version 2 [I-D.ietf-oauth-v2] enables a third-party application to obtain
 >
 > OLD:
 > the focus is on an HTTP-based environment only.
 >
 > NEW:
 > the focus is on an HTTP-based environment only. Note that OAuth
 > version 1 is not supported.
 >
 > Or something like that.
 >
 > /Simon
 > _______________________________________________
 > Kitten mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/kitten