Subject: [OAUTH-WG] Meeting Notes: 14th December 2012 Conference Call

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 16 Dec 2012 21:23:27 +0200

Hi all, 

here are my notes from the conference call:

---

Date: 14th December 2012

Participants:
 * Derek Atkins
 * Mike Jones
 * Phil Hunt
 * Justin Richer
 * Hannes Tschofenig
 * Thomas Hardjono
 * William Mills

I started the call with a presentation of these slides. 
http://www.tschofenig.priv.at/OAuth2-Security-14Dec2012.ppt

We had a short discussion about each of these slides. 

Regarding use case #1 Thomas noted that a channel binding feature may give the client/authorization server the ability to detect such a scenario. 
He asked whether it would be useful to add such a feature to the protocol. 

In use case #2 ("unprotected" resource) Bill noted that this is the Flickr scenario and Justin suggested that Bill provides more background about the motivation for not supporting TLS to the list. This could help to better understand why some deployments show reluctance to enable TLS support (and therefore need a custom application layer security solution). 

In use case #3 (prevent access token re-use) the conference call participants started a discussion about the delegation use cases.

For use case #4 (AS-to-RS relationship anonymity) it was not quite clear what the cost of adding support for this functionality is and how it interferes with other security features. Needs more investigation. 

When we started discussing the client instance functionality it became clear that this is not necessarily security functionality and should therefore be discussed independently. Justin mentioned a draft he published some time ago (see http://tools.ietf.org/html/draft-richer-oauth-instance-00) and Hannes encouraged him to resubmit it. This topic will be discussed independently of the security work. 

The group went a bit overtime already and therefore there was not too much time left to discuss the key lifetime topic. It was, however, noted that the usage of asymmetric keys may allow larger key lifetime and usage of the access token with more than one resource server (since that the resource server does not obtain the private key and therefore cannot impersonate the client). 

In general there was fairly good understanding of use cases #1, #2, and #3. 

Action items:
  * Justin will re-submit his "OAuth Client Instance Extension" document 
  * Justin to provide a short writeup about the regulatory requirements for application layer security. 
  * Hannes to incorporate a short description about the use cases into draft-tschofenig-oauth-security

--- 

Let me know if I missed something.  

Ciao
Hannes