Microsoft made the ruling of the Court of First Instance in Europe available on their web site... this condenses 5 years of my work life into a single document.

tag: Microsoft

Paul and Pam seem to think that my stance on assurances and trust is hard-line.

No Assurance vs. Pseudonymity

Paul seems to agree with me to some extend while noting that a concept like self-issued cards can establish a stable pseudonym. I agree with this: both the Windows CardSpace system, as well as OpenID produce in their basic usage scenarios^[1] stable pseudonyms - not more, not less. But this conveys nothing about the identity of the user controlling this pseudonym. It is purely an authentication process that takes place, with no authorization data being exchanged. In fact, all authorization takes place within the RP system, solely based on the pseudonym. I called that the "No assurance" level, which is - a little - harsh, but still fair.

Pseudonymity and Low-Value Transactions

Pam has more issues with my analysis: initially, she finds it strange that "No assurance", pseudonym-only level of assurance is acceptable at all. Again, I might have been somewhat extreme in my wording: when speaking about "No assurance" I was speaking about a situation, where some authentication, but no authorization took place. So you do have (as Paul pointed out) a stable pseudonym, but absolutely no reliable information beyond that. This, I find completely acceptable to what I coined "low-value transactions" like forums, blog commenting, etc.

Trusting an IdP

Now Pam goes on to point out, that an arbitrary managed card provider has - beyond the certificate that confirms the identity of the IdP to only some extend  - no other trustworthiness to them, making them practically as unreliable as a self-issued card.

I agree totally. That is why I insisted in my earlier article that in order to gain any confidence in the token, the RP has really no other choice but to set the sp:IssuedToken/sp:Issuer (3.1.1 [ISIP 07]) to a WSA Endpoint that the RP is willing to trust. This trust is established through non-technical means, e.g through contracts, reputation systems, etc. But without this tying of the authentication to an IdP you have at least some trust in, you cannot have any reasonable level of assurance about your attributes.

The Energy Level Diagram of Assurance

Thus, I also agree with Kim: assurance is not binary - quite the opposite. For reasons of brevity (and laziness 8-)) I only focused on the two major categories of assurance for authenticated session. So here is now a somewhat more complete picture:

Please note that in this picture "No assurance" refers to completely anonymous transactions (no authentication), while the former level of that name is now name "Pseudonymity".

At the end of the day, however, I come back to the same point I made in my earlier post: technology (as long as it is not blatantly broken, i.e. insecure) bears no significant role in establishing trust or assurance. You cannot create a technology that has "built-in" trust - any technology can be deployed in a completely untrustworthy way.

Even a technology-centric system like SSL rests on the trustworthiness of the browser programmers (that put roots in the CA stores) and the CA companies themselves.

tag: identity, assurance, cardspace

[1] Windows CardSpace: self-asserted cards, OpenID: OpenID Auth 1.1 + SimpleReg 1.0

[ISIP 07]   Arun Nanda, "Identity Selector Interoperability Profile V1.0", Microsoft, April 2007

Well, this is over ... and on to the next.

The last week was quite busy since Mrudul Uchil (from the OpenSSO team), Jiandong Guo (from Metro) and I were scrambling to teach OpenSSO to issue InfoCards for Windows CardSpace and respond correctly to WS-Trust STRs. Overall, it went quite ok and this excercise uncovered a few issues that will help us make the product better. The idea is to make this code accessible to the general public as soon as we can - but please bear in mind that we had to make changes to WSIT/Metro and OpenSSO, and some of these are not (yet) considered critical for the products. Nevertheless, I will be working towards a release for the IIW 2007b timeframe, so that we can progress.

Eve posted a couple of thoughts and some nice pictures of the interop session ... go check it out.

tag: identity, interoperability, InfoCard, opensso

This comes through Lauren. I can only fully agree with her recommendation of watching and sharing this clip with anybody that has kids or is concerned about the security of our children.

This is very creepy and shows the high level of immorality of the toy industry. With aggressive data hoarders like this, it seems more urgent than ever to even go beyond an opt-in regime (which we do not - yet - have in the U.S.) and put heavy financial liability burdens on any company holding or handling information about children under 17. Also, I think that consent mechanisms for children must be changed in a way that makes it impossible for children and parents to consent to privacy regimes that can be detrimental to children.

What makes this even more scary is that local governments are obviously not fully aware of the privacy ramifications of these organized privacy violators. For example, the Town of Burlington, MA, offers through its recreation department a class (see here, p. 5) for parents and children to make special "things" for their WebKinz.

tag: identity, privacy, policy, children, ID Theft

Tim Bass responds to my objections to his earlier article on the immaturity of modern identity protocols. He makes the valid point that the maturity of a technology should not be measured by the time it has been available, but by the level of adoption and actual deployment numbers:

"On other other hand, I am measuring “maturity” by actual usage, and the proof of security solutions is in the actual adoption, not simply years of standards activity and vendor marketing." (Tim Bass)

I fully agree with Tim that this is a very important factor in evaluating the maturity of a given technology, probably more important than the technologies availability. In fact, my earlier post was not very clear on this. On the other hand, I do believe that an extended peer review with subsequent revisions does contribute to the maturing of a given technology.

It turns out that SAML and its related technologies (Shibboleth and Liberty) excel in both these requirements for maturity:

1. As I pointed out earlier, SAML (the concepts as well as the technology) has been peer reviewed since 2001 by a number of very different organizations such as OASIS, Liberty Alliance, and Internet 2. This extensive review process resulted in two subsequent versions, that incorporated security fixes and enhancements, as well as new features. It has very broad community and industry support from open source projects, universities, and companies like Microsoft, Oracle, Novell, HP, Sun and many, many others. For more information take a look e.g. at Eve's blog or Scott's presentation.
   
2. SAML has been deployed on a very broad scale. There are a number of not-so-visible financial and telco deployment that are huge, but also the highly visible higher education deployments (see here). In fact, there are few (if any) other web centric identity related technologies that can boast an adoption comparable to SAML.
   

So, at the end of the day, I still maintain that Tim's assessment of SAML as an immature technology is - at least - incomplete.

tag: saml, identity, protocols, cybersecurity, standards

Constantin describes in this article how to create an DVD-Audio disc on Linux/Solaris (and also emphasizes the difference between DVD-Audio and DVD-Video).

I assume that most people who are interested in DVD-Audio know that there are also commercial DVD-A solutions out there, like DiscWelder.

However, for the task at hand Constantin would not have needed to create a DVD-Audio disc, but instead could have simply used his favorite DVD-Video authoring tool and create a stereo 96kHz/24bit LPCM track on a DVD-Video. All fully compatible DVD-V players must support this format, thus you do not have to resort to DVD-Audio.

This is obviously different for multi-channel formats where the DVD-Audio format is the only viable alternative. For high-resolution, multi-channel tracks, you will also need an MLP encoder ... and here we are talking about some serious licensing fees.

tag: DVD-Audio, DVD-Video, High-Definition

PS: Here is an overview on the DVD-Video audio capabilities.

Paul picks up on an article by Pam about level of assurance with Windows CardSpace. He emphasizes the important point that assurance is not only affected by the underlying technology, but also by non-technical parameters like contracts.

I would go one step further and say that LoA is almost exclusively affected by non-technical factors. To be able to put any trust into a given authentication system (let alone an authorization system) you need minimally:

1. A contract between the RP and the IdP
2. A contract between the user and the IdP

Both contracts need to have provisions for the following areas:

1. Data governance (including privacy assurances and data handling)
2. Fault handling
3. Data updates
4. Contract termination
   
5. Liability
   
6. Arbitration and conflict resolution
   

Without such a framework most authentication and all authorization systems are only useful for 'low-value transactions' such as blogging or simple social networking. Or - in other terms - there is no level of assurance, even if the underlying technology supports the most fancy certificates or crypto algorithms.

Obviously, contracts of such kind can only be meaningful and economically viable, if the underlying technology is not broken and has the necessary features to support such provisions^[1].

Now, as far as the Windows CardSpace identity system is concerned, there are indeed multiple levels of assurance for the RP:

1. No assurance - self-managed cards, or any managed card where the Issuer is not enforced by the RP
2. Assurance - managed cards where a particular set of Issuer(s) is required by the R

Only in the later case there can be a reasonable level of trust by the RP that the user is actually who he/she claims to be relative to a given IdP. In that case the contract provisions between the RP and the IdP are in effect and it will depend on them how much trust the RP can put into the authentication and attribute statements.

The Liberty identity system has the necessarily technology and the business and legal frameworks for providing a very high level of assurance, but they are currently not ideally equipped to address the needs of little or no assurance (which typically include fast and extremely easy deployments). Hopefully, openLiberty wil help address these issues.

tag: identity, WCS, Liberty

[1]Thus, any identity system that relies on an universal federation (i.e. any IdP is admissible) cannot provide any meaningful level of assurance.

When you are working with Glassfish (like I am doing now), you might need to capture your HTTPS traffic. In an earlier post, I explained how to capture and decrypt any SSL/TLS traffic, as long as you have the server private key.

While this method is quite effective and universal, it is still a little cumbersome, especially since the actual SSL decoder in Wireshark is not yet fully integrated into the analyzer itself.

For Sun's Glassfish application server, there is a fairly simple way to monitor any web services HTTPS traffic:

simply go into the domain.xml file of your domain and add the following <jvm-options>:

<jvm-options>-DWSIT_HOME=${com.sun.aas.installRoot}</jvm-options>
<jvm-options>-Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true</jvm-options> <jvm-options>-Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true</jvm-options>

The server.log (in <installRoot>/domains/domain1/logs) will then contain the fully assembled web services exchanges.

tag: glassfish, java, wsit, SSL, HTTPS

Sorry, due to a recent surge in Trackbacks, I have deactivated this feature for the time being. Spammers are really an annoying bunch ...

What made it now just unbearable is that my blog was being misused to advertise the services of the worst health insurance that I ever had: United HealthCare. My conscience does not allow me to help this highly incompetent and - at times - immoral company in any way. It says a lot about a company (especially in HEALTH care) when they or their agents employ SPAM tactics to get people interested in their offer.

tag: blogging, spam, trackback

It seems that history is about to repeat itself: after Liberty formed, a lot of people wither felt left out or did not understand what all this 'identity stuff' was good for. Granted, Liberty was in 2002 about 5 years ahead of the rest of the market. At the time, I thought that this perception problem could be attributed to some abysmally bad marketing - I guess that this was only partially correct.

Today, the same complete lack of understanding is about to hit the "user-centric" identity community as well: Take a look at a post by Brian Huff and compare that with this post from Tim Bass (via James McGovern).

It seems astounding to me that both authors (who claim to be working in 'SOA') have so little understanding of the problems, technologies, and solutions in the identity space. Granted, I am a geek working in this area, but both Tim and Bex claim to be architects and decorate themselves with shiny titles (CTO, CISSP, Oracle ACE Director). They should know better.

Both advocate (in so many words) 'a simpler identity system' (heard that one before) and 'authentication - and that's it'. Both paint existing standards in a very bad light, describing them as 'immature, confusing and less-than-proven  security standards' or asking 'Makes you wonder why people bother to call them "standard," doesn't it?'.

Ok, guys you do not understand identity - get over it and hire someone who does. The good old days where everyone was getting ready for the global directory and its PKI are over. It's not only about authN and authZ in these days, but about the much bigger business and regulatory issue like trust or identity theft.

It seems that the larger identity community (Liberty, InfoCard, OpenID) is about to experience the same pushback that Liberty was facing initially. Let us hope that our joint communication efforts today will help to get over this 'perception gap'.

--

Here are a few comments regarding Brian's post:

1. CardSpace, OpenID, SXIP, (parts of) WS-*
Are not even by the widest possible definition standards, but rather a collection of protocol specifications. Some of these are even proprietary, IPR protected technologies (e.g. SXIP) that are not even covered by a NAC. Also, why are you not including real identity protocols by industry consortia, that are free to implement like e.g. ID-WSF?

2. SPML, XDAS
These OASIS standards have - per se - nothing to do with identity. They *touch* upon identity and security, but are not core to it. Otherwise you should also include HTTP, IMAP, SOAP, and even TCP.

3. LDAP, SAML 2, (parts of) WS-*, XACML
The are (in a wider sense) identity and security related standards. But so are many, many others (Kerberos, X.509, WSPL, XML-Enc, etc.) that you chose to omit. And interestingly enough, most of these standards build on each other or are complementary. So where is the issue?

4. The API issue
There is no unified, standadized API to all these protocols? For starters, only protocol organizations typically create protocols, not APIs (one notable exception is the GSS-API). If you want to create a 'standard' identity API, go to the JCP and suggest a JSR. That organization is probably the body with the biggest amount of standardized APIs, and it is - by most standards - fairly open today. On the other side, if you take the contract-first approach serious, every WSDL or SOAP profile is a reasonable API documentation. In fact this approach allows you select your platform of choice.

Regarding Tim's post:

His list of immature protocols is simply ridiculous: SAML - well established since 2001: go ask the Shib folks, who are running the larger chunk of the academic environment on this protocol. XML Enc and Dsig - yes, there are a few problems (authenticated encryption or key exchange), but none of these problems are insurmountable and have been solved for a long time.

tag: identity, saml