… 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.