Please note, the opinions here are my own and represent my impression of the discussion that took place. Hopefully I have not misrepresented anyones view here, if I have, please let me know. This post is not meant to represent minutes for the discussion but rather a summary. Minutes can be obtained here.
Nishant Kaushik (Oracle) started off by talking about the case of a personal banking/financial services aggregator site and the quandary that services like it present to the financial service industry and their customers. While a great idea, these types of sites currently require customers to provide their banking user ids and passwords to access financial information. Obviously there is a lot of risk for potential customers to share this information. But, it seems the biggest risk is that there is no way to differentiate the customer from the aggregator. The aggregator accesses banking information with the same rights as the customer. This forces the customer to take an undue risk and likely compromises the aggregators ability to gather a broad set of customers. For banks being accessed by the aggregator, the sharing of uid/passwords by their customers also brings a certain amount of risk.
Patrick Harding (PingIdentity) covered another scenario that actually may be even more familiar. Patrick described how web companies (such as banks, or retailers) often offer 3rd-party services to their customers. To-date, that has been done successfully using web single-sign-on (SSO) technology. When a web retailer hands off to a 3rd-party, a SSO token is used to transfer session information. However, that need is evolving to where the 3rd-party service provider needs to have access to services from the retailer on some ongoing basis, or beyond the current session with the user. OAuth presents an opportunity for the 3rd party site to obtain access rights, with the customer permission, to access retailer information about the customer on an as-needed basis.
Nishant Kaushik (Oracle) started off by talking about the case of a personal banking/financial services aggregator site and the quandary that services like it present to the financial service industry and their customers. While a great idea, these types of sites currently require customers to provide their banking user ids and passwords to access financial information. Obviously there is a lot of risk for potential customers to share this information. But, it seems the biggest risk is that there is no way to differentiate the customer from the aggregator. The aggregator accesses banking information with the same rights as the customer. This forces the customer to take an undue risk and likely compromises the aggregators ability to gather a broad set of customers. For banks being accessed by the aggregator, the sharing of uid/passwords by their customers also brings a certain amount of risk.OAuth provides a new way to handle this scenario that would enable these types of aggregators to avoid using private user-ids and passwords, and instead obtain OAuth "authorization" tokens with the permission of their customers, to access financial service information. The advantage? Well, for one, no re-use of passwords. But for Banks, a key advantage. The ability to to differentiate usage capabilities of individual 3rd-party applications as distinct from and approved by their customers.
Patrick Harding (PingIdentity) covered another scenario that actually may be even more familiar. Patrick described how web companies (such as banks, or retailers) often offer 3rd-party services to their customers. To-date, that has been done successfully using web single-sign-on (SSO) technology. When a web retailer hands off to a 3rd-party, a SSO token is used to transfer session information. However, that need is evolving to where the 3rd-party service provider needs to have access to services from the retailer on some ongoing basis, or beyond the current session with the user. OAuth presents an opportunity for the 3rd party site to obtain access rights, with the customer permission, to access retailer information about the customer on an as-needed basis.Patrick also pointed out that for the enterprise, the OAuth token avoids having to give broad access to 3rd parties systems. Enterprises will prefer a delegated access model as could be offered with OAuth. While eliminating the uid/password anti-pattern is key, differentiated access management of 3rd parties acting on behalf of users is an even more important benefit of OAuth.
There was a general discussion that there are many cases where OAuth tokens are a useful way to obtain user consent for sharing of information between service providers (organizations). As usual, Bob Blakley (Gartner) made the point, more important here is the idea that the holders of valuable data, will retain their ability to ascent to particular clients service providers access data on behalf of users. This makes natural sense, since the above scenarios demonstrate the need by enterprises to be able to have access policy that differentiates capabilities of users/customers from those of 3rd party service providers acting on their behalf.
There was a lot more discussion that took place. Some of it very detailed, some on topics which I plan to blog on shortly. Stay tuned!
1 comment:
Business processes fuel the design and logic of several enterprise network management tools. In banking, security and verification are heavily coupled in all of processes from paper work to financial issuance.
Post a Comment