00:00:00.539
(Audience laughs)
00:00:18.920
All right, good morning! My name is Tom Brown, and today we're going to talk about beautiful payments with OAuth.
00:00:24.480
I am a big believer in the law of two feet, so I want to start with a quick overview of what we will be discussing today. If it doesn't fit what you were anticipating, feel free to use the law of two feet and check out the other room.
00:00:37.020
What's on the agenda? First, we'll do a quick OAuth demo. I polled the room and asked if they would like to see a popular instance of using OAuth to ensure we understand what it does.
00:00:48.960
Then we'll follow the normal agenda, where I will discuss the motivation for this talk. A lot of it was influenced by a chapter I read in the book 'Beautiful Security.'
00:01:05.400
Next, we'll cover the Dwolla OAuth API, which is a new payment API using OAuth, and I think it's quite neat. We will also discuss the OpenTransact mailing list and the activity happening there, as well as why I believe it's a positive development.
00:01:20.400
Following that, we'll look at a couple of examples, specifically with an OAuth consumer called oauth.jpkarma. Additionally, I'll showcase a tool called Artifice, created by Yehuda Katz, which facilitates building server APIs with OAuth conveniently. Finally, we will discuss some future projects in the works, including currency exchange and Federation.
00:01:48.000
Before we dive into the motivation, I want to do a simple OAuth example so we can all agree on what OAuth actually is. OAuth is an authorization protocol that emerged in 2007 through a grassroots community effort that included contributors like Kellen Elliott-McRae, the CTO at Etsy, and Chris Messina.
00:02:10.019
In April 2009, the community took it to specification after addressing a significant security issue known as a session fixation attack, demonstrating their maturity in maintaining vital protocols on the internet in a decentralized manner. Today, OAuth is utilized in various payment systems, which is an exciting evolution.
00:02:36.120
As a simple example, a popular consumer of the Twitter OAuth API is a conference manager called Lanyrd, familiar to attendees of Lone Star RubyConf. Twitter allows users to sign in using OAuth, meaning that instead of Lanyrd managing proprietary user accounts, they utilize Twitter and possibly other social networking sites.
00:02:57.240
The process is often referred to as the 'valet key for the web', which means Lanyrd, as a consumer site, wants to perform actions on behalf of the user. To do this, users must authorize the actions, which involves redirecting them to the OAuth API provider, in this instance, Twitter.
00:03:28.740
Lanyrd uses a request token to bind the series of activities during this authorization process, ensuring that it is indeed the user performing all the necessary steps. The flow includes the consumer asking if the user wants to use the service, redirecting them to the API provider, where they can authorize the request under the provider session.
00:03:53.400
Once authorized, the user is redirected back to Lanyrd, which then exchanges the request token for an access token. Now, Lanyrd has an access token allowing them to complete the authorized actions. OAuth also includes Scopes, which enable granular authorization for specific actions. This means that a user could grant permission to Lanyrd to read tweets and update their profile but may choose not to grant permission to post tweets.
00:04:34.739
After granting the necessary permissions, the user is returned to Lanyrd, which can then fetch their contacts and provide value-added features for conference scheduling, such as showing what events their Twitter contacts will attend. This capacity for integration highlights the tremendous value that APIs can offer for application development.
00:04:59.159
Many believe that current payment systems are outdated and in need of improvement, and OAuth can indeed help us with that. I encourage questions at any time during this presentation; the Q&A does not only need to be at the end, so please feel free to raise your hand.
00:05:24.240
The motivation for this discussion is largely grounded in a chapter written by Ed Bellis in the book 'Beautiful Security', titled 'A Beautiful Trade: Rethinking E-commerce.' He argues that current web payment systems are flawed, particularly due to their reliance on traditional credit card information, which is essentially a shared secret exposed to numerous parties throughout its lifecycle.
00:05:57.600
This system design is problematic; the weakest link in the chain can compromise sensitive data. Additionally, those charged with safeguarding this information often lack adequate control. Consumers bear little risk beyond an arbitrary threshold, providing them with no incentive to protect their information.
00:06:25.560
Consequently, this creates a fundamentally flawed payment system that we can work to correct. There are various issues with existing payment systems, but I won't dive into all of them today. Instead, I will focus on how we can address this shared secret problem to rectify other associated issues.
00:06:43.200
One notable payment API recently supporting OAuth is Dwolla, which processes over a million dollars in transactions per day. Many of these transactions are related to Bitcoin, such as cashing out. The API is interesting because when an application requests permissions to perform actions on your behalf with Dwolla, they take you through a process to grant those permissions.
00:07:06.840
When redirected to Dwolla for authorization, users see a list of Scopes, including permission to send or receive money. This highlights the importance of permissions in maintaining a secure and user-friendly experience. Different applications may require varying Scopes, allowing users to selectively choose permissions based on their needs.
00:07:24.420
For example, an account aggregator might only require access to account details and balance information without needing to see transactions or contacts. It's important to ensure that applications clearly communicate their requested scopes and why they need them.
00:07:43.680
Further, if you're interested in the Dwolla API, I encourage you to explore the documentation. You can use the Ruby OAuth gem to communicate with the Dwolla API quite simply. However, there are considerations to be aware of.
00:08:06.240
One significant issue with the Dwolla API is that permissions are presented as all-or-nothing. When asked to grant Scopes, users can either approve everything or reject everything. This limitation could be significantly improved by allowing selective permissions.
00:08:29.640
Another issue is that the Dwolla API assumes USD as the only asset class, which limits functionality. To establish a robust payment protocol, we must address these two critical problems to ensure its adequacy.
00:08:47.760
Now, let’s delve into the OpenTransact initiative, which was started by Pele Brangard, the maintainer of the Ruby OAuth plugin for building OAuth applications. The mailing lists related to this initiative include the original Agile Banking mailing list and the more recent OpenTransact mailing list, focused specifically on the OpenTransact protocol.
00:09:04.680
OpenTransact is a straightforward protocol that encompasses just the essentials needed to facilitate payments. A critical aspect to consider is that we need to support multiple asset classes like USD, Bitcoins, frequent flyer miles, and even time exchanges.
00:09:22.500
Our API needs to be equipped to handle transactions across various asset classes, not just one. OpenTransact is simple to use; for instance, if you want to retrieve transactions, a simple GET request fetches the list.
00:09:40.740
Creating a transaction involves a POST request with minimal required information: the ID of the destination account and the amount. The unit is inferred from the URL to which the POST is sent. Additionally, the destination ID can take various forms, such as an email address, OpenID, or bank account ID.
00:09:56.400
OpenTransact simplifies this process. You can easily create a consumer using the OAuth gem as you would with basic HTTP requests, but the key difference is that you interact with an access token for added security.
00:10:13.680
The OpenTransact Ruby gem also offers additional functionalities such as retrieving profile information linked to the access token and the Scopes that pertain to that token. This highlights the granularity of permissions provided, ensuring a secure API experience.
00:10:30.120
One practical example of utilizing the OpenTransact gem would be an SMS payment gateway. If you've created an OpenTransact provider, you could easily integrate it with a pay SMS application for mobile payments.
00:10:46.620
Today, we will explore the integration of Novamataki's JP Karma, originally developed to interface with an OpenTransact server known as Pico Money. However, I'll demonstrate how easily it can connect to a server I built called OS Currency.
00:11:08.099
To provide a practical demonstration, we will look at the Pay SMS application. This OpenTransact consumer allows users to check their balance or initiate payments via SMS, showcasing the versatility and ease of use associated with the OpenTransact protocol.
00:11:24.840
Additionally, I will demonstrate oauth.jpkarma, a tool for making payments and viewing account details from afar. Now, let’s proceed with the OAuth demonstration.
00:11:40.920
Next, I want to discuss a gem called Artifice, which Yehuda Katz developed. This tool enables developers to spec out server APIs easily, specifically for OpenTransact APIs.
00:11:58.380
Artifice works by injecting code into Net HTTP, meaning that, instead of sending requests over the network during testing, it redirects the calls to Rack. This lets you test your code effectively without the complexities that come with real network interactions.
00:12:14.640
I highly recommend using Artifice for designing OAuth APIs; it makes the process incredibly convenient. Let's look into how Open Currency can benefit from this gem, as I began writing it back in September 2008 based on the Sochi project by Michael Hartl.
00:12:32.880
Wrapping up the presentation, I’ll show you some examples of specifications for OpenTransact using Cucumber—this test-driven approach enables us to clarify the scope of how to interact with the API.
00:12:55.080
You might wonder why Cucumber is used in this scenario. In this context, the customer is the API programmer rather than a regular user, so the programmer needs to understand the scope URLs that will be encountered when interfacing with the API.
00:13:11.520
We have various scenarios to test, including successful payment listing, error handling when no asset is specified, and ensuring compatibility with multiple Scopes when requesting authorization tokens.
00:13:29.880
As demonstrated in the final parts of my talk, we can clearly observe how requests are constructed using the example code for access tokens and how Artifice aids in simulating those requests for effective testing.
00:13:45.000
Though I didn't manage to dig out of my earlier trouble fully, I hope my exploration of the OAuth integration and specification processes has proven insightful. If there are any questions or further clarifications needed, please don't hesitate to ask.
00:14:00.000
Thank you very much for your attention. I hope you found this talk useful, and I'm glad to have shared these insights with you today.
