Recap of European Identity & Cloud Conference 2013

The 2013 edition of the European Identity & Cloud Conference just finished. As always KuppingerCole Analysts has created a great industry conference and I am glad I was part of it this year. To relive the conference you can search for the tag #EIC13 on Twitter.

KuppingerCole manages each time to get all the Identity thought leaders together which makes the conference so valuable. You know you’ll be participating in some of the best conversations on Identity and Cloud related topics when people like Dave Kearns, Doc Searls, Paul Madsen, Kim Cameron, Craig Burton … are present. It’s a clear sign that KuppingerCole has grown into the international source for Identity related topics if you know that some of these thought leaders are employed by KuppingerCole themselves.

Throughout the conference a few topics kept popping up making them the ‘hot topics’ of 2013. These topics represent what you should keep in mind when dealing with Identity in the coming years:

XACML and SAML are ‘too complicated’

It seems that after the announced death of XACML everyone felt liberated and dared to talk. Many people find XAMCL too complicated. Soon SAML joined the club of ‘too complicated’. The source of the complexity was identified as XML, SOAP and satellite standards like WS-Security.

There is a reason protocols like OAuth, which stays far away from XML and family, have so rapidly gained so much followers. REST and JSON have become ‘sine qua none’ for Internet standards.

There is an ongoing effort for a REST/JSON profile for XACML. It’s not finished, let alone adopted, so we will have to wait and see what it gives.

That reminds me of a quote from Craig Burton during the conference:

Once a developer is bitten by the bug of simplicity, it’s hard to stop him.

It sheds some light on the (huge) success of OAuth and other Web 2.0 API’s. It also looks like a developer cannot be easily bitten by the bug of complexity. Developers must see serious rewards before they are willing to jump into complexity.

OAuth 2.0 has become the de-facto standard

Everyone declared OAuth 2.0, and it’s cousin OpenID Connect, to be the de facto Internet standard for federated authentication.

Why? Because it’s simple, even a mediocre developer who hasn’t seen anything but bad PHP is capable of using it. Try to achieve that with SAML. Of course, that doesn’t mean it’s not without problems. OAuth uses Bearer tokens that are not well understood by everyone which leads to some often seen security issues in the use of OAuth. On the other hand, given the complexity of SAML, do we really think everyone would use it as it should be used, avoiding security issues? Yes, indeed …

API Economy

A lot of talk about the ‘API Economy’. There are literally thousands and thousands of publicly available APIs (named “Open APIs”) and magnitudes more of hidden APIs (named “Dark APIs”) on the web. It has become so big and pervasive that it has become an ecosystem of its own.

New products and cloud services are being created around this phenomena. It’s not just about exposing a REST/JSON interface to your date. You need a whole infrastructure: throttling services, authentication, authorization, perhaps even an app store.

It’s also clear that developers once more become an important group. There is nu use to an Open API if nobody can or is willing to use it. Companies that depend on the use of their Open API suddenly see a whole new type of customer: developers. Having a good Developer API Portal is a key success factor.

Context for AuthN and AuthZ

Manye keynote and presentations referred to the need for authn and authz to become ‘contextual’. It was not entirely sure what was meant with that, nobody could give a clear picture. No idea what kind of technology or new standards it will require. But it was all agreed this was what we should be going to 😉

Obviously, the more information we can take into account when performing authn or authz, the better the result will be. Authz decisions that take present and past into account and not just whatever is directly related to the request, can produce a much more precise answer. In theory that is …

The problem with this is that computers are notoriously bad at anything that is not rule based. Once you move up the chain and starting including the context, next the past (heuristics) and ending at principles, computers are giving up pretty fast.

Of course, nothing keeps you from defining more rules that take contextual factors into account. But I would hardly call that ‘contextual’ authz. That’s just plain RuBAC with more PIPs available. It only becomes interesting if the authz engine is smart in itself and can decide, without hard wiring the logic in rules, which elements of the context are relevant and which aren’t. But as I said, computers are absolutely not good at that. They’ll look at us in despair and beg for rules, rules they can easily execute, millions at a time if needed.

The last day there was a presentation on RiskBAC or Risk Based Access Control. This is situated in the same domain of contextual authz. It’s something that would solve a lot but I would be surprised to see it anytime soon.

Don’t forget, the first thing computers do with anything we throw at them, is turning it into numbers. Numbers they can add and compare. So risks will be turned into numbers using rules we gave to computers and we all know what happens if we, humans, forgot to include a rule.

Graph Stores for identities

People got all excited by Graph Stores for identity management. Spurred by the interest in NoSQL and Windows Azure Active Directory Graph, people saw it as a much better way to store identities.

I can only applaud the refocus on relations when dealing with identity. It’s what I have been saying for almost 10 years now: Identities are the manifestations of relationship between two parties. I had some interesting conversations with people at the conference about this and it gave me some new ideas. I plan to pour some of those into a couple of blog articles. Keep on eye on this site.

The graph stores themselves are a rather new topic for me so I can’t give more details or opinions. I suggest you hop over to that Windows Azure URL and give it a read. Don’t forget that ForgeRock  already had a REST/JSON API on top of their directory and IDM components.

Life Management Platforms

Finally there was an entire separate track on Life Management Platforms. It took me a while to understanding what it was all about. Once I found out it was related to the VRM project of Doc Searls, it became more clear.

Since this recap is almost getting longer than the actual conference, I’ll hand the stage to Martin Kuppinger and let him explain Life Management Platforms.

That was the 2013 edition of the European Identity & Cloud Conference for me. It was a great time and even though I haven’t even gotten home yet, I already intend to be there as well next year.

Share

Found: Identity Provider Business Case, or not?

I had the pleasure to have been part of the Identity community in the “early days”. Right before OpenID came into existence and most people thought of Microsoft Passport as innovative. One very hot topic was the idea of an “Identity Provider”. An Identity Provider is a party on the Internet who would be happy to serve any claims about me to a any relying party, obviously with the user’s consent and control. Anyone remember the expression “user centric identity”?

There were some unsolved issues:

  • How would an Identity Provider make money to pay for the operational costs?
  • How would relying parties know which Identity Provider to trust?

Especially the second issue was hard. Some relying parties just want to be able to recognize recurring visitors and are happy with a couple of standard attributes. For them, identity has low value. Well known examples are the myriad of forum sites.

Other relying parties however want more, they want identities with verified attributes, an identity they can trust. For them, identities have value and untrusted identities come with a business risk. An extreme example would be a financial institution who would, for these reasons, typically never outsources the Identity Provider role.

A couple of days I came across an interesting article about Facebook offering their commenting system to other sites, including authentication through Facebook. What caught my eye was an argument showing that Facebook serves as an almost perfect Identity Provider in some sense:

This offers publishers a number of benefits. They get more links to their site from inside the net’s most popular website. A lot of people are “registered” to comment on their sites. And, they have a system designed to discourage vitriol because it’s easy for the site owner to ban a user and tough for a user to create a new identity.

Especially that last part is interesting: relying parties can put some trust in the provided identities simply because … people invest time and effort in their Facebook identity and generally would not throw this away just to post rubbish on some forum. In other words, relying parties will like Facebook identities. They trust one Identity Provider, Facebook, and they get hundreds of millions of fairly trustful Identities.

But what is in it for Facebook? A lot!

For Facebook, the benefit is also clear. Users now have even more incentive to be constantly logged into Facebook (those who are already logged into Facebook don’t have to do anything to comment on a website using its system). Additionally, even more of Facebook’s users’ net activities flow through its site, since by default comments — and replies to them — post to a Facebook user’s wall. That deepens users’ ties to Facebook, adds more content to Facebook, and gives people more reason to check their Facebook newsfeed for the increased information flow.

By allowing relying parties to use Facebook identities to realize a comment system on their site, Facebook actually generates value for themselves. A win-win it seems.

Facebook, with their Facebook Connect, wants to be the primary Identity Provider on the Internet:

It also builds on what’s becoming Facebook’s most important function: being the identity provider and validator for the wider net. The system opens the door for what’s likely inevitable: having news sites rely on Facebook to identify its users and eventually to serve ads to its readers based on their individual Facebook pages.

Both issues are gone: the Identity Provider (Facebook in this case) can have a very viable business model and the relying party has an Identity Provider they can trust, one that brings hundreds of millions of identities.

So, all well now in the world of Identity? I don’t think so. The relationship between Facebook and relying parties is not a balanced one. Relying parties are clearly at the mercy of Facebook:

… just as Facebook jealously holds onto the e-mail addresses of the people you are connected to on Facebook so you can’t re-establish your network on some other site.

Promising as it may seem, this type of unbalanced relationship should not satisfy us. So, for those still active in the field of Internet Identity, what do you think about this?

Share

Embarassing Facebook Moments

Paul Madsen confesses he was able to, just in time, avert an embarassing Facebook moment:

On what started as an innocuous thread on the relative merits of curling and football, comments were made by a non-work friend that, while completely appropriate to the relationship between myself and the commenter (we having a long history of questioning each other’s masculinity and mental health), were not appropriate for a work context (or 98% of any other contexts it must be said).

Paul also points to what he thinks is the root cause:

The fact that my Facebook friends list is an aggregation of both work and non-work hit home yesterday.

Facebook allows me to create lists but not, AFAICT, use those lists to compartmentalize through differentiated permissions, e.g. allow members of one list to participate in a thread and not another.

Since the first day I have been using Facebook I felt very uncomfortable with the way various friends list are managed. On Facebook, you always risk having embarassing “red face” moments when you have different types of friends list (work and friends for instance).

Facebook does have various settings related to privacy, who is allowed to see what, etcetera. But honestly, even I sometimes have it difficult to configure those in a way that I am confident no information is spilled from one group to another. Currently I even practically closed down my Facebook profile for everyone who is not a close friend. If you are not a close friend, you will only see some very basic information about me and that’s it (if you do see more and don’t consider yourself a closefriend, drop me line ;). But even with all careful configuration work, I know I will one day face a “Paul Madsen Moment” on Facebook.

Clearly, offering a bunch of configuration settings like Facebook does not solve the issue. First, it becomes (too) complicated very fast and second, even when configured properly, it still has open holes. Who has a good solution that works in complex environments like Facebook?

Share

Disturbances in the cloud

Cloud computing is cool, no doubt about that. There have never been more good looking and futuristic looking schematics been made in Visio. Thousands of presentations, workshops and even conferences have been held on the subject.

One question however has not be clearly answered yet … what about data ownership? What about privacy of that data? When your applications are running in the cloud you are also handing over your data to whoever is running the data center. How sure are you that they protect this data as they should do? What about these situations:

  1. Your cloud partner goes out of business and your data becomes a valuable asset that can be sold to pay of debt. How well are you protected from this scenario? Or … what are the guarantees about confidentiality? Think SalesForce …
  2. Your cloud partner goes out of business without any warnings, your applications are offline, your data is not accessible. Worst case you got a couple of days notice, best case a couple of weeks. Does your disaster recovery plan takes this into account? How fast can you move to a new cloud partner or your own data center? How much data will you loose? How recent is the data you go online with after recovery?
  3. Your cloud partner decides to disable a feature in their application, a feature you depend on. Does your disaster recovery plan takes this into account? This is not far fetched, in a small way this is what happened when Microsoft decided to disable anonymous comments on their Live Blog. They even did this retroactively and so revealed identity information of authors who previously had been anonymous.

None of these scenarios is purely technical in nature and none of these scenarios are far fetched. You can probably think of many more realistic and sure to happen situations.

In relation to the 3th scenario … how many companies have application versions that are far behind the lastest public version purely because of functionality or compatibility they depend on? At least all of the companies I have came into contact with are in this situation. If you run everything on your own servers you have a greater deal of control then you can imagine at first. Companies should do their homework when moving some of this into the cloud, they are often giving up far more control then they think they do and want to do. Contracts alone won’t solve it either.

Share

YouTube vs. Viacom … what about privacy?

Most of you have probably heard about the case where a judge ordered Google to turn over every record of every video watched by YouTube user. That includes the user’s name and IP addresses. This in response to complaint filed by Viacom against Google for allowing clips of its copyright videos to appear on YouTube. Read about it here. This is the actual ruling from the judge.

I am not going to comment on the copyright issues or the actual complaint filed. I am however worried about the consequences for online privacy. A lot of users will see their personal information being handed over to Viacom even though they probably never watched a single copyrighted clip or at least were not aware of infringing anyone’s copyright. Somehow this reminds me of the toystar.com case. A company selling toys, files for bankrupcy and tries to sell their customer database to the highest bidder. It was eventually stopped by the FTC.

People can hand out personal information to sites and even carefully review the privacy terms before doing so. It means nothing if this kind of rulings can mean your information is handed over to a third party. It would be a different case if that information helps law enforcement agencies to detect crimes and prosecute criminals. I trust law enforcement agencies more then Viacom to properly process that data. Does Viacom give any guarantees on safeguarding this data? Will the processing be transparant and with full disclosure to the users involved?

Share

Not being you

Lately there has been a lot of talk about anonymity and pseudonimity. Just read around on the blog agregation Planet Identity.

There is a strong interest in walking around on the Internet, participating in transactions and doing whatever without people knowing who you are. Most federation and user centric protocols have some sort of support for this. Most of it driven by Kim Kameron’s identity law on minimal disclosure: only disclose that part of your identity that is absolutely necessary.

I happen to be a fervent player of World of Warcraft. For those of you who don’t know, that is an MORPG (massive online role playing game). Divided across hundreds of servers, players can create avatars, give them names and create an entire new personality in the virtual world. That sounds like pseudonimity heaven to me. You can literally recreate an entire new identity, new in every aspect. You can choose a different avatar from eight races. A human character versus an orc based, how different can it get?

Using that avatar you can play whatever you like. A female, suspicious priest or a strong and eager hunter. You can even start multiple characters, all completely different. This is in fact what most players do. Sounds easy to create different identities right?

Surprise … no it isn’t. Even seasoned players have complained about how difficult it is to create two different identities. Even when you have all the tools at your disposal: new avatars, new names, different clothing, different professions, different cities … It still isn’t easy to change identity. After a few weeks of playing their new character, most of them eventually are discovered: “Hey, aren’t you also playing this other character?”

You might think “Why?” Well, it seems there is one thing you cannot change, one thing none of the MORPG, games nor federation or user centric can change: YOU.

No matter who hard you pretend, no matter what tools you have at your disposal for creating a new identity, it is still you. You might be different in the way you look, in your name but you are still you. You betray yourself by talking, walking and liking the same things. Even if you try hard and pretend to like other things or walk differently, there are so many details of you, that are you, that people recognize and will blow your cover after a while.

Even if Cardspace of OpenID gives me anonymity or pseudonimity, I will probably betray myself the moment I start posting on the forum or buy my favorite music.

The hard part of anonymity or pseudonimity is not in the identification or authorization process, it is afterwards, when you start posting in forums or do stuff on the Internet. Thereby exposing the real you. Remember how search queries on AOL (or Google, Live …) could identify you?

Share

Driver’s License to be the Next Debit Card

I just came across this article on Business Week “Use Your Driver’s License as a Debit Card“.

The intent is to use your drivers license for payment transactions. By coupling your license number to your bank account, they make your drivers license suitable for payments. Just swipe it, enter your personal code and the money is transfered. This way the shop owner doesn’t have to pay credit card companies those exorbitant fees and can carry less plastic around in your wallet.

Sounds like a good idea? Yes and no. Yes, since you don’t have to carry yet another card for doing payments. No, because they are overloading the drivers license to do stuff that it wasn’t made for.

We all know the the verification process for the US drivers license is shaky yo say the least on most states. The REAL ID act tries to improve this situation by introducing extra measures. But in the end, the verification process remains faulty. It is just less faulty but still faulty enough. Piggy backing a payment authorization is not such a good idea. You could couple the bank account of John to the drivers license of Jeff. And what happens if your drivers license is revoked? No payments anymore?

Their aim, reducing the number of plastic in your wallet, is worthy. Their modus operandi isn’t. Piggy backing one type of identification and authorization on to another type is often dangerous. Not always bad, but often questionable.

Why not introduce a blank card that can store multiple virtual ID cards like your credit card, drivers license … You just pick and unlock the one you would like to use. That reduces the plastic weight while still separating identities and authorization when needed and when you wish. Sounds like user centric identity in your wallet.

Share

Identity Ownership

During lunch on the first day of the Identity Open Space in Brussels one of the attendants mentioned that he wanted more power over his identity since he owns his own identity.

He used the following example: when he send his resume to a potential employer, he wanted to be informed about what happened to that resume. That sounds fair to me, it contains private and potential sensitive information. However, he went even further and said that when the recruiter ranked the resume, he wanted to be informed of that rank and why it was ranked like this. His reasoning was: that resume is part of my identity, an identity I own, so I am entitled to that information.

Immediately I was thinking about this article. The article explains in great detail the difficulties you have with “user consent” and “owning your identity”.

If I meet a person, I build up an identity of that person. Part of that identity is based on my perception: the way he walks, talks and behaves. Other parts of that identity are based on what that person told me: his name, phone number, telephone number … Reasoning that the other party also owns the identity I created based on my perception is a bridge to far for me. I should not be forced to disclose my perception about a person because it is somehow connected to him.

You don’t own your identity, in fact, without other people around you, you don’t even have an identity. For me, identity only exists in a relationship with some other party. That identity is the perception that other party has about you. That perception might be based on information it got through several channels. In all cases, you only own a small part of that identity if you own a part at all.

The only identity you really completely own is the identity you have built about yourself in the relationship you have with yourself.

I would like to blog more about this idea of identity only existing within the context of a relationship. Feedback is more then welcome.

Share

Two Must-Reads

It has been a while since I have blogged about identity. That does not mean I haven’t been actively thinking, reading or discussing the subject. Recently I came across one recent and one older article on identity, I consider both articles a must-read.

The first one, the oldest, was written by Bob Blakley and discusses the feasiblity of the first law of identity “User control and consent”. A very good read. It touches on most of the difficulties with “user-centric” identity systems. In the Identity Gang discussion group I have touched on the feasability of identity meta-systems and the forces that could make or break it. This article however does a much better job at this. No matter how interesting identity meta-systems are, I yet have to see some good arguments that proof that current silos (Google, Yahoo!, MSN …) would want to give up the control they have over your personal (identity) information. Or will we end up with a Hobson’s Choice. They support the identity meta-system and will play along with specifications like OpenID or Infocards … as long as they are the identity provider issuing the assertions.

The second one, titled “Law of Relational Symmetry” was posted only a few days ago on the Identity Blog of the Burton Group. It builds upon the reservations made in the first article and gives a, well thought out, try in explaining why user-centry identity systems are very hard to accomplish and where potential solutions may be found.

So, grab some quality identity time and go read these articles!

Share

Craig, don’t help spammers!

Craig Burton’s blog is on my blogroll. Yesterday I wanted to comment on a recent post of him about Onfolio and Firefox. The form asked me to insert my email address. Thanks to the amount of spam I receive I have become very reluctant to enter my address. Sites just have no clue about how to deal with them. There are numerous sites posting entire mail archives with no obfuscation whatsoever to protect email addresses. On Craig’s site, I pasted my XRI contact service url (http://xri.net/=bavo.de.ridder) which would allow both Craig and his readers to contact me.

Sadly enough, the form came back to me, telling me that I should enter a real address. Hmmm, so I had to give my address. Knowing Craig’s reputation I assumed to following:

  1. Craig uses the email address to confirm a real person was posting and I would probably get a confirmation mail I had to respond to before my comment would be published.
  2. Craig would then be smart enough not to publish my email address or at least obfuscate it enough to keep it safe from spammers.

Feeling slightly more comfortable, I entered my real address and hit submit. A few seconds later (actually a lot of seconds later, his site must be on a 32kbps line), the post was submitted. I went to my mail reader to hit “get mail” but nothing had arrived yet. Going back to Craig’s site I discovered that:

  1. The comment was submitted and showed my email address in both the source and the rendered version (so not even basic javascript hiding).
  2. I did not receive a confirmation mail.

I mailed Craig to ask him to remove my address from the site. His mail address is available on his site, obfuscated as “gcraigburton [at] Yahoo [dot] com”. Nice. Obfuscation for his address but al his commenters are exposed.

I am very tempted to include Craig’s mail address, not obfuscated, but I will refrain. Craig’s obfuscation of his own address is weak enough, spammers probably already got it.

Share