Every so often, the issue of “Joint and Several Liability” comes up in the world of e-government. It’s usually thrown at me because I run the Government Gateway which “does” authentication and so, therefore, must handle JSL. It doesn’t. And it’s therefore an easy target, as in, “we’d love to make use of the government gateway, but it doesn’t do … yaddayaddaya”.
I doubt that there’s anyone outside the legal profession or a few parts of government, mostly at the local level (but not entirely) that understands what JSL is, so here’s some words from debtclinic.co.uk
“If you have taken out a credit agreement, loan or have a bank account in joint names (with another person) then you are both liable for the full amount of any debt.
This means that if you have a joint loan with a spouse or partner and one of you fails to repay the debt (this often happens following divorce or separation) then the lender could still ask you for payment of the full amount (not just half).
The lender cannot recover the money twice but can pursue both of you, or just one of you for all amounts still outstanding until they have obtained full payment.
Joint and several liability can also apply to rent arrears on joint tenancies, arrears on joint mortgages, council tax payments and water charges on properties that have been jointly occupied.”
In essence, when you sign up for certain financial transactions, it’s quite common for everyone in the household or the family to sign the paper forms. Then, if there are problems later, any one of the signatories can be pursued for recovery of the debt (whether that is a hire purchase agreement, a fraudulent benefit claim or whatever). Nice and simple in the paper world. Or it appears to be.
In the offline world, the problem is that a bunch of signatures on a page doesn’t mean very much. Ask anyone who works in a bank what they verify signatures on checks against and you’ll get a very surprised look. Signature verification happens rarely, only for large amounts and only in a very few places – but where they do, they’ll have a big book with lots of signature samples in it. Ask someone in government what they verify signatures against and I very much doubt that there will be a big book. How would you do it? 60 million samples? Even split across 468 Local Authorities, that’s a pretty big book. The signatures cannot be practically verified, so they’re not. But if there’s a dispute later, you go hunting for the people who purportedly signed the form – and I imagine (I don’t have data on this) that there are very few cases where the signature is the pivotal evidence in the case (maybe 5 a year? 10? 100?).
JSL is a collection of signatures in a box or two on a form. It’s nothing more, nothing less. The signatures could come from anyone, there is no way to relate the signature to an individual or, more importantly, to relate the owners of each signature to each other. The relationship is on the page and nothing more than that. But, it is an important legal concept and one that is hard to throw away – after all, doing away with it would mean having less recourse than you had before.
In the online world, conceiving a solution for JSL is hard. And I know I keep saying things are hard, even brutally hard, right now, but this one is genuinely hard. We’d need some way to identify several people, draw a relationship between them as regards, say, a benefit form and then have them all authenticate that form – imagine a screen with 4 userid and password boxes on it which have to be completed at one time, or passed between the respective PCs of each person for signoff. Or, much worse, 4 digital certificates that all needed to sign the XML and then be unwound at the opposite end to ascertain that the signatures were correct. But, even if I did that, I still wouldn’t know how the people related to each other – I don’t know of a system that stores a variable called “household” and then associates people into that variable. Just imagine the change control and updates on it even if it did exist? People move in and out of houses, students go away, lovers leave, boyfriends & girlfriends come and go – and because it’s a system rather than a piece of paper on file, it would “NEED” to be more up to date than the paper, right?
I spent a lot of time thinking about this around 2 years ago before the Gateway was built and did a lot of work with several departments trying to figure out if it was in any way practical to consider the implementation of some kind of JSL. None of us could come up with an idea, despite a lot of effort. In the end, therefore, it was dropped as impractical at a technology level and, very likely, impractical at a business level. The business didn’t really know who was signing the paper forms and didn’t draw links between them at any level of process, so why should the technology try and make up for a business issue?
There are still people out there who throw this one out as an excuse. Rather than use it as an excuse, tell me how it should be done (please no pitches for products that I just need to install and everything will be ok). Just give me the outlines of how this problem should be cracked in the online world – I await with interest all ideas and input.
