Loving the simple API Design Guidelines from GoCardless

See here.

I like this for several reasons:

  • I like the simplicity and clarity of the guidelines.
  • I agree with all of their guidelines; nothing feels controversial there. Such as: Use JSON, and pretty print it. Be explicit with error messages. Use plural nouns for containers. Etc.
  • I like the fact that it is open sourced for the world to see, share and fork.

ps: My employer, Apigee, is still looking to hire SEs, and other API geeks.



Developer , ,

Oregon sues Oracle over app delivery

screenshot-20140822-155853

Fortune Magazine is reporting that the US State of Oregon is suing Oracle for $200 million, alleging fraud for Oracle’s role in building the state’s failed health insurance exchange.

Ouch!



Business ,

Uber aims to be a platform

You may think of Uber as a disruptive player in the hire-car business. They offer a service similar to taxis, but enabled with an app experience that riders really appreciate. The hailing and pay-by-phone experience is something that I personally love. I love knowing where the driver is, how long it’ll take to arrive, the ease of paying, and so on.

But now Uber is launching an API. They’re aware that disruption is not simply something they dish out to others, but that they are also subject to disruption. They cannot afford to stand still.

Uber has a key asset – a network of drivers available on a for-hire basis. By exposing that asset programmatically via an API, Uber turns itself from simply a taxi service with an app, into a people-and-goods delivery platform upon which other companies can build their businesses. Pharmacies are a key potential partner – think of Prescription delivery services for people with limited mobility. Uber can act as a personalized delivery service for any high-value retail good.

Or think of personal concierge services – what if you could build an app to request a car to any location on behalf of a VIP or a person you’re trying to impress?

Uber have announced 11 partners at the launch of their public API. Obviously the market is interested in building new businesses or expanding existing businesses in partnership with them.

The beautiful thing about APIs is that any business can expose their capabilities programmatically to transform into a “platform”. That means greater reach, more partnerships, lower cost of business development, better return on assets.

Think back: this is exactly the kind of nirvana we in the industry were envisioning, 15 years ago, when we created SOAP and all the WS-* specifications. But we went too far out on the complexity-vs-value spectrum. It turns out the WS-SecureConversation spec was not the key concept that would enable flexible business partnerships. We now realize that simplicity of design and ease of programmability are the keys to unlock the possibilities in this domain. I’m so glad that time has arrived!

What’s the basis for your platform?



Strategy , , ,

Data is Beautiful, Episode #1: Strava Running Routes

Strava heatmap

I’m currently digging the heatmap that Strava produces with running route data.
Continue reading



Data , , , ,

SAML – the standard that wasn’t

OASIS

SAML – the Security Assertion Markup Language is quite successful. SAML was born in 2002 out of OASIS, the somnolent standards body that enjoyed its heyday in the 2000’s forming so many of the XML-oriented standards like WS-BPEL, UDDI, UBL, and ODF. Today SAML enjoys success satisfying a key need in enterprises: browser-based single-sign across origins. Sign into www.mycompany.com and then later visit www.serviceprovider.com and get automatically authorized. The benefit is: people type in their passwords, just once.

SAML wasn’t designed for just that problem, or anyway, not for that specific problem. SAML was designed to address the general problem of exchanging claims securely. The summary on the first page of the spec says that SAML “defines the syntax and semantics for XML-encoded assertions about authentication, attributes, and authorization, and for the protocols that convey this information.” Hence the name, “Security Assertion Markup Language”. But in actual use, SAML is heavily oriented towards browser-based SSO.

In SAML, the claims or assertions are statements about people. When people (via apps or browser pages) make requests of systems – like “let me see this file”, or “let me transfer funds” – the system that receives this request can use trusted claims about the requester to make authorization decisions. The key is that the system needs to trust the claims, and the claims need to be relevant.

An example: If I go to the grocery store, I can present my debit card to the checkout person, to pay for my groceries. The card is basically a set of claims “asserted” by a bank about me:

Debit card
  1. that the person named on the card is a customer of the bank,
  2. that the person named is authorized to use a particular account.

This set of assertions is also decorated with some other information, like valid dates, and the author of the claims. The author of the claims is a bank, and that bank is affiliated with a card payment network, in my case, Visa. Also: My debit card expires in a given month and year. The implicit rule is that all parties agree that the claims presented in the plastic card do not hold after that date. This card is good if the merchant trusts the bank, and Visa, and if the dates are valid. Some merchants want to insure that the person named on the card is the same as the person presenting the card, so they’ll ask for a government-issued picture ID that has the same name.

The SAML Analogue

SAML Assertions

SAML works in a similar way, except the set of claims is formatted digitally, in an XML document, rather than on a plastic card. The set of claims enclosed in a SAML token is general – it can be any set of claims about a person, or “subject”. Claims such as “Dino is male”, or “Dino has no tattoos”, or “Dino is of sound mind and body” are all acceptable. But more often the claims are statements that are relevant to information-processing organizations, such as “Dino is an employee of XYZ corp.” and then some detailed information such as “Dino’s email address is Dino@xyzcorp.com”, “Dino is a member of the Aviation group in XYZ”, and so on. In the general case these are claims about a person’s identity; SAML calls them “Attributes” of the subject. Statements not about the particular person don’t belong in SAML. “It is sunny today” may or may not be true but it is completely unrelated to me – the person in question aka “subject” – therefore not suitable as an attribute in a SAML assertion about me.

Such claims about me could be used by an organization or company to decide whether to grant service to me, when I request it. If my company, XYZ corp, has a partnership agreement with another company, LMN Corp, then when I present my claims to LMN, along with my request, LMN can take a decision on whether to grant my request.

How Trustworthy are your claims?

The claims in a SAML Assertion are just statements, coded in an XML document. Though SAML is a particularly florid and ornate language, it’s still XML, and anyone could create such a document. For a system to be able to rely on that information, to trust that information, there must be some assurance that the presented claims are bona-fide and originate from a trusted source, and also that they are valid at a given moment in time. At one point, “Dino is in the Eighth grade” was a true statement about me, but that statement is no longer true. SAML uses digital signatures based on public-key cryptography for the purpose of assurances of the author of the claims, and explicit time windows on claims (eg, NotBefore or NotOnOrAfter) to circumscribe the validity of such claims.

Key

The “Relying Party” or RP examining a SAML Assertion SAML must verify the signature on the XML document, to insure that the claims can be trusted. The relying party must also evaluate the time windows on the claims. And then finally, the RP must evaluate the claims themselves. It may be that “Dino is a member of the recreation committee” does not grant me permission to see the early draft of the company’s 10-K filing. On the other hand if I am a senior director at the auditing firm, maybe “Dino is an employee at XYZ Auditors” and “Dino is a senior director” is a good enough claim to allow me to see or edit the document.

Simple in Concept, Complex in Execution

SAML is simple enough in principle. I’ve explained the broad strokes here, in just a few paragraphs. Of course, it builds on a large stack of technologies, starting with XML, XML Schema, XML namespaces, URIs, XML digital signatures, and X.509. That alone is a daunting set of technologies, though there is some relief in the maturity of the relevant specifications.

But the details about SAML itself have lead to additional complexity. First, the SAML 2.0 spec is 86 pages. Even there, it is not self-contained. One example: SAML has an element called an AuthnContextClassRef I’m guessing this implies “Authentication Context Class Reference”. For those of you scoring at home, that’s four nouns in a row. What exactly is this thing?

Helpfully, the OASIS spec defines this thing as

A URI reference identifying an authentication context class that describes the authentication context declaration that follows.

All clear? We now interrupt this essay to present a completely unrelated Dilbert comic.

Dilbert

In addition, the SAML spec document suggests, “See the Authentication Context specification [SAMLAuthnCxt] for a full description of authentication context information.” That document is itself an additional 70 pages. Ready to dive in?

This kind of complexity and standards-speak lead, even early on in the life of SAML, to complaints of impracticality from the people who had hoped to be able to use it. Even as early as 2003, just a few months after SAML 1.0 was launched, IBM, one of the original authors of the spec, was employing its partners to bravely assert that the idea that SAML was complex was a myth.

The Wizard

I can hear the wizard inveighing: Pay no attention to that AuthnContextClassRef!!

But the complaints about complexity were not academic. They were based on real-world attempts to get disparate implementations of “the standard” to interoperate. Even today, connecting an Identity Provider and a Relying Party via SAML is a challenge worthy of a platoon of IBM consultants. Have we got a mismatch in the AuthnContextClassRef? Well, we’re gonna have to figure out how to persuade the Relying Party to allow it, or to persuade the IdP to provide a different one. Have you got the wrong NameID Format? Transient, Permanent or Unspecified? Which side needs to give ground in this negotiation?

That’s what I mean when I call SAML “the standard that wasn’t.” It’s a standard, all right, but there are so many different options that despite the rigor of the specification, getting compliant systems to interoperate is still a huge challenge. Despite the challenges, the standard IS valuable – it works mostly, and it solves specific problems that many companies have. But it isn’t automatic.

Lessons for History

SAML is designed to address much more than browser-based single-sign on. But the lion’s share of adopters use SAML for just that, and only that.

There’s a lesson here regarding over-reach of standards: SAML could have been simpler, quicker to get adopted, and easier to use, had its designers restricted their design goals to addressing what 90% of people use it for today, anyway.

Why Bother?

But why am I even talking about SAML? My passion and intention is to work on APIs and enabling new interconnections. That’s why I’m at Apigee today. APIs means “SOAP on Steroids” or if you like, “all the benefits of SOAP without that unsightly residue”. It means getting better connections, faster, and allowing new customer experiences, better mobile apps, better connections between customers and companies. So if I am all about connecting systems with APIs, why do I care about SAML? Have I been sucked into a time-portal and time-warped back into 2007?

Ah, but no! See, the thing is with large companies, they move deliberately. Many still use SAML and still need any systems they install to integrate with their SAML-based Enterprise Identity system. So if I want to work with enterprises in helping them adopt APIs to supercharge their businesses, I need to get SAML working with the various web apps that enable API management and adoption. Get SAML integration done, then the enterprise can innovate with APIs. See?


Related posts:

Developer , , ,

FiveThirtyEight just pre-negotiated Lionel Messi’s next contract

FiveThirtyEight shows the data that explains why Lionel Messi is worth more than any other player.

Love me that breakdown.



Quickies