Tag Archives: Liberty

Quick thoughts on XAuth

It’s the “common domain cookie” trick from Liberty ID-FF and SAML2, except without the notion of a circle of trust. (Thanks to Praveen for forging the CDC connection in my brain.)

Heh.

It’s yet another thing you have to opt out of instead of into. (To disable it, visit XAuth.org from each browser you use.)

Pamela is wise.

I was already getting tired of the “social web” about the end of 2009. Does that make me anti-social?

Ugh — seepage.

A Venn of identity in web services, now with OAuth

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).

VennOfBCID-Oct2009

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.)

Concordia workshop: the secret word is authz

Dave Kearns asks, I deliver — in two parts (so far)…

Concordia workshop report

Monday’s Concordia workshop at Catalyst was a surprise and a delight. We tried to make it a more interactive and intimate experience than the mega-carnivals we do at RSA: check. We set up a theme — identity in Enterprise 2.0 — and hoped for a bunch of interesting use-case submissions to tee up the subject: check. We worried that the diverse agenda would hang together: we needn’t have. A leitmotif emerged pretty quickly: authorization.

A crack team of volunteer tweeters, led by Brett McDowell (in English; I helped!) and Tatsuo Kudo (in Japanese), helped keep the outside world connected to our discussions (searching #catalyst09 concordia gives you an accessible sampling, but looking for tweets on July 27 for just #catalyst09 will give a more complete listing).

All presentations and original sources are now linked from the workshop agenda, and I strongly encourage you to check out this rich material. Attendees were enthusiastic about the new XACML profile work and our Burton speakers’ thoughts on the complexity of social networking in enterprise settings (thanks again to Mike Gotta and Alice Wang for presenting some exciting/scary scenarios, and to Burton as a whole for continuing to support our Concordic efforts). And people had lots of useful feedback on the Levels of Assurance survey idea we’ve been hammering on for a couple of months now — basically, we think we’re going to start with in-depth interviews instead, since all our questions are open-ended and lead to more questions.

If you want to help us figure all this out going forward — including possibly contributing multi-technology authorization use cases for future interop experimentation — don’t forget to join Concordia in its new guise as a Kantara discussion group! Here are simple instructions.

ProtectServe and UMA deeper dive

At the workshop I had a great opportunity, given that my User-Managed Access group is just spinning up, to do a quick overview of the ProtectServe work that has inspired UMA and to review some alternative “use-case topologies” that could satisfy a single generic scenario in different ways. Srijith Nair et al. of BT submitted an interesting ProtectServe use-case document, and in my workshop presentation I walked through some of the implications.

The scenario I highlighted is about an employer and an employee, and the fact that both might want to impose their own constraints on the sharing of the same piece of information. Examples of pieces of information your employer holds that you might need to share (the Liberty ID-SIS employee profile spec might suggest more):

  • Employment status (often needed when you apply for a loan)
  • U.S. Internal Revenue Service W-4 (tax withholding) form details (handy for sharing with accountants and investment planners)

I (sort of ab)used the Scrum concept by formulating the following “user stories” that capture what’s special about the need:

  • As an employee, I want to audit and control the further dissemination of information my employer must know about me as a condition of employment.
  • As an employer, I want to adhere to laws and best practices regulating my sharing of information about my employee.

Three obvious ProtectServe entity topologies present themselves, each with a different sweet spot:

employer-1
#1: Employer as authorization manager and service provider

This topology preserves an explicit place for the employer to apply its own sharing policies — the authorization manager (and enclosing relationship management app) that it hosts itself. However, I think this is probably a “legacy” solution because it forces the employee to seek out other relationship managers in the outside world where they’re just an individual rather than an employee, and I can’t think of very good reasons for the employer to host this AM/RM other than corporate inertia (admittedly, a force to be reckoned with). Maybe I’m wrong, though, and a good reason will emerge.

employer-2
#2: Employer as service provider

For information for which the employer is authoritative (“Is this person employed here?”), it should host a service provider willing to attest to this on request (in accordance with the instructions issued by the employee’s personal AM). If the employer doesn’t want to release the data even though the employee is cool with the sharing, it could use existing access control mechanisms that are out of band with respect to ProtectServe, perhaps only surfacing a response code that reflects its refusal. (Ah, there’s a potential requirement for the UMA work if this use case is accepted by the group.)

employer-3
#3: Employer as consumer

For information that the employee already self-asserts to the employer (“What is the employee’s home address of record?”), why can’t the employer consume this data in the same way some other “vendor” (online service) on the open Internet could? If the employee moves, a number of workflow actions have to unroll on the employer’s side as they would have anyway (in the U.S., moving to a different state might involve withholding a different amount of state income tax), but this is already handled in existing systems when the employee provisions the new information into employee portal apps by hand. An on-board “personal datastore” service provider is shown here as being hosted out of the same relationship manager app as the user’s chosen AM, but the SP could just as easily have been hosted remotely somewhere.

If you have thoughts on this, either about the problem space or the solution space, please consider joining the UMA group and helping out!