03.23.07

All your infocard are belong to us

Posted in identity at 11:28 am by

This week was Novell’s Brainshare conference. It’s a big deal for Novell folks and it’s a great event. It gives us a place to show off new technologies like the emerging Internet identity systems and some of the recent work that we have done on the Bandit team.

Our most significant demo this year was shown during the technology preview keynote on Friday. The whole series of demos is interesting — I especially liked some of the Linux desktop stuff — but if you want to just skip to the infocard stuff, it starts at about 40 minutes into the video.

For those who may want to know more detailed information about what the demo actually does, let me give some background information here:

There were 3 new open source components written by Bandits and made available this week:

• A fully open source, cross platform identity selector service was contributed to Higgins. Written in C++, this Higgins ISS runs as a daemon (no UI) and provides core infocard selector service: it accesses multiple card stores, enumerates available cards, matches cards based on requested claims, and interacts with the appropriate STS to get a token. It is almost complete on support for personal cards, with an internal STS, etc. The real deal.
• A UI process for the Higgins ISS. It is currently written in C#, runs on Mono, and leverages much of the management UI of the CASA component of Bandit.
• A new OpenID context provider was contributed to Higgins. This context provider plugs into the Higgins IdAS and allows identity data to be accessed from any OpenID Provider. What this means is that, with no change to the Higgins STS code (since the STS uses IdAS), we could set up a demo such that infocards can be generated from any OpenID identity. In other words, using the Higgins STS and the new OpenID context provider, I can access any site that accepts infocards with my openID account.

So what Baber showed in the demo:

1. A fully functional, native infocard selector running on the Mac.
2. He accessed a shopping site with an infocard generated from an OpenID account. Put some things in the cart and logged out.
3. Baber switched to a SUSE Linux Desktop machine. Fully functional infocard selector there as well. Accessed the same site with an OpenID infocard and see stuff in his cart from the Mac session.
4. Goes to check out. The site asks for a card with different claims, needs a payment card.
5. The Higgins Infocard selector supports multiple card stores. In this case Baber selects a credit card from a card store on his mobile phone via bluetooth.
6. He authorizes a (hypothetical) payment and the online shopping site (the relying party) only gets his shipping address and an authorization code from the credit card.

It’s a simple demo, and easy to miss the number of technologies and interactions involved, but this is the kind progress that we have been working towards for a long time.

The Bandits are happy and tired.

Permalink 9 Comments

03.09.07

A Field Trip to the Planetarium: Delegation, Authorization Documents, and Auditing

Posted in identity at 12:50 pm by

There has recently been an interesting blogosphere conversation around Kim’s series of posts on delegation. It started with Kim’s post about a statement attributed to Eve Maler. He focused on the phrase “user absent scenario” that Eve reportedly maintains Cardspace doesn’t support. Kim then goes on through a number of posts to explain the concept of delegation. It’s actually a concept that Eve mentioned as well. I think Kim reacted mostly against the phrase “user absent”, and the conversation was then picked up by others as being confrontational. I’d hate to have my casual conversations over coffee reported to the Internet and scrutinized over a single phrase. So please do not construe this post as picking a side between current identity system brands. I don’t see these concepts being deployed very much at all right now, certainly not to Internet scale. Even in Kim’s post he mentions that, using Cardspace, someone can build a system that can delegate a user’s authority. Such systems are not here yet.

What I’d like to do is expand on Kim’s exposition on delegation. You might even say, embrace and extend those thoughts to capabilities of authorization and audit.

The concepts he explains are, in my experience, right on. This stuff is exciting to old directory services developers. It even drew Pete out of his code for a while. Much of my career has been working on a directory service from the inside — where identity is represented as a flat list of authorization entities on the other end of a connection. Connection based services. They are fine for many purposes and necessary. But they don’t support delegation well. They don’t allow an entity to take a subset of it’s authority and delegate it to service for a specific purpose and time. Nor does it allow much more complicated scenarios, like those that actually happen when I walk into a Starbucks and pay with a credit card.

What we need for many operations is identity data, especially data used for authorization, that is composable — something like a document that allows chunks of data from multiple sources to be combined into a single authorization document. That way the data can pass through multiple entities and be securely transformed and composed, almost like a mini-workflow. Often delegation involves a time-bound subset of the authority of one entity given to another entity. There are probably many ways of doing this, but one way is to call those chunks of data “claims”, and the document an “infocard”. There are even techniques to keep the claims secure and yet properly pseudonymous.

BUT, the authorization data still needs to keep track of all the entities that authorized some portion of each request. It needs to be composable, but separable to individual authorization entities. There are many reasons why we need to keep them separate, but one reason is so that we can audit who did what. In my directory services experience, I’ve seen many other services login to the directory service as a privileged account, say serviceAdmin, and then make requests on behalf of its users. But all the audit logs can record is that serviceAdmin did everything. Imagine a backup service. I want to delegate to the service my authority to back up some of my files for a specific period of time each night. When the backup service reads my financial data at 2am, I want the audit log to indicate that is was the backup service reading my data on my behalf, not that it was me reading the data. Hopefully, I was asleep.

Audit logs can be necessary for a service to prove compliance with various corporate policies, but it can also be of great value to the consumer. When I buy something at a store, I usually use a credit card. I almost always get a document from the store, the relying party, that indicates who I am, what I purchased, how much they agree to charge me, and what they agreed to do for me. It’s an audit record. A document that gives me a record that I delegated a bit of my authority to that store for a specific purpose. It’s called a receipt. Then when I get the financial statement that says how much was debited from my account by that store, I can correspond it with the receipt. These are all documents that give are composed of delegation and audit trails from multiple entities involved in the transaction.

What about the field trip to the planetarium?

These concepts are all illustrated in a this rather simple recent event.

A few weeks ago my daughter brought me a permission form. I had to fill it out before she could go with her class on a field trip to the planetarium. It had a check box for whether I would drive her myself, or delegate that to the bus company with which her school had contracted transportation. It had a place for my name and signature, and what dates this authorization was effective. That document was then transported (via a rather unreliable medium) to my daughters teacher, to the school administration, where it was processed (I assume), and some derivative document was filed with the bus company. It is very important to me that all points of delegated authorization are clear and auditable. If my daughter wanders off after the show, I want the bus service to wait for her. I do not want it recorded that I drove my daughter to the planetarium. Because it wasn’t me. I delegated some of my authority to another service. I want my online transactions to have these same capabilities — only better.

Authorization and audit matter, and need to be composable from multiple entities. Delegation is a key concept.

Permalink 2 Comments

infocard.

Posted in identity at 12:31 pm by

This is actually a precursor to the another post. While typing that post I became increasingly tired of typing “Identity Metasystem” and “Information Cards”, and have decided to revert to infocards. This is why…

I’m tired of trying to figure out what to call a system of software agents that support a particular style of interactions and data exchanges. Exchanges which are in the style of WS-Trust, use security tokens and security token services, employ an information card metaphor, and are probably to some degree compatible with Microsoft’s Cardspace implementation of an identity selector. What is that system called?

I have read that some feel this system should be called the Identity Metasystem and on my last rereading of Kim’s paper, I mostly think that’s his intent. Mostly. But I’m not sure. And certainly others tell me that the metasystem can’t be meta if it relies on specific protocol exchanges. Protocol exchanges define an identity system, not a metasystem. Also, how can a protocol encompass future systems? It would have to be incredibly fuzzy and abstract (perhaps as fuzzy as WS-*).

So a metasystem should encompass other systems — but does that mean other distibuted systems or other host based systems? Put another way, is a metasystem a conceptual thing only, since actual communications between agents would involve a specific set or system of protocol exchanges. Or is it a metasystem if it is a protocol system that is so incredibly felxible, extensible, and general that connectors can be written to connect all host based identity systems into it?

Reading the paper again just now, I think that Kim’s intent is that the “Identity Metasystem” is a set of protocols and profiles — based on WS-Trust and sometimes called WS-*. But I don’t think it’s commonly understood that way, and I’m not at all sure I’m right.

There’s also the concept of the MetaIdentity System.

And I’m still tired of dancing around what to call it. So, in the posts that follow (until I’m corrected or change my mind) I intend to call it by name of infocard. Using the Microsoft code name as a generic term for the overall paradigm. I know most people now call them “Information Cards”. But that’s so LONG and I’m an old coder that doesn’t type well. It’s as long as “Identity Metasystem”. I like short, but specific names. Preferably all lower case. So I intend to refer to the specific visual metaphor as infocard, and the system as infocards, or perhaps, “an infocard system” when necessary.

Permalink Comments