[kitten] SASL OAuth: Next Steps

"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Tue, 20 December 2011 09:36 UTC

Return-Path: <hannes.tschofenig@nsn.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3CD21F8B16 for <kitten@ietfa.amsl.com>; Tue, 20 Dec 2011 01:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level:
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKGNyXiC3yK4 for <kitten@ietfa.amsl.com>; Tue, 20 Dec 2011 01:36:28 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4C52221F8AF8 for <kitten@ietf.org>; Tue, 20 Dec 2011 01:36:27 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBK9aOfe006620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <kitten@ietf.org>; Tue, 20 Dec 2011 10:36:26 +0100
Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBK9aJ9O027700 for <kitten@ietf.org>; Tue, 20 Dec 2011 10:36:24 +0100
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 10:36:23 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
x-cr-puzzleid: {0F59FB4D-37BC-48F4-8FAF-E7644951B572}
x-cr-hashedpuzzle: LyA= B6iR DPlF EDmR EIeb FGsq GXK8 HSSk HTas IRPl IhrF I4yY Jxvo J5OR LAnv LUNP; 1; awBpAHQAdABlAG4AQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {0F59FB4D-37BC-48F4-8FAF-E7644951B572}; aABhAG4AbgBlAHMALgB0AHMAYwBoAG8AZgBlAG4AaQBnAEAAbgBzAG4ALgBjAG8AbQA=; Tue, 20 Dec 2011 09:36:19 GMT; UwBBAFMATAAgAE8AQQB1AHQAaAA6ACAATgBlAHgAdAAgAFMAdABlAHAAcwA=
Content-class: urn:content-classes:message
Date: Tue, 20 Dec 2011 11:36:19 +0200
Message-ID: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: SASL OAuth: Next Steps
Thread-Index: Acy++tRCaIv87RfyRzu6nB9TBbGyCQ==
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: kitten@ietf.org
X-OriginalArrivalTime: 20 Dec 2011 09:36:23.0992 (UTC) FILETIME=[D6B0E380:01CCBEFA]
Subject: [kitten] SASL OAuth: Next Steps
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2011 09:36:29 -0000

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