Blog

We’ve submitted our application to take part in the 2013 Google Summer of Code event. If you are a student and are interested in not only learning about how the Web is built, but taking an active role in creating the foundation that billions of people around the world use, here’s your chance. Our company…

It’s been quiet recently on this blog… because we’ve been busy! RDFa and JSON-LD standards are coming along nicely and the Web Payments work is progressing. Our payment standards effort has been focused on our PaySwarm implementation but we haven’t forgotten the specs and will get back to working on them as soon as we…

This wasn’t a typical Beta launch… it wasn’t what we intended to do when we started. We have been focused on creating an open, universal payment standard for the Web for the past 24 months. In late February, we launched an alpha release of the PaySwarm reference implementation with a plan to release a commercial…

In May of last year, we launched the first public PaySwarm system for developers. The system implemented the open standards-based, patent-and-royalty free, PaySwarm specifications that enable developers to perform Web Payments. We have learned quite a bit from that deployment, which resulted in core changes to the specification and developer website. Today, we are pleased…

A few weeks ago, we announced the launch of the Data Driven Standards Community Group at the World Wide Web Consortium (W3C). The focus is on researching, analyzing and publicly documenting current usage patterns on the Internet. Inspired by the Microformats Process, the goal of this group is to enlighten standards development with real-world data….

This is a continuing series of blog posts analyzing the differences between PaySwarm and OpenTransact. The originating blog post and subsequent discussion is shown below: Web Payments: PaySwarm vs. OpenTransact Shootout by Manu Sporny OpenTransact the payment standard where everything is out of scope by Pelle Braendgaard Web Payments: PaySwarm vs. OpenTransact Shootout (Part 2)…

The Web Payments Community group is currently evaluating two designs for an open payment platform for the Web. A thorough analysis of PaySwarm and OpenTransact was performed a few weeks ago, followed by a partial response by one of the leads behind the OpenTransact work. This blog post will analyze the response by the OpenTransact…

The Web continues to transform the way humankind communicates and builds our world. At the heart of most of these endeavors is the exchange of value. Gifts, attention, and payments each play a role in the ecosystem that we call the economy. Until now, there has been no open and universal way of sending and…

After being in development for around 9 months, we are proud to announce the first release of the PaySwarm Developer Sandbox. This release includes a working implementation of the PaySwarm universal payment platform, an OAuth-based REST API, and a WordPress plugin that allows articles to be sold in a standards-compliant manner.

The World Wide Web Consortium (W3C) is starting to tackle the sticky issue of identity on the Web. For those not familiar with the W3C name – they are the stewards of a number of the most important standards that make the Web work – the HTML, CSS, DOM, XML, RDFa, SVG and a number of other specifications and technologies. There will be an Identity in the Browser workshop in Mountain View, California on May 24th and 25th 2011. Digital Bazaar was asked to submit a position paper for the workshop, and this blog post summarizes some of the information in that paper.

In our push toward the first public release of the PaySwarm standard, development platform, and commercial release of the first PaySwarm Authority – we have released a key building block of the PaySwarm specification: The PaySwarm Vocabulary. The vocabulary outlines the concepts that are active on any PaySwarm-compliant network – people, financial accounts, assets, licenses, listings and contracts. The vocabulary is used by PaySwarm applications to communicate with one another using a common commerce language.

We are often asked why Digital Bazaar is creating a standard for Universal Payments on the Web. Visa and Mastercard exist. PayPal is widely known and used. Google Checkout and Amazon Payments also cover retailers willing to hitch their store to yet another proprietary checkout mechanism. The brands are well known and recognized. Many competitors and good brand recognition are good for the marketplace, right?

The PaySwarm Reference Platform uses the Semantic Web. That means that it understands the information it reads in a web page and uses that knowledge to accomplish its tasks, for example, performing financial transactions. Machines understand what is in a web page by reading meta-data embedded in the page. The meta-data is expressed using a machine-readable vocabulary to describe human concepts. Vocabularies are basically dictionaries for computers – telling them more about each concept described by a particular term. In our push toward the first public release of the PaySwarm Reference Platform, we have released two of these vocabularies. One of them is for describing Commercial exchanges and one is for describing Digital Signatures. This blog post discusses what each one of them does and how they fit into the greater PaySwarm ecosystem.

Recently a few XML experts have been claiming that the decision made by large Web Service providers, like Twitter and Foursquare, to drop XML from their Web Services infrastructure is not very interesting news. They also assert that the claims that JSON is more useful than XML for the majority of Web Services is wishful thinking by a “cadre of Web API designers” that have yet to provide “richer APIs”. As the rest of this post will attempt to explain, some of these folks may be missing the bigger sea change that is happening.

A global model for sharing information, once a dream, and then a reality with the Internet and the Web, is now becoming a fundamental part of the systems that we build. As we automate much of the sharing of information, we need to be able to express this shared data to computers in a way that is both easy for them to process and also easy for web developers to understand. We need a way of expressing Linked Data in JSON…

We always strive to make using the PaySwarm web platform as simple as possible for developers. With that goal in mind, we are launching a new PaySwarm Developer API and a development website today. We are also releasing a demonstration of the PaySwarm web platform as it applies to bloggers, journalists, newspapers and magazines…

If there is one thing that is universal to all websites, it is the login process. Almost every website requires you to create an account, enter your e-mail address, verify your account, and log in before you can use any of the advanced features of the website.

Wouldn’t it be great if there was a universal login mechanism for the web? One where you just had to click a login button and your browser would take care of filling out your account details? What if you didn’t need to remember different passwords to log into websites? What if we could do all of this and ensure that only you and the website you are communicating with would be able to see the data you are sending?

The good news is that there are some very smart people working on this problem. The solution is called WebID. The bad news is that there remained one problem that would take the browser vendors years to solve. That is, until Dave Longley (our CTO), discovered a way to make WebID work in all the current browsers in use today, including Internet Explorer…

In the previous article that we did on a JavaScript implementation of TLS, we explained why we created Forge, which we released as open source software. To summarize, before Forge, there was no easy way to access a home computer using just JavaScript and Flash – technologies that exist in 98.9% of all browsers. With Forge, application providers such as Google Docs can now provide access to your home computer in a way that is safe and secure…

To our knowledge a JavaScript implementation of TLS has never been done before. But, if you are a developer, you might be thinking: Wow, that sounds completely inane. Is this just another case of a bored developer engaged in an esoteric demonstration that something crazy is possible? It is useful. We promise.

If you are not a developer, you might be wondering what TLS is and what JavaScript has to do with it at all. Well, first, TLS stands for Transport Layer Security and is just the fancy name behind what makes “https” websites secure. You may have heard of SSL (Secure Socket Layer) before. TLS is the latest version of SSL and is more appropriately named because data does not have to travel over a “socket”; it can be transported in many different ways. So why would someone think a JavaScript TLS implementation is useful?