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

• 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.