MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Date: Tue, 20 Dec 2011 11:36:19 +0200
Message-ID: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net>
Thread-Topic: SASL OAuth: Next Steps
Thread-Index: Acy++tRCaIv87RfyRzu6nB9TBbGyCQ==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: <kitten@ietf.org>
Subject: [kitten] SASL OAuth: Next Steps
Precedence: list

Hi all,=20

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.=20

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.=20

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.=20

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.=20

Here is an example from the current draft version:

---------------
   GET / HTTP/1.1
   Host: imap.example.com
   Authorization: BEARER =
"vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=3D=3D"
---------------

A possible JSON based representation would be:
---------------
   {"token-type":" BEARER",=20
    "token":" vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=3D=3D"}
---------------
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.=20

In any case, I believe Leif's suggestion is good. I wonder what others
think about it. =20

Ciao
Hannes