In the past week, several people approached me with the idea of incorporating OAuth somehow into the Venn view of identity. Feels like more of that “destiny” Ashish invoked a couple of weeks ago — especially since I had already developed just such a Venn for my XML Summer School talk last week.
My very first Venn of Identity blog post also included a second diagram, covering something like “identity in web services”. It was little-noticed, I think, because the deployment of the more esoteric pieces of WS-* and ID-WSF was pretty low. I’ve been itching to add OAuth to it, given its wildfire-esque spread. Last week gave me my excuse, and with further feedback (thanks Paul and Dom!), I’ve continued to revise it. So here’s a new version for your perusal (click to enlarge).
As with the original version, the relative heights and sizes are significant: they indicate roughly how voluminous, vertically applicable, and far away from “plumbing” each solution gets. (Unlike the original, however, this one seems to give off a Jetsons vibe.)
Some thoughts from space-age 2009:
OAuth is helping many app developers meet their security and access goals with minimal fuss (80/20 point, anyone?), and by providing for user mediation of service permissions, it is easily as “user-centric” as any other technology claiming the title. It’s these lovable qualities that led the ProtectServe/User-Managed Access effort to use OAuth as a substrate.
ID-WSF still provides identity services functionality that nothing else does, and some folks I’ve been talking to lately still chafe at the lack of more widespread support for these features. But obviously it’s still a “rich” solution vs. a “reach” one.
WS-*, ah yes, what to say?… It uniquely solves certain issues, but do all of them really need solving? My Summer School trackmate Paul Downey had some choice words about this, and his WS-TopTrumps class exercise proved that the star in WS-* really does match everything possible — that’s too much. And trackmate Marc Hadley pointed out lots of benefits you get “for free” with a REST approach, which it was hard not to notice when we all chose to design REST interfaces for his class exercise despite having a SOAP option.
To be fair, Paul and Marc and also trackmate Rich Salz — who has an uncanny ability to explain complex security concepts simply — stressed the value of the core pieces for message security if you’re using SOAP. It would be interesting indeed if OAuth, or extensions to it with the same pure-HTTP design center, were to “grow leftward” to accommodate the use cases covered by the WS-*/ID-WSF intersection.
(Anyone think the new REST-* effort will win in this space anytime soon? I’m a bit dubious, myself. Its name sure didn’t inspire any love in our lecture room.)
I would be interested in your view on how foaf+ssl fits into this diagram.
http://esw.w3.org/topic/foaf+ssl
I don’t have much experience with much of the technology described here, so it is difficult for me to position it in there. foaf+ssl is completely RESTful, so it would be a good candidate to look at how far a RESTful effort can go.
A very initial first thought:
1. foaf+ssl is based on URIs. URIs – Universal Resource Identifiers – deal with identity at the most general level.
2. foaf+ssl uses the RDF, a framework to describe anything, that is modular and composable.
3. foaf+ssl uses the linked data pattern for deploying RDF, such that dereferencing URLs using their canonical dereferencing mechanism, gives you information about the meaning of that ID. This gives you an the discovery service.
4. foaf+ssl uses SSL to tie a user agent to a URI. This is similar to what openid does.
I think one can do something similar to OAuth quite easily by following this RESTful pattern.
I am confused why OAuth was categorized as an API – it’s more a security framework for WebAPIs and obviously as with any other frameworks it does have a protocol (token exchange and authorization) that helps in bootstrapping APIs built using the OAuth framework. No? I always feel it’s confusing to draw a line between “API – Protocol – Framework – Platform” – given that each one of them weaves together with another in one way or other to become another. :-)
Hi Praveen– I think I used their own original description for themselves (though they do describe it as a protocol in the modern era…guess I should revise the diagram!). I see it as a protocol myself, and do think there’s a useful distinction between them, even if it’s sometimes fuzzy. A protocol defines a contract, and APIs assist in implementation and deployment of real-world endpoints that are parties to that contract, creating distance but also ease. (I had some thoughts about this subject a couple of years back, wrt interop.) Framework and platform mostly get too fuzzy for useful distinctions. :-)
true – the language used to define what OpenID and OAuth are is very confusing. OpenID for example used to have “OpenID is an open, decentralized, free framework for user-centric digital identity.” but now on it’s redesigned website it says “OpenID is a decentralized authentication protocol that makes it easy for people to sign up and access web accounts. ” OpenID an Authentication protocol ? should have called it an SSO or Identity Exchange Protocol instead ?
Good point! I think all such taglines need to be taken with a grain of salt, as they’re partly about marketing. (I also notice openid.net now says “OpenID is a safe, faster, and easier way to log in to web sites,” and yet “safe” is an awfully big promise — as are “faster” and “easier”! What’s it being compared to?… Local logins are still probably the fastest, once you’ve registered.)