OAuth for High Value Transactions

Conference IIW8 Room/Time: 6/F

Convener: Jeff Shan            E*TRADE

Notes-taker: Tom Brown and Jeff Shan

Attendees: 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

Technology Discussed/Considered:
 * OAuth
 * 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 should be passed from consumer to SP (for each step) for auditing and risk assessment.
 * Client IP
 * Browser (User Agent)
 * Device ID

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.