Subject: [kitten] SASL OAuth: Next Steps

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 20 Dec 2011 11:36:19 +0200

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

At the KITTEN IETF#82 meeting I gave a presentation illustrating the
recent changes and I also listed the open issues. Here are the slides:
http://www.ietf.org/proceedings/82/slides/kitten-1.pdf

The slides illustrate the design choices of how OAuth messages are
integrated into SASL. 

Last week I attended an identity management workshop organized by ISOC
and I met Leif there. I used the opportunity to chat with him about the
feedback he gave during the IETF meeting. 

I would need your feedback on the following important design decision.
Currently, the OAuth messages are encoded as HTTP headers and Leif had
suggested to instead use a JSON encoding. 

The benefit is that we do not need to incorporate HTTP-specific aspects
that are not relevant to the task at hand, the specification becomes
clearer and easier to make an analysis of what parts a relevant to our
task. 

Here is an example from the current draft version:

---------------
   GET / HTTP/1.1
   Host: imap.example.com
   Authorization: BEARER "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=="
---------------

A possible JSON based representation would be:
---------------
   {"token-type":" BEARER", 
    "token":" vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=="}
---------------
In my made-up example I define two attributes: a token container and a
token type attribute. The accessed resource is most likely in the
protected token itself and is additionally carried in the underlying
transport mechanism and therefore not needed again. 

In any case, I believe Leif's suggestion is good. I wonder what others
think about it.  

Ciao
Hannes

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Dec 2011 09:39:24 -0700

> clearer and easier to make an analysis of what parts a relevant to our

Ciao Hannes,

I'm working to get people in the XMPP community interested in an OAuth2
mechanism for SASL, so I am in favor of providing a separation from the
underlying data transfer protocol.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: William Mills <[email-masked]>
Date: Tue, 20 Dec 2011 08:56:32 -0800 (PST)

The choice to use HTTP format here means that any new OAuth 2 enabled auth profile is supported without having to define a new mapping.  We don't have to do anything in this spec to support a new profile.  If we decide on JSON encoding we then have to define how the mapping will work, and we have to make sure it will be robust enough to survive anything new.

If this were independent of other specs HTTP would be a very poor format choice.  Since it would be possible for OAuth 2 authentication enabled HTTP auth methods to use other headers for example, I think simply leaning directly on those specifications is cleanest.

-bill

________________________________
 From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
To: [email-masked] 
Sent: Tuesday, December 20, 2011 1:36 AM
Subject: [kitten] SASL OAuth: Next Steps
 
Hi all, 

---------------
   GET / HTTP/1.1
   Host: imap.example.com

Ciao
Hannes

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