Friday, November 02, 2007

Guarding against sewer backup (or more on assurance)

Update #2: Axel comments that there are meaningful gradations between 'managed card' & 'managed card/contract'. I agree. I tried to dance around the possibility of something less than a full contract between the RP & IdP by allowing for the RP to 'have a relationship' with the IdP. Axel's scenario is perhaps the loosest sort of coupling possible. The RP knows the IdP 'by reputation' and that's deemed sufficient. If I were to redraw the X-axis it would look like


-->Coupling strength-->

I tried to explore this continuum between "I've never heard of this IdP before" and "we're basically attached at the hip" in a previous post.

Update: Eric comments that he doesn't understand why there is no assurance difference between a self-asserted card and a managed card. The premise is that a managed card, unless accompanied by some sort of relationship between the identity provider and the RP, gives no more assurance than a self-asserted card. I might even argue that it provides less assurance, given that the RP would be relying on the IdP but without any business justification for doing so. Fear of the unknown etc.


I have one of those one-way valves on my basement drain to protect against sewer water backing up. I also have home insurance that limits my liability should this happen despite the valve. With respect to this particular risk, my comfort level of 'asscoveredness' feels sufficient and I can sleep at night (unfortunately not well since getting back from Tokyo last week).

That's how I think of assurance, a combination of technical & non-technical mechanisms that engender for RPs a sufficient (for whatever applications) feeling of 'asscoveredness'. While in theory both types of confidence can exist in siolation, generally it's their combination that allow RPs to sleep at night when accepting identity attributes from an IdP.

For permutations of Cardspace deployment, I believe the degree of technical confidence (for authentication) that an RP might have looks something like the below (password thrown in for comparison). I'm allowing for a self-asserted card, a managed card, and a managed card from an IdP with which the RP has some sort of business relationship (not necessarily a direct contract).

Note: not drawn to scale.

For the RP, this sort of assurance if 'confidence that nothing will go wrong', this arising from trust in the security characteristics of the system and the processes of the IdP (there may be differences in security characteristics between self-asserted and managed cards - I'm ignoring any here). Note that the existence or not of a legal relationship doesn't impact the technical confidence.

Separate from the above sort of technical confidence is business confidence, namely 'confidence that if something does go wrong, I'm not on the hook beyond what is appropriate for my business model'.

The key difference here is that the existence of the business relationship with the IdP makes possible for the RP (but does not guarantee) a nice warm feeling of comfort that, even should the technical mechanisms fail, it won't suffer undue harm (somebody else stepping in).

If you put the different types of confidence together, you get an assurance profile that looks something like

Separately, I must remember to check the batteries on my smoke detectors this weekend. And check my fire insurance coverage.


Anonymous said...


Eric Norman said...

The combined graph shows no change in confidence from somewhere in self-asserted cards to somewhere in managed cards.

Is this supposed to represent the case where a user operates their own IdP? That's the only sense I can make of it.

Unknown said...

I think there is (or should be) something between managed and managed/contract. In the case where the RP does not have a contract with the IdP there still is a difference between "some IdP" and "a well known IdP". If e.g. T-Mobile would issue a managed card that asserts my customers telephone number or billing address, I as a RP, would trust this assertion because there is no incentive for T-Mobile to lie. I believe in the technical security and correctness of this claim but additionally I trust T-Mobile even without a contract. And even if the assertion is wrong with a very low probability then still it might be beneficial for my business to trust this assertion even without a contract.