Mark Lizar is the Secretary of the Privacy and Public Policy Work Group (P3WG). Mark has been active with the group since June 2009 and is an important part of the team and the ongoing development of privacy and trust frameworks.

Hailing from Canada, Mark now lives in London, England. Mark’s has an interesting education studying in computer science, network engineering, law and sociology. Mark worked in technical security, testing token authentication and RADIUS servers. He also worked at Entrust, which was an enterprise PKI (encryption) organization. Since then, Mark’s efforts and interests have been in the trust side of identity.

In Mark’s spare time he enjoys family & friends, playing the drums, and traveling. Learn more about Mark here

Find out about Kantara’s P3WG and how to become involved here

Abbie Barbir (http://www.oasis-open.org/about/distinguished-contributors.php) has just been elected by his peers to Chair the Kantara Initiative Privacy and Public Policy Work Group (http://kantarainitiative.org/confluence/display/p3wg/Home).

According to Abbie, the Kantara Privacy and Public Policy WG (P3WG) plays an important role in identifying the steps that are needed in the community to help ensure better privacy outcomes for users, data custodians and other stakeholders across the Internet and other public domains. The P3WG intends to be actively engaged with other stakeholders such ISO/IEC JTC1, ITU-T SG 17 and OASIS to ensure that common frameworks, privacy-enabling technology (PET) standards, operational criteria and privacy-enhancing culture, policies and best practices are adopted at the international level. Abbie Barbir invites all interested individuals to participate in this important activity by joining the P3WG today (http://signup.kantarainitiative.org/?selectedGroup=8).

As you may know, I’ve recently set up the Privacy and Public Policy Work Group (P3WG) for the Kantara Initiative, and as we start mapping out the areas in which the Group wants to exercise an influence, one topic has generated more discussion than anything else on the mailing list. It goes by the rather uninformative name of “LOA”, or Level of Assurance. Even if you’ve never heard of LOAs, they have played a major part in your life online and off.

I’ve blogged before about what I call the “Chain of Trust” – namely, the sequence of events all of which need to be working if a credential is to work properly when you present it. In other words, for instance, if you apply for a passport in the name of Michael Mouse and the passport office doesn’t bother to check whether there’s any evidence that that is your name, the resulting passport won’t be that reliable as an indicator of your identity (even though people may assume that it is). Similarly, driving licences would not be much use as an indicator of which vehicles you’re entiteld to drive, if it was possible for you to alter what the licence says… and if you tell someone the PIN of your ATM card, it is no longer effective as a way to ensure that only you can take money out of your account (in fact, the bank is likely to take it as de facto evidence that you must have been responsible for the transaction, even if it wasn’t you who actually used the card and PIN…).

These are just three examples of the many ways in which the Chain of Trust can fail, at the Registration/Verification phase, over the life of the credential, and at the authentication step, respectively. There are many other points at which the Chain can be compromised and the reliability of the credential (or the assertions made using it) undermined.

LOA is about protecting the first of these – the point at which someone decides whether or not to issue a credential which represents you in some way. In other words, if you can present a relying party with not just a credential, but a ‘score’ which indicates how reliably that credential was issued to you, can judge whether it’s more likely that you are actually Michael Mouse, or that whoever gave you a passport saying so was not doing their job very well.

That, in turn, will give them useful information about what decisions to make next, particularly if they decide that the answer to your authentication question is “yes”.

The UK and US governments both have relatively simple 4-level LOA models (though, inconveniently, one runs from 0-3 and the other from 1-4…). Omitting the ‘index value’ for a moment, the four levels look remarkably similar. In fact, if I adopt a slightly different scale, just to paper over that difference, we might get something like this:

Rare

UK: no authentication of identity

US: little or no confidence in the asserted identity

Medium rare

UK: basic authentication

US: some confidence in the asserted identity

Medium

UK: greater level of assurance (e.g. credentials based on proof of identity to a third party)

US: high confidence in the asserted identity

Well done

UK: identification beyond reasonable doubt

US: very high confidence in the asserted identity

So far so good. However, when it comes to putting this simple model into practice, and because we’re talking about assurance here (and therefore judgement), a couple of different approaches emerge.

One is to give a technical specification of the kinds of authentication technology which should or must correspond to an implementation claiming to be at a given LOA level.

Another is to relate the LOA levels to levels of risk, and allow the implementer to work out how they think that risk is best mitigated.

You might think that a third, better solution would be to combine the two… define organisational risks in a way which allows them to be assessed against the four-level model, and then have a technical specification list which says: “if you face this level of risk and you want this level of assurance, you need technology such as ‘x’, implemented with the following governance measures.

Actually, I have a better idea… if you have opinions on this question (better still, if you have a good answer), come and sign up to the Kantara P3WG and join the discussion. We’d love to hear from you.