Subject: [kitten] SASL OAuth: Next Steps
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
To: <[email-masked]>
Date: Tue, 20 Dec 2011 11:36:19 +0200
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>

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