Skip to main content

Minutes for OAUTH at interim-2013-oauth-2
minutes-interim-2013-oauth-2-1

Meeting Minutes Web Authorization Protocol (oauth) WG
Date and time 2013-01-21 08:00
Title Minutes for OAUTH at interim-2013-oauth-2
State Active
Other versions plain text
Last updated 2013-01-24

minutes-interim-2013-oauth-2-1
OAuth Conference Call - 21th Jan 2013

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

Notes:

Hannes used the following slides for the meeting:
http://www.tschofenig.priv.at/OAuth2-Security-21Jan2013.ppt

As a first agenda item Justin explained two scenarios posted to the OAuth
mailing list in response to the December 2012 conference call:
http://www.ietf.org/mail-archive/web/oauth/current/msg10407.html

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.