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

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to