Mike made a very good remark on the OSIS General mailing list that seems relevant to the discussion between Pam, Paul, and myself about assurance in distributed security:

There's a reason that self-issued cards didn't provide any ability to transmit a credit card number or national ID number. The good news is that Identity Providers sending such sensitive information are likely to not be willing to transmit it to relying parties they don't have a business relationship with. Once you're using managed cards for payment rather than typing credit card numbers into web forms, you'll definitely have additional layers of protection working for you. [...]

I fully agree with Mike here: as fas as I understand, Mike is describing the IdP deployment model that Paul and I have been championing over the use of self-asserted cards for sensitive attributes.

tag: assurance, identity, cardspace

Paul found an "periodic" table of data visualizations, which is quite nice in its own right (Paul: I think I have seen a knowledge map of the identity landscape some time ago). But I certainly prefer this "periodic" table of ... beers (hmmm).

tag: humor, beer

Through Nico Williams a real interoperability story:

Alan Wright reports that the Solaris team recently completed the Solaris kernel CIFS service. That's right: CIFS (i.e. Windows networking) is now on par with NFS and other kernel-level system services. To be able to achieve this goal, the Solaris folks had to create some really innovative pieces of technology:

• To allow Windows style SIDs in the process credentials, they are now allowing negative and ephemeral UIDs and GIDs.
  
• ZFS now supports all kinds of DOS attributes and full NTFS ACLs, i.e. ordered ACEs with SIDs.
  

All persistent data (like filesystem records) are dealing with actual SIDs, while non-persistent kernel and memory objects are using the ephemeral negative UIDs. The later are not stable across a reboot, but an ID mapping daemon performs the necessary translation between the SID and its UID.

With this new technology on the horizon, my new home project on a Solaris storage appliance for the basement ("Codename Filer") looks brighter than ever ...

tag: interoperability, cifs, solaris

... that I will not let anybody break my windows - also, they seem to be a little stronger than the Jones' windows, at least the big one in the spotlight.

In the latest round, Pamela explains how a particular authentication should be considered to have a particular level of assurance. Paul takes the time to address some of the issues Pamela raises, but before we loose track of where we started, I would like to point back to the initial discussion between Pam and Paul:

Paul wrote:

In discussing Cardspace's relaxation of the SSL requirement for RPs, Pam writes

We now theoretically will have three different assurance levels going, based on three different ssl certificate levels (no certs, regular certs, and HA certs).

For there to be 3 Cardspace assurance levels would imply that the LoA is the same for self-asserted and managed cards. Is this the case?

Pam originally thought about three levels of assurance that were bound to the level of the certificates: none, regular, EV^[1]. Paul noted that the level of assurance depends on a number of factors, with technology and deployment architecture only having a small part in this. Paul and I then tried to elaborate in more detail how technical and non-technical factors affect the assurance an user and a RP can place into the transaction.

The reason I started this discussion was that - in my mind - the security certificate used in a particular authentication or authorization transaction is essentially only one reputation factor: by wielding an SSL or EV certificate you demonstrate that a particular company (the CA) thinks that you are who you say you are. This certainly affects assurance, but - by itself - it is rather useless.

The identity provider model (which derives from the mutual trust model in Kerberos) adds a very significant layer to the assurance model: It goes beyond the generic assurance by e.g. a CA by offering information (authentication, attributes) about a particular group of users - the IdP is by far more specific than the CA. Additionally - as Paul points out - a trustworthy IdP is typically a company with deep pockets - someone a RPor an user can sue for damages if something goes wrong. Note that the Windows CardSpace system support such an IdP deployment by using managed cards with Issuer policy. I expect this to be the default deployment for CardSpace, if it gets selected by large organizations.

Self-issued cards or managed cards from any IdP (the OpenID model) do not offer the comfort of sueable deep pockets to the RP. A RP that trusts an authentication that is done by anyone but himself will find himself in a rather dangerous situation: if something goes terribly wrong (e.g. some nasty mal-ware rootkit stole my self-asserted cards along with usage logs and sent them to a criminal for use with my bank) the burden is then on the RP to prove that the authentication token it received did not originate at my Windows CardSpace client, but at the criminal's computer. In an IdP model this burden is with the IdP^[2].

Thus with all respect to Pam's critique, I do have to insist on my original point: the technical factors (like an EV cert or lack thereof) play some role in the level of assurance, but only to establish a baseline. What allows RPs and their customers to truly trust in an identity system are the deployment parameters (including such "mundane" but at least equally important things as e.g. physical security), and - most importantly - the established mechanisms of society for enforcement, arbitration, and liability management.

tag: assurance, cardspace, identity

[1] By the way: the recognition that different types of security certificates might even on influence the assurance you have about a transaction invalidates Ben Laurie's argument that third parties do not add additional assurance.

[2] If I were a cynic, I'd might come up with this argument: Since there is likely a contract between a RP and an IdP, and the IdP has all kinds of lawyers working for them and an interest in precting itself and its users (to a degree), the RP would actually be much better off with self-issued cards: if something breaks, the RP can

• blame the end-user about their lack of security precaution and sue them for negligence,
  
• rest assured that no large number of lawyers will counter-sue them,
• offer the end-user a token of reparations ("We will cover 50% of your losses") and earn tons of goodwill for marketing purposes.
  

Fortunately, I am not a cynic.

Paul Trevithick just announced that Higgins will start developing a SAML 2.0 compliant card selector, that will - in addition to Windows CardSpace compatible i-cards - support SAML 2.0 compatible "s-cards"^[1]. This will be quite interesting to follow, in particular if Higgins really supports the SAML 2.0 protocol (not only the token format). In that case it would really step up to be part of the identity meta system (actually: the Aleph 0 Identity System ).

PS: Welcome in the blogosphere, Paul!

tag: saml, identity, higgins, liberty

[1] Paul Madsen made some interesting remarks about that name...

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.