Gerald Beuchelt

Privacy and Identity Management

Starting with Novell's eDirectory and Active Directory, I have been working in identity management-related fields now for more than 12 years. While the technologies change, the complexities and issues have remained the same. My current architectural work is very heavily focused on identity management and privacy, and I have joined the Liberty Alliance and the Kantara Initiative as an individual member.

My current focus is mainly on the interactions between identity management and privacy, and to this extend I have been working closely with Robin Wilton and other Liberty members on starting a comprehensive privacy program at Liberty. My main goal is to work towards a privacy management framework that builds on existing work by the ISO/IEC, W3C, and other standards bodies, including Liberty's own IGF work.

In the past I have been working on identity management interoperability, especially in the context of Sun's OpenSSO/Access Manager product. To this extend, I lead a project rolling out an OpenID provider for Sun employees and coordinated OpenSSO/Windows CardSpace interoperability testing and development.

Interoperability

The issue that always fascinated me most was and is interoperability, i.e. the ability to have distinctly different systems exchange well-formatted (syntax) and meaningful (semantics) messages. This is a very hard problem and in many cases interoperability is more a goal to strive for than one that we could actually reach.

There is a reasonable classification of interoperability and related concepts in the military; in fact, NATO and the U.S. government actually defined interoperability and created a system to classify how good interoperability gets: the four levels are compatibility, interoperability, interchangeability, and commonality.

Beyond this degree of interoperability it is also quite important to properly scope the application domain of interoperability. For example, two computer systems can achieve perfect commonality on the network transport layer, i.e. TCP/IP, yet be completely unable to interoperate on the application layer. This would happen if you try to use telnet from to create a remote desktop session to a Windows machine.

The holy grail of IT interoperability is obviously commonality for applications. Just as with the finding of the holy grail, this goal has proven itself to be rather elusive. Once more, the path is really the final destination.

There are some areas of technologies that enable (or hinder, depends on your view point) interoperability. Of those I am interested in the following:

Web Services

While even the definition of web services is not too precise and varies over space and time, I am interested in applications and autonomous services that are layered on top of HTTP. As far as I am concerned, this is currently the best definition of web services. One special case is not covered, though: distributed applications that use similar patterns as web services, but different transport bindings (e.g. SOAP over TCP).

SOAP (Simple Object Access Protocol) is certainly an interesting technology, although it has become fashionable to dismiss it as too bloated, since it is--well--too bloated. Instead, people are looking now more at architectural patterns like REST. A RESTful approach can remove a lot of unnecessary baggage that SOAP and comparable technologies carry around. Tying these light-weight service design patterns to a comprehensive identity management strategy seems vitally important in the days of network-centric computing.

I am currently looking into making web services more efficient and less complex. To arrive at a lower level of complexity, it seems important to me to push some of the functionality like security again further down in the stack of protocols. My GSS-SAML proposal was focusing on this, and it seems that the MITKC is picking up on these ideas.

Security

My interest in security goes back some time. In my first job in the U.S. is was focusing on Active Directory and its security systems. The Kerberos subsystem was quite interesting, in particular since Microsoft decided to use the then rarely utilized AUTH_DATA field for storing the NT security token (PAC data). This along with some other profiling issues created a highly non-interoperable
system, which was nevertheless based on open standards.

My current ideas, as already mentioned, are focusing on driving security again further down the stack. At the same time, it seems prudent to me to allow for proper application-accessible security. By that I mean that even if the underlying platform deals with most aspects of security, the application developer still needs some configuration options to adjust his application and its security. 

Operating Systems

For a long time, I had a knack for operating systems. Not that I understand a lot about them, but I simply like to play with them. I remember well when I was first standing in a general shop, playing with the Commodore VC-20 on display, starting
to write some simple BASIC scripts. Later I had a lot of fun with a variety of systems, including my C64, my father's office system (much to his dismay - it was a RAND Computers CP/M and MP/M box and I got more than once in trouble for hacking away) and then with Windows 2.0.

When Linux entered my world, it was at kernel version 0.99.7. I was working in a large datacenter on a Cyber 2000 with NOS/VE and a Cray Y-MP with UNICOS.