Back to it ...

I'm a Dad!! We have a beautiful daughter ... and we are enjoying the adventure of parenthood!

And this post will mark the end of my foray into self disclosure for a little while ... the iNK blot will tack towards things that are a little less private :-)

37 weeks ...

My wife is 37 weeks pregnant. This is going to be our first child and we are nervously excited!

The more emotionally open parents in our community tell us with joyful self-disclosure that we are going to experience a complete transformation of our lives. Something about a whole new set of wavelengths suddenly becoming visible. I am looking forward to it ... but not without a whole lot of introspection (of course!!).

Laden with a mind that does not like to switch off and can't tell the difference between when its valuable to think about something and when its not, I am finding the waiting to be quite the experience. Thinking about the coming change is largely useless ... but my idle cycles love to go meandering as I try and figure out whether I have any hope of being a decent parent and what I need to do to try. I find that I have a heightened awareness of the neuroses of my family. I am watching with horror at the way the human race has collectively consumed itself into a recession. And don't get me started on sustainability ... why aren't we more het up about how willfully ignorant our community is on what it can do to turn the tide.

This will not do - I feel a sense of failure - I have not been able to fix the world in time for the arrival of our little one.

But when I do switch off my mind, or rise above the chatter to be in the present a bit more ... I am delighted at how wonderful things are for us - how privileged we are to live the life we do - and how happy my lovely wife is as she anticipates the arrival of our child. Its just amazing to see that she is ready to be a mother - like magic, she is fully equipped to protect and nurture her little one with unconditional love.

What a ride ... :-)

So I haven't been writing for a good while ...

... and should do something about it.

Trust Ratings

The story thus far can be summarised with the following key points:

• Identity Management has traditionally been viewed as necessary for compliance with regulation and also as a driver for cost reduction and efficiency of operations (ala enabling smoother provisioning and de-provisioning of user credentials).
• Customer Management, through CRM products, has been viewed as necessary for marketing and cross-selling of services and products.
  
• The concept of trust can be (coarsely) measured by mining the data that is collected over time as a Subject transacts with a Relying Party.
• Identity Management becomes exciting to business people when it is shown to relate to their primary, revenue generating processes. Relating Identity Management to Trust via a trust rating is what allows this connection to become obvious.

The concept of a trust rating is not new. eBay has been using it for a while and using it to enable a more satisfactory experience for its customers. Their version of a trust rating is captured in their Feedback score. On each transaction, buyers and sellers rate each other using on a simple scale of Negative, Neutral or Positive. eBay provides the number of transactions that a user has conducted next to their username and provides an easy link from this number to data about the user and in particular, the proportion of transactions that were rated Positive. A Relying Party assesses the trustworthiness of the Subject they want to transact with by taking into considerations these two parameters which essentially encapsulate the transaction history of the Subject. They accept the risk of a transaction because they can develop a reason to trust the person they are about to transact with.

The eBay trust rating is simple, quite coarse in its measurement, and by no means infallible. However, it is a simple and effective first step towards introducing a mechanism for communicating trust in the closed and controlled environment that is the eBay marketplace.

In general, every system will have its own definition of trust rating - one that captures the general health of the transaction history of the Subjects in the system. Let us design a simple trust rating for an Internet banking application, where we take the perspective where the Relying Party is the bank and the Subject, a customer. First we need to measure the health of the transaction history of customer - define a Customer Transaction Index (CTI) that takes values of Negative, Neutral and Positive where:

• Negative corresponds to a bad transaction history - e.g. the customer has had more than 2 instances of an overdrawn account (account balance negative);
• Neutral corresponds to a lack of transaction history (a new customer) or no more than 2 instances of an overdrawn account;
• Positive corresponds to a transaction history that involves at least 3 months of transactions and has no instances of an overdrawn account.

Also, assume that the business intelligence products used by the bank are able to measure whether a customer is profitable or not. Then, the trust rating for this system can be a function of the CTI and the profitability of a customer via the following (draw a simple table to see this more clearly - I will get around to having one here shortly):

• Trust rating = 1 (lowest) if the Subject has CTI = negative or if CTI = neutral and the Subject is not profitable;
• Trust rating = 2 (medium) if the Subject has CTI = neutral and they are profitable, or, if their CTI = positive and they are not profitable;
• Trust rating = 3 (highest) if the Subject has CTI = positive and they are profitable.

Clearly the CTI and trust rating would have to be recalculated on regular intervals (say, monthly).

Now, the delivery of the Internet banking service can be tailored to accept more risk for customers with trust rating = 3 and less risk for customers with trust rating = 1. For example, the daily limit for payments might be increased by 20% for customers with trust rating = 3 or a periodic bill payment that might result in an overdraft can be honoured (within reason!) and trigger an e-mail or SMS communication to the customer that informs them of the overdraft.

This kind of mechanism will provide the bank with the ability to enhance its service delivery for those customers who it wants to keep and wants to reward for being well behaved. Unlike the current state of online service delivery, not all customers will be presented with the same service experience - the fact that they will be acknowledged and rewarded for being "trusted customers" will only go towards increasing their loyalty to the bank. This will only increase customer retention and brand strength.

First posted on Thursday, July 13, 2006 at 08:38PM

Risk and Trust

In my last post I talked about a trust rating. In this entry I will lay the foundations for a formal definition of this concept and set up the context within which to discuss using it to enrich online service delivery.

Let us set the scene by considering the actors involved in an online transaction. Typically there are two - a Relying Party and a Subject. The Relying Party is the one relying on the authenticity of the transaction. The Subject is the entity transacting with the Relying Party. Usually, the Relying Party has more to lose than the Subject if the transaction goes wrong. In most Internet banking transactions, the bank is the Relying Party and the Subject is the bank's customer who is conducting the transaction. A customer who is aware of the threats of Phishing and Pharming attacks could very well consider themselves to be the Relying Party and the bank's website, the Subject of their transaction. Simplifying things somewhat, the Relying Party relies on the successful authentication of the Subject.

Consider then the following assertions:

• Risk is traditionally regarded as a function of the impact of a threat and the likelihood that the threat is realised. The risk associated to a transaction between a Relying Party and a Subject requires context - the risk to a Relying Party is typically greater than the risk to the Subject (usually because the Relying Party carries more liability than the Subject).
• Trust is typically a label assigned by a Relying Party to a Subject. It is a function of the behaviour of the Subject as they conduct transactions with the Relying Party over time. A brand new customer is "untrusted" whereas a customer with some transaction history may be "trusted" or "not trusted," depending on whether they have been good customers or not.
• The Risk that is accepted is very much a function of the trust that is placed by the Relying Party in the Subject. Quite simply, the Relying Party will take a larger risk if they trust the person they are transacting with. This is because the likelihood of a threat being realised is intuitively assessed as being lower when the Subject is trusted.
  

Acceptance of risk is a function of trust

Note that if you play the role of Relying Party, you can't decide whether or not you trust the Subject until you have authenticated them. However, once you have authenticated them, and, established that they are a trusted customer, you have the opportunity to adjust the delivery of services to them. This is exactly what we have been doing in face-to-face service delivery for centuries - let's start doing it in the online service delivery context.

Customer Relationship Management (CRM) systems have been designed to mine the data collected on customers, usually with the purpose of tailoring and targeting the products and services that are sold to them. I claim that by viewing Identity Management in the same context as CRM, we see the whole picture of authentication, better service delivery, better cross-selling of services resulting in improved customer satisfaction with online service delivery and better revenues! More on this in my next post.

First posted on Wednesday, July 12, 2006 at 08:58PM

Identity Management and Trust

It seems like we have been confusing the establishment of trust in an online environment with identity management for quite some time now. We have a keen intuitive sense for what it means to establish trust in "face-to-face" service delivery environments (e.g. I am a long time customer of my bank and thus I am a valued and trusted customer) but this seems to be missing in the context of online service delivery. We seem to have very narrow focus on the authentication problem in the online service environment - lots of time and energy has been spent on understanding various types of "multi-factor" authentication techniques but very little effort seems to have gone into explaining how this will enrich the service delivery experience for the customer.

I would like to suggest that the answer lies in the vast amounts of data being collected by our servers as our customers conduct business with us over the Internet or the phone. It's time we began to think about a trust rating - an analogue of a credit rating if you will, but one that measures the trust quotient of the entity we are transacting with. This will enable us to customise the delivery of an online service to temper the risk inherent in the transaction with the trust that has been engendered by the good behaviour of the entity.

First posted on Sunday, June 25, 2006 at 08:58PM