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

From: Simon Josefsson <[email-masked]>
Date: Tue, 27 Dec 2011 10:39:12 +0100

"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

---

From: William Mills <[email-masked]>
Date: Tue, 27 Dec 2011 08:46:11 -0800 (PST)

In fact, as written, there's nothing that prevents supporting an OAuth 1.0a authentication to the RP, but the discovery stuff is incompatible.  I don't want to write out OAuth 1.0a because extant server-to-server solutions could migrate to this SASL mechanism, although this could be a veyr small number in fact and maybe it isn't worth it.

________________________________
 From: Simon Josefsson <[email-masked]>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]> 
Cc: [email-masked] 
Sent: Tuesday, December 27, 2011 1:39 AM
Subject: Re: [kitten] SASL OAuth: Next Steps

OLD: (Title)

OLD: (Abstract)

OLD:
    application protocols.

NEW:

OLD: (Introduction)

NEW:

OLD:

NEW:

Or something like that.

/Simon
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Dec 2011 10:15:08 +0200

There are two design approaches, as I tried to explain in my earlier 
cryptic writeup.

1) Assume that all you need to specify is the exchange of the OAuth 
token and the rest is outside the scope of the specification.

This approach had, for example, been chosen by RFC 5878 where an 
extension to TLS had been defined to carry SAML assertions and other 
tokens. The document does not explain where the TLS client gets these 
assertions from.

Also SASL OAuth follows this approach and so does XMPP OAuth, see 
http://xmpp.org/extensions/xep-0235.html

2) Assume that you also want to standardize how the client obtains the 
token in addition to the mechanism to present it to the server.

This approach is used, for example, with SASL SAML, see 
http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml/, and SASL 
SAML-EC, http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/.

The main question is: What level of interoperability we you want to 
accomplish?

With (1) a client A may use protocol Foo to obtain a token and client B 
may use a different protocol, called Bar, to also obtain a token. Both 
interoperate nicely nicely with a server that understands how to receive 
tokens. Obviously, a random client implementation will not manage to get 
a token in every environment. Imagine that a client uses a library that 
only works with OAuth v1 code and the authorization server speaks only 
OAuth v2 then the entire procedure will of course fail.

(2) is a restricted version of (1) that defines more than just the 
client to protected resource server exchange.

Which approach is better? Hard to say.

A possible middleground is to standardize (1) in addition to "profiles" 
for (2). For example, when a plain exchange of the OAuth token is 
defined with (1) then one could also pick a common way for obtaining 
tokens with, let's say, OAuth 2.0, and describe all the details. That 
description could even go further by looking into a specific application 
protocol usage (such as SASL within IMAP).

Ciao
Hannes

On 27.12.2011 18:46, William Mills wrote:
> In fact, as written, there's nothing that prevents supporting an OAuth
> 1.0a authentication to the RP, but the discovery stuff is incompatible.
> I don't want to write out OAuth 1.0a because extant server-to-server
> solutions could migrate to this SASL mechanism, although this could be a
> veyr small number in fact and maybe it isn't worth it.
>
> ------------------------------------------------------------------------
> *From:* Simon Josefsson <[email-masked]>
> *To:* "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
> *Cc:* [email-masked]
> *Sent:* Tuesday, December 27, 2011 1:39 AM
> *Subject:* Re: [kitten] SASL OAuth: Next Steps
>
> "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]
> <mailto:[email-masked]>>
> writes:
>
>  > Hi all,
>  >
> [email-masked] <mailto:[email-masked]>