You could take this theme pretty far. Does SAML-OAuth bridging have any elements of arbitrage about it? Is assurance leakage in protocol translation like the lousy currency exchange rates at those little van kiosks in airports? Maybe that’s far enough…

I hosted a session at IIW last week to start collecting data around this topic, impishly/illicitly called Two Legs Good? (since the OAuth community keeps trying to quit the “legs” habit but can’t seem to manage it). Session notes are at the link. IIW totally rocked this time; thanks to the organizers and all who contributed to making it great!

In order to encourage you to comment over on the other site, I’ve turned off comments here (boy, does that feel weird…). If you prefer to weigh in with 140 characters’ worth of wisdom, just be sure to use the hashtag #Forr2Legs so I’ll see it.

Newcastle University’s SMART project team will be in Mountain View again, discussing their UMA implementation and UX work. And vice-chair Maciej Machulak and I plan to convene a session to share our draft solution for loosely coupling an OAuth authorization server and resource server to solve for externalized authorization and interoperable scoped access in the UMA context.

Back in February, a bunch of us tried discussing this very subject in Twitter and got pretty far, but it took Paul Madsen to put the whole story together in his blog post Way more than 140. And loving it. Check it out.

Essentially, UMA is choosing to give the host (resource server) more autonomy than it would typically have in a tightly coupled environment, so that it’s not entirely accurate to say it’s a mere policy enforcement point (PEP) and the authorization manager (authz server) is a full policy decision point (PDP). This seems to make good sense in a totally open-Web environment. However, “the full PDP” is an optional feature we could probably add if there’s interest.

The really interesting thing is that, to make externalized authorization work, we’ve had to go “radically claims-based”. The model seems very powerful and generative — it gives the power to upgrade and downgrade granted scopes at will! But it does take a step or two back from pure OAuth 2.0 as a result. This is something I’m keen to discuss with folks in and around IIW; we’ll be presenting these slides to that end.

Later: Neat, it’s been cross-posted to the CSO Online blog as well.

Thanks to Domenico Catalano (@DomCat) for putting together this lovely and geeky holiday message! And thanks to all the UMAnitarians for their contributions of passion, business problem-solving, and technical know-how to the User-Managed Access work.

The end of 2010 has brought new progress on several fronts. The UMA-friendly Java-based OAuth leeloo implementation was released as open source; we’ve begun solving some hard problems in defining interoperable interfaces between OAuth authorization servers and resource servers; we’ve been teasing out the implications of trusted claims as the basis for user-centric access control; and we saw two significant submissions in response to the UMA validation bounty program. We’re grateful to submitters Cordny Nederkoorn, whose interest in UMA grew as a result of his explorations into cloud identity, and Project hData, a unique and important effort that seeks to make electronic health data amenable to RESTful web app treatment.

We’ve got lots more developments in store for the coming months, and we welcome your involvement. From our Kantara home page you can join the group (no membership fees!), subscribe to our mailing list, and check out the latest news, and don’t forget to follow us on Twitter.

Happy holidays!

Some 30 live attendees were very patient with my Internet connection problems, meaning that the slides (large PDF) didn’t advance when they were supposed to and I couldn’t answer questions live. However the good folks at BrightTALK fixed up the recording to match the slides to the audio, and I thought I’d offer thoughts here on the questions raised.

“Framework provider – sounds suspiciously like an old CA (certificate authority) in the PKI world! Why not just call it a PKI legal framework?” Yeah, there’s nothing new under the sun. The circles of trust, federations, and trust frameworks I discussed share a heritage with the way PKIs are managed. But the newer versions have the benefit of lessons learned (compare the Federal Bridge and the Open Identity Solutions for Open Government initiative) and are starting to avail themselves of technologies that fit modern Web-scale tooling better (like the MDX metadata exchange work, and my new favorite toy, hostmeta). PKI is still quite often part of the picture, just not the whole picture.

“How about a biometric binding of the individual to the process and the requirement of separation of roles?” I get nervous about biometric authentication for many purposes because it binds to the bag of protoplasm and not the digital identity (and because some of the mechanisms are actually rather weak). If different roles and identities could be separated out appropriately and then mapped, that helps. But with looser coupling come costs and risks that have to be managed.

“LDAP, AD, bespoke, or a combination?” Interestingly, this topic was hot at the recent Cloud Identity Summit (a F2F event, unlike the BrightTALK one). My belief is that some of today’s tiny companies are going to outsource all their corporate functions to SaaS applications; they will thrive on RESTfulness, NoSQL, and eventual consistency; and some will grow large, never having touched traditional directory technology. I suspect this idea is why Microsoft showed up and started talking about what’s coming after AD and touting OData as the answer. (Though in an OData/GData deathmatch, I’d probably bet on the latter…)

Thanks to all who attended, and keep those cards and letters coming.

In the enterprise, an externalized policy decision point represents classic access management architecture, but in today’s Web it’s foreign. UMA combines both worlds with the trick of letting Alice craft her own access authorization policies, at an AM she chooses. She’s the one likeliest to know which resources of hers are sensitive, which people and services she’d like to share access with, and what’s acceptable to do with that access. With a single hub for setting all this up, she can reuse policies across resource servers and get a global view of her entire access landscape. And with an always-on service executing her wishes, in many cases she can even be offline when an access requester comes knocking. In the process, as Phil observes, UMA “supports a federated (multi-domain) model for user authorization not possible with current enterprise policy systems.”

Phil wonders about privacy impacts of the AM role given its centrality. In earlier federated identity protocol work, such as Liberty’s Identity Web Services Framework, it was assumed that enterprise and consumer IdPs could never be the authoritative source of all interesting information about a user, and that we’d each have a variety of attribute authorities. This is the reality of today’s web, expanding “attribute” to include “content” like photos, calendars, and documents. So rather than having an über-IdP attempt to aggregate all Alice’s stuff into a single personal datastore — presenting a pretty bad panoptical identity problem in addition to other challenges — an AM can manage access relationships to all that stuff sight unseen. Add the fact that UMA lets Alice set conditions for access rather than just passively agree to others’ terms, and I believe an AM can materially enhance her privacy by giving her meaningful control.

Phil predicts that OAuth and UMA will be useful to the enterprise community, and I absolutely agree. Though the UMA group has taken on an explicitly non-enterprise scope for its initial work, large-enterprise and small-business use cases keep coming up, and cloud computing models keep, uh, fogging up all these distinctions. (Imagine Alice as a software developer who needs to hook up the OAuth-protected APIs of seven or eight SaaS offerings in a complex pattern…) Next week at the Cloud Identity Summit I’m looking forward to further exploring the consumer-enterprise nexus of federated access authorization.

In the spirit of real ones:

Margo wanted Parker to get an attorney before making a confession but he insisted on telling the truth anyway. Margo quickly called Jack with the latest development so he and Carly rushed to the station. Jack ordered his son to keep quiet but Parker said he was going through with his confession. Carly was brokenhearted that Parker couldn’t be silenced and Margo took Jack off the case. [ATWT]

…I present the soap-opera synopsis of the goings-on:

David showed up at the Mountain View party with OpenID Connect, which had been hanging around with OAuth in a way that seemed promiscuous. Having insisted last year that it was ready to change, OpenID quickly got busy. OpenID Artifact Binding was brokenhearted that its quiet yet effective nature wasn’t enough to get it noticed. UMA and CX couldn’t help putting in their two cents when they heard what the problem was.

The OpenID specs list discussion is now hopping, and so far it’s been relatively free of pique and getting more productive as people understand each other’s use cases and requirements better. Now we just need to come up with a list of in-scope ones…and realize that the best ideas for solving each one could come from anywhere.

So: Can we try and combine the grand vision and breadth of community of the OpenID.next process, the rigor and security of OpenID AB, and the speed and marketing savvy of OpenID Connect — rather than (ahem) the speed and rigor of the OpenID.next process, the grand vision and marketing savvy of OpenID AB, and the security and breadth of community of OpenID Connect?

UPDATE on 10 July 2010: This post has been translated into Belorussian by PC.