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:
#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.
#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.)
#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!
