OAuth for High Value Transactions
Conference IIW8 Room/Time: 6/F
Convener: Jeff Shan E*TRADE
Notes-taker: Tom Brown and Jeff Shan
Tom Brown opensourcecurrency.org Michael Helm LBNL/ESnet Ray Valdes Gartner Inc Greg Haverkamp Lawrence Berkeley National Laboratory Dick Hardt Microsoft Rajesh Pandey eTouch Eric DRAGHI, Consultant Abraham Williams Independent Manish Pandit E*TRADE Nathan Beach Google Brian Eaton Google Siddharth Bajaj Verisign Hannes Tschofenig Nokia Siemens Networks
- Threat Modeling
- risk management
- challenge – extra authentication
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
As OAuth begins to be adopted for High Value Transactions, there is strong need to enhance the OAuth protocol to mitigate the risk. In general, the risk mitigation should be transparent to most of users and transactions. Additional parameters for end user client such as
- Client IP
- Browser (User Agent)
- Device ID
should be passed from consumer to SP (for each step) for auditing and risk assessment.
Result of risk assessment by SP could be challenge, which should result in consumer redirecting user back to SP for extra authentication (so to minimize the changes for Consumer). If user successfully passing extra authentication, it should be redirected back to consumer side to finish the transaction.
Scope/Level for Access Token was discussed. But Brain mentioned that it seems to be very difficult to have a generic model to cover all use cases.
Security improvement to protect against session fixation with bad consumer implementation. One of proposals is with “Approved Token” approach as documented in http://groups.google.com/group/oauth/browse_thread/thread/e8506e71c5dc9582# which is similar to OAuth Core Spec 1.0 Rev A (Draft 3). But Approved Token would be different from Request Token after user’s approval, to protect against bad consumer implementation of early binding. And no need for verification code.
Token secret is currently not used in signing with RSA-SHA1. There should be enhancement to leverage token secret with RSA-SHA1.