It's been a rough ride for the last couple of weeks since I had a family emergency in December and have been quite busy. Since live is coming back to normal, I will start blogging again (hopefully).

One interesting thing to mention is the Identity Landscape Paper at openliberty.org. It took some time to get this project going, but it is definitively starting to take off. So if you are interested in contributing, please let me know.

tag: Identity

OASIS has published a draft web service profile for XACML, called WS-XACML. Now, this seems to get very interesting, since it has the potential to truely deliver 'User-Centric' identity (as opposed to Infocard's ServiceProvider-centric identity).

The significant difference here is the availability of two sections in the XACML assertion: one defining the requirements, and the other the capabilities - for BOTH, server and client. InfoCard (and its implementations like Windows CardSpace or Higgins) do not really negotiate requirements, but the service provider (i.e. Relying Party) dictates its requirements and the client will only present Infocard conforming to such requirements. With WS-XACML (which - by the way - also works out-of-the-box with rich client applications) there is an initial policy matching of the server's requirements with the client capabilities AND vice versa. The superiory becomes obvious, when thinking about how easy it is with an InfoCard system to present a card with too much information.

tag: Privacy, Standards, Web Services, OASIS, XACML

By now, most people must have seen what caused some massive traffic delays in Boston, fear of terrorism, and some pretty uncomfortable press for a major network. Ok, the almost pavlovian response to a number of unlicensed ad signs might have been overblown, and one could make the case that this plays well into a general atmosphere of hysteria and fear.

However,  even the remotest advertising monkey should have realized by now, that there has been a major terror attack in which more then 2500 people died. Part of this attack (and subsequent attempts) was an intentional disruption of public services - bridges, planes, trains, etc. Putting unprofessional ad signs, with wires, batteries and LEDs at critical infrastructure points and high-traffic areas is not only stupid, but DOES raise old anxieties. This is highly unnecessary and - as far as I am concerned - "Terror in Advertising" (some might call it 'Guerilla tactics', but this seems to be a point of view).

I would love to see those responsible punished by the full extend of the law, since these sign were deliberately positioned at critical points - it seems quite implausible that the possible ramifications of such placement were not obvious (unless - of course - they do plead stupid, which is also not too unlikely). Also, a full prosecution and punishment (including termination of the cartoon series, and revocation of their broadcasting license) should serve as a reasonable deterrence for potential other Terror-Advertisers, they feel like they have to top this so called 'stunt'.

tag: Boston, Advertising, Terror

This morning (PST), Roger Sullivan announced Lberty's new project called openLiberty.org. This community oriented website aims at providing developers and architects with open source implementations of Liberty's suite of identity protocols. I am really looking forward to seeing a lot of dicussion happening there.

tag: Liberty Alliance, Identity, Open Source

Since I am using VMWare a lot for all kinds of testing, I am really happy to have found this simple procedure: it allows you to extend the Boot partition of your Windows box without having to resort to 3rd party tools.

Now - here is something quite interesting about Java directions: I was only remotely aware of JSR 277 - Java Modules - and took really no big interest in it. However, this effort might solve some of the self-inflicted problems that I had to deal with regarding OSGi bundles.

JSR 277 (which is currently in early draft) aims at provinding a simple class versioning mechanism that allows some of the features of OSGi bundles. Stanley Ho has written some explanatory material on this JSR - from what I could gather, it should be - at least principally - not too hard for OSGi to deal with Java Modules. Now if we only could get it working the other way round ...

tag: JSR 277, OSGi

WS-Federation 1.1 is out... and skipping through the TOC, I have this strange feeling of deja vu.

Thanks to Pat, I caught the five-things-bug as well...

So here are the five things that most folks probably do not know about me:

1. I attended a Jesuit border school in Bonn from grade 9 through 11. The only reason for getting away from there was that I was kicked out after partying too much ...

2. In order to make some money during my university years, a friend and I started a boot camp for high school students, to prepare them for their final exams (Abitur). After the first few years this became a big event, and Uwe is now making a living of it. He is mz son's godfather.

3. There is a story behind my given name "Gerald": My parents had differing opinions about how I should be called, so "Gerald" (my father's name) was the compromise. He got that name, because my grandmother really liked the movie "Gone with the Wind" and named her son after Gerald O'Hara.

4. I am really a Linux guy by heart. I converted my PC (a 486) to SLS at kernel revision 0.99.15 in 1992. Seems like a few lifetimes back ...

5. My favorite beer is Mühlen Kölsch.

And now the pleasant part: Robin, Dale, Hubert, Clemens, Marc - you're it!

After talking to Robin and some other folks, I think it might be an interesting exercise to define a few terms and describe how I have been using them in mny blog post. This is not necesarrily an attempt to create a dictionary or lexicon, but an explanation of how I understand things ...

• InfoCard (System): This is an authentication system, originally devised by Kim Cameron and other folks at Microsoft. It utilizes the WS-* network protocols for transport, and uses a "Wallet" metaphor for vizualizing identy information on client machines through credit card-like graphics.
  

• Windows CardSpace: By this I mean Microsoft's implementation of the InfoCard system on Windows. This includes Vista and the WCS port for Windows XP and 2003.

• IdentityCard: A single instance of an identity holding card in an InfoCard System. IdentityCards can be e.g. Higgins I-Cards holding OpenID information or Windows CardSpace cards.

• InfoCard (Card): The Windows CardSpace implementation of an IdentityCard.

One thing that I am really interesting in finding out is how (and if!) consumers will pick up on the visual IdentityCard metaphor.

I am starting this series of truly random thoughts on various identity-related topics with an area that I have - so far - not spend a lot of time thinking about: Identity for Voice. What do I mean by that?

I have my bank accounts, health care insurances (or not), credit cards, etc. Whenever I interact with these companies and organizations through a phone, they typically try to identify me by asking me questions about the identity information they have about me: PIN, social security number, birthday, zip code, maiden name of my mother, last name of my first teacher in middle school and similarly absurd questions. Based on the capability to give the correct attribute value, they consider me authenticated as "me". A local maximum of absurdity was recently reached in my digital life, when my bank switched to a system where I have to answer at least 2 questions from a list of 10, some of them as ridiculous as "Where does your next relative live?".

There are times, where things get a little more fancy. One example is using caller ID as a means to identify the phone I am calling from. Not only is it quite dubious in my mind that this is a good way to authenticate. Even worse is the fact that there are plenty of ways to fake the caller ID system.
Beyond that, we also have voice recognition (which might get quite good), but there is always the option of a tape recorder and voice synthesization technology. Also, there are call-back mechanisms.

Another problem is the potential for phishing through voice based systems. To address this, there would need tobe a way to authenticate the provider (i.e. the bank, insurrance company, etc.) to the caller, which is - to my knowledge - not easily possible at all at this time.

Quite obviously, I am not really happy with identity in voice UI land. While this might be ignorance on my part (there have to be quite a few folks out there thinking about solutions to this problem), I think that the distributed-services-and-federated-identity crowd that I am working with mostly, is equally disconnected from these problems.

So what can we do about this? First of all, get smart about the the voice ID problems. I have started to talk to a friend of mine working in this area, and he gave me a lot of interesting entry points into the world of voice UI. Beyond that, I suppose we might have quite a few ways to extend security:

• Integrated multi-factor authentication: Voice print, caller ID, call back and attribute knowledge are - by themselves - insufficient. A combination of these might be sufficient for low risk transactions.
  
• Increased integration of electronic and voice technologies: Authentication could be done through a web site (based on strong crypto). The web site would then issue a single use, time limited password, that would serve as an additional authentication factor. There are quite a few technologies available today that I would put into this category, including SMS based authentication schemes for cell phones.
  
• Better Meta Data with each call: If we could transmit meta with each call (e.g. proof of posession of a private key), we would immediately increase the level of trust I could have in a voice communication. While traditional telephones do not offer any reasonable extension points, cell phone or - eve more so - VoIP system can send additional data through a data channel.
  

An additional meta data channel with each call would be - as far as I am concerned - the best solution.  This would allow us to tie the authentication for the voice UI into cryptographically strong identity techniques.

James McGovern asks whether federated identity might require (at least sometimes) federated authorization. I think this is a pretty good question and one that is not easy to answer. My initial take on this would be that federated identity should not require federated authorization, assuming that I understand correctly what federated authorization really is.

For simplicity's sake, let identity be just a bag full of attributes (e.g. e-mail address, names, phone number, etc.). An indentity provider is then nothing more than a service that asserts that certain attributes have a particular value for a given digital identity. A relying party (i.e. a service provider like e.g. AmazingBookStore) can choose to trust such an assertion - either in full, or just certain parts of it. At the end of the day, the relying party will have to determine the level of access based on the type of assertion and the content of the "attribute bag". As such, in this case authorization is local.

If authorization is to be delegated to another point (as in e.g. the XACML model), the relying party forwards it to a policy decision point, where the contained attribute information and additional attributes the PDP might obtain are evaluated according to a set of policies.

Now what is federated authorization? If I understand it correctly, it would be a scenario where you trust access level decisions to your resources to a third party (e.g. you would let YahaPortals.COM decide whether or not a user can get access to data you own). I am tempted to say that the risk that YahaPortals has about a false negative or false positive decision is quite substantial, particularly in our age of increased liability.

While there might be some use cases that do (or will) require such a model, I would argue that XACML provides a pretty substantial technology base for a federated authorization system, should the need arise. Some additional elements for such a system (e.g. trust establishment, crypto, etc.) could be either profiled or application specific.

UPDATE: As usual (at least in the last couple of weeks), I am quite behind things. James apparendly commented on quite a few blogs (hmm, was that related to IIW tagging ... noooo, can't be) and got some pretty substantial answers from Pat, Conor, and Paul.