Category: User centric

The database state?

Britain's Ian Brown (author of Blogzilla) is inviting people to a conference at University College London on the first of November:

The UK government is pushing ahead with an ambitious programme to re-engineer the processes of public administration, based on wide-spread sharing of personal data between previously isolated departments and agencies. This is being backed up by proposals for the weakening of data protection law and the building of massive national databases on both adults and children.  

Is widespread data sharing a panacea for effective 21st century government? Is it legal within the European privacy framework? Or, as Tony Blair has claimed, are we living in an entirely new world in which we should leave behind “outdated” notions of human rights?

This workshop will bring together lawyers, technologists, regulators and activists with a shared interest in the development of effective and privacy-friendly government. It will feature expert speakers on two major UK databases: the children's Information Sharing Index (which will hold details on every UK child) and the NHS Care Records Service (which will eventually hold all medical records electronically within the National Health Service). But most importantly, it will give all participants the chance to discuss their views on the privacy principles that should lie behind public administration in the information age.

Places are limited, so please RSVP to I.Brown[at]cs.ucl.ac.uk if you wish to attend.

Gee.  I wish I were able to attend, because I would like to add some questions that interest me more than the political ones: 
  • Where are the actual goals defined for the databases?
  • What other mechanisms have been examined as alternative ways of achieving those goals?
  • Where are the studies in which alternative technologies were compared and large central databases selected as the safest answer?
  • Where are the security threat analyses of these databases published for public review?

It sounds fascinating – I hope it will be podcast.

 

Whobar identity 2.0 technology now available as open source

Not only does Whobar support InfoCards and related identity technology, but check this out:

Sxip is pleased to release the Whobar code to the community.

Whobar makes it easy for users to register and login to a website using their choice of emerging identity protocols such as InfoCard, i-names, and OpenID. It enables developers to easily add support of all these emerging Identity 2.0 technologies to their site. The benefits of this for users is a common website login experience. For web developers, to streamline their user registration and login process so that they don’t need to store user passwords, nor users needing to remember yet another password, thereby improving site conversion ratios. Future releases will also allow users if they so choose, release data about themselves with a single click.

Given the interest shown at the recent DIDW and Future of Web Apps conferences from Phil Windley, Rafe Needleman, and others in the community, we’ve made the Whobar technology available as open source. Whobar is written in PHP, but works like a proxy, so that the web application can be in any language. However, we’ve also been contacted by several developers interested in contributing a port to C#/.NET so stay tuned for additional modules. If you’re interested in getting involved, please check out our contributing page.

Congratulations to the SXIP team.  When I saw this at the DIDW conference I thought it was amazing.  I'll do a video capture over the next few days so those who haven't downloaded Cardspace or a Chuck Mortimer / Ian Brown identity selector can see what it's all about.

What a silo used to be…

Dave Winer at Scripting News brings us this.  The funny thing is, I actually had to cheat and read the HTML IMG tag to figure out that the tall cylinder in Dave's picture is a silo! 

I just saw it as a graphic of a barn, and wondered, “Why is Dave Winer putting a barn on his blog?  Has he run out of pictures?”

In my shrinking mind, the word “silo” had been totally disconnected from its original meaning, and usurped by the very notion of segregated technology realms that Dave is telling us about.  So the farm thing didn't register.

Doc talks about a Vendor Management Systems, to balance the other side’s Customer Management Systems. I, of course, like. A prototype for this is a movie review system where I own and control my data. Today, I rate movies on Netflix and Yahoo, but I can’t get them to share the data with each other, so they make recommendations without info the other one has. If I had a place where I kept my movie ratings and gave each of them a pointer to it, they could read it and I would control the data. It would be very easy to set up, the technology is no trick at all. The hard part is getting enough users to do it this way to gain critical mass. This is also the idea behind Edgeio and Marc Canter’s People Aggregator. Open systems, users own the data, silos smell of sulfur.

This is exciting stuff – I'm talking Identity Big Bang content.

The way I read Doc's ideas, he's talking about a real inversion of what advertising is and means.  Instead of suppliers advertising what they want us to buy (by spamming our attention), we'll advertise what WE want to buy, and suppliers will make us offers.  Sounds a lot more efficient to me.  What am I missing?  Why doesn't everyone want to do this?

Maybe because a lot of what advertising is about is getting us to want things we don't know we want.  But even that can be done in other better ways too.  Like by producing cool things and having them explode into discussion.  Doc said this too, didn't he:  Markets are conversations.

 

A blog on application-centric IdM

Nishant Kaushik is Architect For Identity Management Products at Oracle.  I meant to write about him when I read his interesting discussion of my piece on Enterprise and Individual Identity.  Somehow I got distracted, but recently he's been talking about Appication-Centric IdM, certainly an interesting way to frame the problems, particularly because he doesn't position this against user-centricity.

“One of the most common questions I encountered at the Catalyst conference this year was “what is application-centric IdM”. The second most common question (did not lose by a lot) was “how does this compete with user-centric identity”. It has taken a while, but I wanted to make an attempt at answering those questions in a broader forum. 

What is “application-centric identity management”?

“Application-Centric IdM is one of 3 pillars around which we are building our IdM offerings. It is an offshoot of the broader application-centric security concept being woven into everything coming out of our middleware group. The application-centric philosophy is about understanding the needs of applications and application developers. A lot of the problems we face today in identity management stem from the fact that when it comes to identity, each application is on its own. Every time an application is being developed or deployed, the ones responsible for it – the architects, the developers, the project managers and the administrators – are forced to tackle the same old issues over and over again. How do I deal with authentication? Where do I get the user's identity information from? What identity information do I need based on the problems I have to solve? How do I make sure it is correct? The answer to these questions is often so hard, that the development teams deal with it in the way they know best – they build their own identity infrastructure. They create user tables, login screens and processes, permission and authorization modules, account registration procedures, and profile management tools. And they do it again and again. The result is what we see today – multiple identity silos in the organization that require complex management software, tools and processes as add-on layers to try and give the enterprise some semblance (illusion maybe?) of control; poor application security with no real mechanism for consistent, centralized enforcement of enterprise-wide policies like SoD and RBAC; and users having to deal with multiple passwords, multiple authentication schemes, multiple profiles to manage…the list goes on and on. 

“Enterprise IdM solved this somewhat by adding an additional layer of abstraction on top that solves some of these issues. Centralized profile and password management, SSO tools and Audit & Compliance solutions took away some of these issues. But this added additional challenges into the mix in the form of complex integration problems, and the need for complex tooling and processes. 

“As long as IdM follows the bolt-on systems management approach, these challenges will only be mildly alleviated, and never truly cured. This is where application-centric IdM tries to provide a new way of solving this age-old problem. The idea is that instead of each application having to build these infrastructures as part of their functionality, they can just avail of them as ready made, standards-based services. Application-centric IdM moves away from the traditional system management style of IdM, focusing instead on the creation of an IdM infrastructure that customers deploy to expose these services for their applications to plug into their own business processes. It makes identity (and security) an integral, yet abstracted part of the development process. This separation is critical, because often the people defining the security policies are not the same as those defining application behavior – similar to how the role of deployers and developers is separated in J2EE. At the end of it all, users get a consistent experience, the enterprise gets better control of security, audit and policy enforcement, the IT department avoids massive data and process management problems, and developers can better focus on the business functionality of their applications.

“How does this compete with user-centric identity?

“The simple answer is that it doesn't! Application-centric IdM is completely compatible with user-centric identity. In fact, it can help with the introduction of user-centric identity into the IdM equation. As user-centric identity gets incorporated into the operational environment, applications that have plugged into an application-centric IdM framework will be able to immediately take advantage of it, because it will become available as an underlying service in the infrastructure. The same identity retrieval service that the application was using to retrieve identity data from the corporate directory can also retrieve identity data from the identity tokens that the user provided during their session initiation. Without having to change anything, the application can now consume user-centric identity tokens. The basic value proposition is that applications no longer worry about how they retrieve the identity data they need. They have a common service to get it from, which allows it to plug into the wider identity world underneath in a transparent manner.”

White papers and the like are available here.

Could the world be upside down?

In my last post I shared Jon Udell's conversation about “translucent databases” as a way to protect us from identity catastrophies.  He mentions a lender (e.g. Prosper) who needs information from a credit bureau (e.g. Equifax) about a borrower's reputation.

I'll start by saying that I see the credit bureau as an identity provider that issues claims about a subject's financial reputation.  The lender is a relying party that depends on these claims.

The paradigm currently used is one where the borrower reveals his SSN (and other identifying information) to the lender, who then sends it on to the credit bureau, where it is used as a key to obtain further reputation and personal information.  In other words, the subject deals with the lender, and the lender deals with the credit bureau, which returns information about the subject.

There are big potential problems with this approach.  The lender initially knows nothing about the subject, so it is quite possible for the borrower to pose as someone else.  Further, the borrower releases someone's SSN to the lender – as each of us has given ours away in thousands of similar contexts – so if the SSN might once have been considered secret, it becomes progressively better known with every passing day.

What's next?  The lender uses this non-secret to obtain further private information from the identity provider – and since the user is not involved, there is no way he or she can verify that the lender has any legitimate reason to ask for that information.  Thus a financial institution can ask for credit information prior to spamming me with a credit card I have not applied for and do not want.  Worse still, as happened in the case of Choicepoint, an important opportunity to determine that criminals are phishing for information is lost when the subject is not involved.

Jon proposed ways of changing the paradigm a bit.  He would obfuscate the SSN such that a service operated by the user could later fill it in on its way from the lender to the credit bureau.  But he actually ends up with a more complex message flow.  To me it looks like the proposal has a lot of moving parts, and makes us wonder how the service operating on behalf of the user would know which lenders were authorized.  Finally, it doesn't answer Prosper's claim that it needs the SSN anyway to submit tax information.

Another simpler paradigm

 I hate to be a single trick pony, but “click, clack, neigh, neigh”.  What if we tried a user-centrilc model?  Here's a starting point for discussion:

The borrower asks the lender for a loan, and the lender tells him which credit bureaus it will accept a reputation from. 

The borrower then authenitcates to one of those credit bureaus.  Since the bureaus know a lot more about him than the lender does, they do a much better job of identifying and authenticating him than the lender can.  In fact, this is one reason why the lender is interested in the credit bureau in the first place.

The credit bureau could even facilitate future interactions by giving the subject an InfoCard usable for subsequent credit checks and so on.  (Judging by the email I constantly get from Equifax, it looks like they really want to be in the business of having a relationship with me, so I don't think this is too far-fetched as a starting point).

After charging the borrower a fee, the credit bureau would give out a reputation coupon encrypted to the lender's key.

The coupon would include the borrower's SSN encrypted for the Tax Department (but not visible to the lender).  The coupon might or might not be accompanied by a token visible to the borrower;  the borrower could be charged extra to see this information (let's give the credit bureaus some incentive for changing their paradigm!)

When the lender gets the coupon, it decrypts it and gains access to the borrower's reputation.  It stores the encrypted version of the borrower's SSN in its database (thus Jon's goal of translucency is achieved).  At the end of the year it sends this encrypted SSN to the tax department, which decrypts it and uses it as before.  The lender never needs to see it.

All of this can be done very simply with Information Card technology.  The borrower's experience would be that Prosper's web site would ask for an Equifax infocard.  If he didn't have one, he could get one from Equifax or choose to use the oldworld, privacy-unfriendly mechanisms of today.

Once he had an InfoCard, he would use it to authenticate to Equifax and obtain the token encrypted for Prosper.  One of the claims generated when using the Equifax card would be the SSN encrypted for the Tax Department. 

When you use an Information Card, the identity selector contacts the identity provider to ask for the token.  This is how the credit brueau can return the up-to-date status of the borrower.  This is also how it knows how to charge the borrower, and possibly, the lender.

InfoCard protocol flow

In my view, the problem Jon has raised for discussion is one of a great many that have surfaced because institutions “elided” users from business interactions.  One of the main reasons for this is that institutions had computers long before it could be assumed that individuals did. 

It will take a while for our society to rebalance – and even invert some paradigms – given the fact that we as individuals are now computerized too.

Jon Udell and InfoCards…

Good news and a good question from Jon Udell.

Last night I logged into your identity blog using Chuck Mortimore's Firefox extension — very cool!

It's great to see Jon excited about Information Cards.

Now on to that really good question…

It reminded me to ask you something I've been wondering about. How might following scenario map onto this technology:

  1. I join a site (A) that wants to communicate a doc containing my SSN to another site (B)
  2. Instead of allowing A to hold my SSN, I require A to flow SSN-bearing documents through me enroute to B.
  3. When the doc arrives, I tack on the SSN. If A must see the doc again before handing off to B, I encrypt the SSN for B's eyes only.
  4. Along with the SSN I attach a use-once-only-and-then-discard request directed at B.

(In the example I've been exploring on my blog, and in a podcast with Phil Windley, A is Prosper.com and B is Experian or Equifax.)

It would be interesting to know whether (and if so, how) the Cardspace tech could apply here. Some questions I've thought of:

At step 2, do we construe me as the identity provider asserting the claim that is my SSN?

Since I am not always online — and assuming the protocol tolerates asynch delay — would we model this as my use of a self-asserted SSN-bearing InfoCard in a B context that was set up by A?

I was a bit confused without refering back to Jon's blog, so here's the piece with which he began the discussion:

Back in 2003 I was trying to drum up interest in Peter Wayner’s book, Translucent Databases, which shows how to build and operate databases whose contents are opaque to their operators. Three years later, there’s still no serious discussion of why translucency should be a key architectural principle, or how it might be applied.

A couple of recent examples show why it’s an issue that belongs on IT’s agenda. The first involves Prosper, a service whose tagline is “people-to-people lending.” Using a social network to broker connections between groups of borrowers and groups of lenders, Prosper aims to do for loans what eBay has done for auctionable goods. I wanted to invest a small amount as a lender in order to find out more about how the system works, so I began the sign-up process. To enable a credit check, Prosper asked for my Social Security number. That seems like an obvious requirement but, when you stop and think, why should it be? Prosper doesn’t actually need to receive and store that number. It only needs to relay it to Equifax, Experian, and TransUnion.

If Prosper ran its database translucently, I would be able to encrypt the number so that nobody inside Prosper, legitimate or otherwise, could read it. Equifax and others would ask me to unlock it. Ideally they’d promise to use it once and then discard it.

At this point, of course, it becomes clear that Prosper shouldn’t need to store my encrypted number in its database. It should only need to sign a request to the bureaus for a credit check. The request should then bounce to me, acquire my encrypted Social Security number along with permission for one-time use, and hop along to the bureaus. This protocol won’t work synchronously, but it doesn’t have to. If asynchronous message flow gives me the control I want, that’ll be just fine.

Translucency shouldn’t apply to only databases; it should govern service networks too. Unfortunately, with the lone exception of SSL, every effort to make cryptographic protocols useful to ordinary folks has gone down in flames. How will that ever change?

Quixotic jousts with the likes of Prosper over individual Social Security numbers won’t move the needle. But AOL’s recent data spill, or another such Exxon Valdez-like disaster, just might. “My goodness,” said Thelma Arnold, AOL’s user #4417749, when her search history was linked to her identity and revealed to her. “It’s my whole personal life.”

It’s time for a public conversation about the uses and limits of translucency. Is it really necessary to retain my Social Security number, or my search history, in order to provide a service? If not, what does it cost the provider of a service — and cost the user, for that matter — to achieve the benefit of translucency? Is this kind of opt-out a right that users of services should expect to enjoy for free, or is it a new kind of value-added service that provider can sell?

Realistically, given the very real technical challenges, I think it would have to be a service. Until recently, that hadn’t been a service that many folks would have considered paying for. But Thelma Arnold and 658,000 other AOL customers probably see things differently now. If you’d rather not be liable for storing more of your customers’ data than is strictly necessary, that’s a step in the right direction.

This is one of several related items, all of which are interesting.  I'll let you rest your eyes, and respond in my next post.

Identityblog effect

It seems like I ended up sending too many people to Chuck Mortimore's server at once. At 11:40 am he wrote:

Looks like Kim's two new posts have melted my server. He's the slashdot of the Identity world.

Sorry – the crack sys-admin team has been deployed. Hopefully we're back up soon!

By 1:00 pm he added:

Thanks to Ian, Ebe, and a new router, xmldap.org is back online.

Kim – you owe us $65.00 🙂

One of the mysterious things about RSS is the “publication effect”. 

Mortimore publishes code for managed information cards

Amazing news from Chuck Mortimore at xmldap.org – source for java-based managed cards:

I've just checked in code that can create Managed Cards that import into CardSpace RC1.

To allow people to play around, I've also added a quick little web app, which creates cards for you. You can try this out at:

https://xmldap.org/sts/cardmanager

If you'd like to try it out, you can download the source from http://xmldap.org

 

InfoCards for Firefox users

From Chuck Mortimore at xmldap.org: 

It sounds like Craig Burton has been having trouble with the demo Cardspace Selector I put together for Firefox. I'm not sure what trouble he's been having, but I thought I'd toss up some quick instructions, and a screen cast.

Step 1) Make sure you're on Firefox 1.5 or greater.

Step 2) Make sure you've got J2SE 1.4x installed on your machine. The xmldap selector doesn't use any .net or Microsoft code…its a cross platform implementation written from scratch in Java. You can hit http://java.sun.com if you need to download a JDK

Step 3) Go to http://xmldap.org and download the Firefox extension. You may need to allow the popup blocker to trust my site. Restart firefox.

Step 4) Go to a Cardspace enabled site like xmldap, identityblog, or ping

Step 5) Click to login, create a card, and submit.

Note that you'll still get a warning saying: “Additional plugins are required to display all the media on this page” Ignore it…I haven't figured out how to make it go away yet. Please email me or comment if you know!

Craig and others – email me at cmort at xmldap.org if you have questions or issues!

When I tried it I was using an earlier version of Firefox and had no luck – so make sure you get onto Firefox 1.5 or later.

By the way, this is a must-see demo not only for its general coolness, but for the special coolness of its sound track.  It's really a wonderful, no-nonsense piece of work.

Pretexting and Privacy

I've never seen Craig Burton write about privacy before.  Clearly he's had enough of the recent goings-on: 

  1. I was listening to Talk of the Nation on National Public Radio this afternoon. There was a good discussion going on sparked by the fiasco that happened at HP the last few weeks. Since I cover lexicon, identity, and security, I thought it would be a good idea to cover some of the conversation.
  2. What has emerged new to the general conversation is the term “pretexting”. This is the practice that investigators–both private and internal–use to pretend that they are someone else to obtain personal information from service companies. This includes, the phone company, cell phone companies, banks, utilities, county ownership records, and other private and public agencies.
  3. This is not a new term, but one that is getting public recognition as a result of the HP fiasco.
  4. According to the conversation that I heard, there is a synonymous term in the hacker community for pretexting called “social engineering.” There are some states that have made pretexting and social engineering illegal. California, Tennessee and Florida are exceptions maybe. This is a gray area and is only coming to light after these events.
  5. The previous hacker turned consultant in the conversation is the author of the book The Art of Deception.
  6. Here is my take on this. The government and agencies are not going to be able to cope with this problem. This means that it is your responsibility to protect yourself. There are a few major areas that you can focus on that will help you.
  7. Use InfoCards for login when you can. I admit this is new stuff, but it is fundamental in protecting your information from phishing and hijacking. InfoCard technology will change the future of hackers and thieves. You can support this by understanding it and using it.
  8. Stop using common methods of identification. Your social security number, you mother's maiden name and your birth place are redily accessible to social engineering agents.
  9. Use encryption for your data and emails. There are several technologies that will help you with this. You can do it at work and for your personal emails where needed. Without encryption, you have to assume that your emails are totally accessible to anyone who wants them. The current email technology is hackable and in clear text that is readable by anyone.
  10. You have to assume that at work, there are people keeping track of what you do with your computer. This is an issue, but you can also understand that your employer probably doesn't have the resources to look that closely at what you do.
  11. However, they also had a guy on the program that was being offered a job–a high profile and high paying job–that was revoked after the person had some email conversations about the terms of employment with his attorney. The company actually monitored his email conversations and gave him the choice of resigning or being fired as a result of the interchange. Scary.

Ms. Dunn at HP has struck a deal with the HP board to resign as a result of the press and fiasco. Did she know what the legal dept. was doing? Probably not. My opinion is that she should have found out on an issue of this importance at that she should probably step down now and not later.

I appreciate his comment about the role of Cardspace. 

And while we're talking about Craig, Has everyone seen his recent Poser sculpture entitled, “If I just give this Web 2.0 bubble a flick, nobody will get hurt, right?“: