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

pwd-->self-asserted-->managed-->managed/contract 

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

Tags: Cardspace, assurance