[OAUTH-WG] Minutes from the Conference Call (21th Jan. 2013)

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 25 January 2013 07:47 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5DC4221F8A98 for <oauth@ietfa.amsl.com>; Thu, 24 Jan 2013 23:47:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.952
X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6CHDtv3HtQxP for <oauth@ietfa.amsl.com>; Thu, 24 Jan 2013 23:47:25 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net []) by ietfa.amsl.com (Postfix) with ESMTP id 3655121F8578 for <oauth@ietf.org>; Thu, 24 Jan 2013 23:47:24 -0800 (PST)
Received: from mailout-de.gmx.net ([]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M7WX3-1UurV641GJ-00xIvS for <oauth@ietf.org>; Fri, 25 Jan 2013 08:47:23 +0100
Received: (qmail invoked by alias); 25 Jan 2013 07:47:23 -0000
Received: from unknown (EHLO []) [] by mail.gmx.net (mp016) with SMTP; 25 Jan 2013 08:47:23 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/7+uYaJjb7qhSYdhH3w5jfuSZ1ABeJMWpaUL7P5S HIVsDjTDewxa3o
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 25 Jan 2013 09:47:22 +0200
Message-Id: <5B3AB251-BF88-4AC4-AB15-F6A9E85DC294@gmx.net>
To: "oauth@ietf.org WG" <oauth@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Minutes from the Conference Call (21th Jan. 2013)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jan 2013 07:47:29 -0000

Here are the minutes from the call:

Here are the uploaded slides: 


OAuth Conference Call - 21th Jan 2013

- Hannes Tschofenig
- Justin Richer
- Phil Hunt 
- Prateek Mishra
- Derek Atkins
- Mike Jones
- John Bradley
- Tony Nadalin
- Brian Campbell


Hannes used the following slides for the meeting:

As a first agenda item Justin explained two scenarios posted to the OAuth mailing list in response to the December 2012 conference call:

The first scenario focused on the usage of a keyed message digest in HTTP (instead of using JSON). The second scenario was based on placing all MAC parameters into the URL (instead of the header). 

The participants indicated that further thinking about the inclusion of these scenarios is needed. 

A few clarification questions were raised including whether the solutions we are working on would require always a signature/keyed message computed over some portion of the request, and whether key distribution is within scope of the work or not.

Hannes clarified that the work is aiming to provide security properties beyond the bearer token and therefore the client needs to demonstrate possession of a session key. The available options for key distribution were described as part of the presentation slides. 

Q: What about clients that are either not capable of doing cryptographic operations (because they are computationally not powerful enough) or when they do not have access to keying material?

Hannes and Derek clarified that those scenarios are outside the scope of this work. 

As part of the different options for key distribution only Justin raised his preference for a solution that requires the RS to obtain the session key from the AS. 

The conference call participants agreed to focus on a symmetric key based solution and to postpone a solution offering support for asymmetric keys at a latter stage. 

Phil asked whether we really need both replay protection AND message signing?  

Hannes responded that support for replay protection has to be part of the solution. 

Regarding the lifetime of the session key the participants preferred to have it set to the same lifetime as the access token. If a new access token is obtained then the session key is also renewed.  

Regarding the naming of the keying material used in the protocol exchange there were some diverse views on what to use for the session key. Justin suggested that the name of the session key is the access token itself.