Lost in translation

It was pretty exciting to start posting again and once more feel like part of the twitoblogosphere, or digital reality, or whatever we’re calling it.  I have to admit to not a small amount of regret for having neglected my blog for so long – in spite of my long list of “excellent reasons” for having done so. I was therefore prepared for a nudge or two from my friends, like Mary Branscombe’s:

Yet it was wonderful to see the interest from the people I don’t know yet, like Naohiro Fujie from Japan…

… until I actually went to see what he had said, and, since it was in Japanese, pressed Facebook’s “Translation” button:

Whew!  That’s a real punishment for neglecting a blog!  Or, perhaps worse, a bit extreme as a reaction to seeing me pick up the pen again.

But given Naohiro was just a click away I thought I really had to check in and see what was up:

Boy!  It sure shows it’s better to check your understanding of what people are saying before drawing any conclusions!

Meanwhile, I give Facebook’s Japanese translation engine a double *fail*.  Please, Facebook!  Take off that Translate button!  And nice to meet you Naohiro.

A look inside AzureAD B2C

Alex Simons asked me to write a piece for his Azure Active Directory Team Blog on our policy-based architecture and the “Identity Experience Engine” we developed to handle AzureAD’s B2C scenarios.  You can read what amounts to my first public description of our new technology at “A look inside AzureAD B2C with Kim Cameron” – reprinted here for convenience:

Last month Stuart Kwan wrote a great intro to our new Azure Active Directory B2C service and showed people how to start using it. As he explained, “Once you have a B2C tenant, you register applications and configure policies which drive the behavior of sign in, sign up, and other user experiences. Policies are the secret sauce of Azure AD B2C.” He gave step-by-step instructions and showed examples like this one of using the B2C Admin Portal to configure a policy based on social network providers: Today I’d like to build on Stuart’s introduction by explaining why we saw a customizable, policy-based approach to B2C as being essential – and what it means for the rest of our identity architecture. This will help you understand how our B2C Basic offering, now in public preview, actually works. It will also provide insight into the capabilities of our upcoming B2C Premium offering, currently in private preview with Marquee customers. I think it will become evident that the combination of our Basic and Premium products will represent a substantial step forward for the industry. It means organizations of any size can handle all their different customer relationships, grow without limitation, gain exceptional control of user experience and still dramatically reduce risk, cost, and complexity.

The Why

Readers of this blog probably already know quite a bit about enterprise identity management. So let me begin with what I think is the most important piece of information I can convey to people who are already expert: B2C does not just involve a couple of tweaks on the identity management we have learned to do for employees and devices. The underlying technical infrastructure, the developer model, the protocols and information storage concepts, continue to apply. But whole new technical capabilities are also required that make B2C, well… different.

To fully understand what’s at play we need to ask, “What are the differences between the way businesses interact digitally with their customers and the way they interact with their employees?” This isn’t the place to explore this – I’ll do so on identityblog. For now I’ll sketch the big picture as I see it.

Organizations and their employees typically have a close and ongoing relationship. Employers “know” their employees, having verified their qualifications and made them part of an enterprise team. They assign them a “corporate identity” – an account and password (and potentially a smartcard or OTP device) through which they identify themselves to corporate systems. To maximize productivity, employees typically log in once and work using their corporate identity for long periods of time. Internal identity systems have not generally been context-aware: the context has simply been that the employee is at work, doing his or her job.

Meanwhile organizations have had a completely different approach towards their customers. Relationships with customers have been driven by sales and marketing departments, not by traditional IT departments. The goal has been to eliminate friction (and clicks!) so new customers come on board – even before the enterprise knows the slightest thing about them – and then deepen the relationship and get to know the customer based on his or her specific needs and behaviors. Succeeding at this results in retention of the customer over time. Marketers in a number of industries actually see the ultimate role of customer identity being to learn how to delight their customer.

Clearly there are also cases where customers need access to their own valuable possessions and information, for example, in financial, health, insurance and government scenarios. Here customers will be willing to jump through various hoops to prove their entitlement and protect what is theirs. But far from being an exception, such high value scenarios drive home the fact that interacting with customers is all about being able to match the customer experience and related identity interaction to the specific activity a customer is engaged in rather than imposing some inflexible one-size-fits-all approach on everything.

The essential is that B2C scenarios demand, above all else, the ability to customize the customer’s identity experience to what is right for whatever they are doing.

The what

The requirement for continuous customization led us to create a technology enabling organizations to create “policies” that allow complete control over identity behaviors and experiences, and use these to drive the behavior of a flexible “identity experience engine” that handles all the issues around security, information protection, protocols, support for mobile and web devices and applications, and scalability.

Any application developer, department, enterprise, or group of enterprises can create policies. Then applications and portals can, depending on their context, invoke the identity experience engine passing the name of a policy and get precisely the behavior and information exchange they want without any muss, fuss or risk. These policies are what Stuart Kwan called “the secret sauce of Azure AD B2C”.

What behaviors of the identity experience engine do the policies control?

  • The set of html and css pages that are scrubbed for security compliance (e.g. cross-site scripting vulnerability) and then presented to users
  • User journeys – the visual experiences through which the customer progresses in a given policy
  • Identity providers (for example the social networks, ISVs, and enterprise or national IdPs that can be used to establish identity)
  • Relying parties who can use the policy
  • Authentication requirements, including multifactor orchestration
  • Integration with claims verifiers (hosted within an enterprise or provided by external partners)
  • Shared schema and mappings to participants (different systems name things differently)
  • Claims transformations and data minimization (hashing and/or transformation of attributes revealing PII into non-identifying demographic attributes)
  • Blinding and encryption
  • Claims storage
  • Web Service calls and workflow initiation
  • Protocol Conversion (SAML, OAuth2, and OpenIdConnect)

The idea of user journeys is key to the customization of customer experience and sheds light on how the system works at the protocol level. The identity experience engine operates as a pipeline and uses request/response claims exchanges to communicate with its internal components as well as with external entities.

The diagram below shows the example of a browser application or mobile application redirecting to the identity experience engine while specifying a policy that invokes a user journey. This particular journey begins with an identity selection experience – completely customized by the policy to blend into the rest of the application or portal. The customer then chooses whether to log in with an email-based “application-specific account” or with a social network. Because the journey is intended to control access to a high value resource, the customer’s phone numbers are retrieved from the customer directory and she is asked to up-level her authentication using an SMS or phone call. Then a token is issued for the application providing a number of claims retrieved from the store. Of course the policy author could have created any other journey appropriate for a given use case. There is no requirement to use MFA, consult a store, use social providers or anything else: all is flexible and extensible.

The How

It is important to understand that the identity experience engine used in B2C is an intrinsic part of Azure Active Directory, not some new service. The policy-based approach applies to many AAD scenarios besides B2C. All enterprise computing can benefit from policy-based identity and you likely already recognize that AAD Premium’s Conditional Access introduces these capabilities into B2E scenarios.

It is our goal to make AAD B2C identity management available to every organization regardless of size or complexity. We’ve been working with a host of companies in preview to make sure our B2C Basic offering solves the customer identity challenges of a wide cross section of companies solving straightforward issues.

B2C Basic uses all the same technology as will B2C Premium. The difference is that the Basic policies are 100% written by our B2C Basic Admin Portal. As Stuart explained, to author policy, you pick all the options you need to integrate a growing number of social providers and/or a customizable identity provider uniquely for your tenant. You can extend schema and select multi-factor authentication, do email verification and much more. You choose what information is released to which application. As you maneuver through the portal it writes your policy.

B2C Premium will be a superset of B2C Basic in which you will be able to take advantage of all the other capabilities of the system that are not present in the Basic portal. Premium is not yet in public preview. But I invite you to follow a set of posts I will be beginning soon on identityblog to tell you all about it and show examples of how it works.

I hope to hear from you there. Meanwhile, please take a good look at B2C Basic in light of the whole world of capabilities AAD B2C Premium is opening up.

Azure Active Directory B2C is now in public preview

For the last several years I’ve been working on a new technology and capability that we are calling “Azure Active Directory B2C.”   I’m delighted that I’m finally able to tell you about it, and share the ideas behind it.

For me it is the next step in the journey to give individual consumers, enterprises and governments the identity systems they need in this period of continuously more digital interaction and increasing threats to our security and privacy.

I don’t normally put official Microsoft content on these pages, but given how important the B2C initiative is, how closely I’ve been involved, and how well it has been received, I think it makes sense to show you Microsoft’s announcement about “B2C Basic”.  It appeared on the Azure Active Directory Blog.  Stuart Kwan does a great job of introducing you to the product.

I hope you’ll take a look at his introduction.  I’ll be posting a number of pieces which expand on it – exploring issues we faced, giving you the background on the thinking behind the architecture and implementation, and telling you about the “B2C Premium” offering that is coming soon. I think the combination of Basic’s accessibility and Premium’s feature completeness really offers a new paradigm and amazing opportunities for everyone.

Introducing Microsoft Azure Active Directory B2C

By Stuart Kwan

With Azure Active Directory B2C we’re extending Azure AD to address consumer identity management for YOUR applications:

  • Essential identity management for web, PC, and mobile apps: Support sign in to your application using popular social networks like Facebook or Google, or create accounts with usernames and passwords specifically for your application. Self-service password management and profile management are provided out of the box. Phone-based multi-factor authentication enables an extra measure of protection.
  • Highly customizable and under your control: Sign up and sign in experiences are in the critical path of the most important activities in your applications. B2C gives you a high degree of control over the look and feel of these experiences, while at the same time reducing the attack surface area of your application – you never have to handle a user’s password. Microsoft is completely under the covers and not visible to your end users. Your user data belongs to you, not Microsoft, and is under your control.
  • Proven scalability and availability: Whether you have hundreds of users or hundreds of millions of users, B2C is designed to handle your load, anywhere in the world. Azure AD is deployed in more than two dozen datacenters, and services hundreds of millions of users with billions of authentications per day. Our engineers monitor the service 24/7.
  • Unique user protection features: Microsoft invests deeply in protection technology for our users. We have teams of domain experts that track the threat landscape. We’re constantly monitoring sign up and sign in activity to identify attacks and adapt our protection mechanisms. With B2C we’ll apply these anomaly, anti-fraud, and account compromise detection systems to your users.
  • Pay as you go: Azure Active Directory is a global service benefiting from tremendous economies of scale, allowing us to pass these savings along to you. We offer the B2C service on a consumption basis – you only pay for the resources that you use. Developers can take advantage of the free tier of the service when building their application.

B2C uses the same familiar programming model of Azure Active Directory. You can quickly and easily connect your application to B2C using industry standards OAuth 2.0 and OpenID Connect for authentication, and OData v3 for user management via our Graph API. Web app, web API, mobile and PC app scenarios are fully supported. The same open source libraries that are used with Azure Active Directory can be used with B2C to accelerate development.

If you want, you can get started right now! The rest of this post takes a look at how B2C works in detail.

How it works

The best way to describe B2C is to see it in action. Let’s look at an example. Our heroes, Proseware, have a consumer-facing web site. The site uses B2C for identity management. In this case that means sign in, and user self-service sign up, profile management, and password reset. Here’s the Proseware homepage:

A new user would click sign up to create a new account. They have the choice of creating an account using Google, Facebook, or by creating a Proseware account:

One quick note. The Microsoft button doesn’t work yet, but it will soon. It isn’t available at the start of the preview as we have more work to do in our converged programming model before we enable this.

What’s a Proseware account? As it turns out, there are many people out there who don’t always want to use a social account to sign in. You probably have your own personal decision tree for when you use your Facebook, Google, Microsoft or other social account to sign in, or when you create an account specifically for a site or app. In B2C a Proseware account is what we call a local account. It’s an account that gets created in the B2C tenant using an email address or a flat string as a username, and a password that is stored in the tenant. It’s local because it only works with apps registered in your B2C tenant. It can’t be used to sign in to Office 365, for example.

If a person decides to sign up with a social account, B2C uses information from the social account to pre-fill the user object that will be created in the B2C tenant, and asks the user for any other attributes configured by the developer:

Here we can see the user is also asked to enter a Membership Number and Offering Type. These are custom attributes the Proseware developer has added to the schema of the B2C tenant.

If a person decides to sign up with a Proseware account, B2C gathers the attributes configured by the developer plus information needed to create a local account. In this case the developer has configured local accounts using email as username, so the person signing up is also asked to verify their email address:

B2C takes care of verifying the person signing up has control of that email address before allowing them to proceed. Voila, the user is signed up and signed in to Proseware!

You might ask yourself, how much code did I need to write to make this elaborate sign up screen? Actually, almost none. The sign up page is being rendered by Azure AD B2C, not by the Proseware application. I didn’t have to write any code at all for the logic on that page. I only had to write the HTML and CSS so the page rendered with a Proseware look and feel. The logic for verifying the user’s email address and everything else on the page is B2C code. All I had to do was send an OpenID Connect request to B2C requesting the user sign up flow. I’ll go into more detail on this later when I talk about how I wrote the app and configured the B2C tenant.

Let’s look at a return visit. The user returns and clicks sign-in:

If the user clicks one of the social network providers, B2C will direct the person to the provider to sign in. Upon their return B2C also picks up attributes stored in the directory and returns them to the app, signing the user in.

If the user clicks the Proseware account button, they’ll see the local account sign in page, enter their name and password, and sign in:

That’s it! Now I’ll show you how I built this example.

Configuring Azure AD B2C

Step one was to get an Azure AD B2C tenant. You can do this by going to the Azure AD section of the Azure management portal and creating a B2C tenant (for a shortcut, see the B2C getting started page). B2C tenants are a little different from regular Azure AD tenants. For example, in a regular tenant, by default users can see each other in the address book. That’s what you’d expect in a company or school – people can look each other up. In a B2C tenant, by default users cannot see each other in the address book. That’s what you’d expect – your consumer users shouldn’t be able to browse each other!

Once you have a B2C tenant, you register applications in the tenant and configure policies which drive the behavior of sign in, sign up, and other user experiences. Policies are the secret sauce of Azure AD B2C. To configure these policies, you jump through a link to the new Azure management portal:

This is also the place where you find controls for setting up applications, social network providers, and custom attributes. I’m going to focus on sign up policy for this example. Here’s the list of sign up policies in the tenant. You can create more than one, each driving different behavior:

For the Proseware example I created the B2C_1_StandardSignUp policy. This policy allows a user to sign up using Facebook, Google, or email-named local accounts:

In sign up attributes I indicated what attributes should be gathered from the user during sign up. The list includes custom attributes I created earlier, Membership Number and Offering Type:

When a user completes sign up they are automatically signed in to the application. Using Application Claims I select what attributes I want to send to the application from the directory at that moment:

I’m not using multifactor authentication in this example, but if I did it’s just a simple on/off switch. During sign up the user would be prompted to enter their phone number and we would verify it in that moment.

Finally, I configured user experience customizations. You might have noticed that the sign up and sign-in experiences have a Proseware look and feel, and there isn’t much if any visual evidence of Microsoft or Azure AD. We know that for you to build compelling consumer-facing experiences you have to have as much control as possible over look and feel, so B2C is very customizable even in this initial preview. We do this by enabling you to specify HTML and CSS for the pages rendered by B2C. Here’s what the sign up page would look like with the default look and feel:

But if I configure a B2C with a URL to a web page I created with Proseware-specific look and feel:

Then the sign up experience looks like this:

You can probably imagine a number of different approaches for this kind of customization. We’re partial to this approach, as opposed to say an API-based approach, because it means our servers are responsible for correct handling of things like passwords, and our protection systems can gather the maximum signal from the client for anomaly detection. In an API-based approach, your app would need to gather and handle passwords, and some amount of valuable signal would be lost.

One quick side note. In the initial preview it is possible to do HTML/CSS customization of all the pages except the local account sign in page. That page currently supports Azure AD tenant-branding style customization. We’ll be adding the HTML/CSS customization of the sign in page before GA. Also, we currently block the use of JavaScript for customization, but we expect to enable this later.

That’s a quick look at how I set up a sign up policy. Configuring other policies like sign in and profile management is very similar. As I mentioned earlier, you can create as many policies as you want, so you can trigger different behaviors even within the same app. How to do that? By requesting a specific policy at runtime! Let’s look at the code.

Building an app that uses B2C

The programming model for Azure AD B2C is super simple. Every request you send to B2C is an OAuth 2.0 or OpenID Connect request with one additional parameter, the policy parameter “p=”. This instructs B2C which policy you want to apply to the request. When someone clicks the sign up button on the Proseware web app, the app sends this OpenID Connect sign-in request:

GET /prosewareb2c.onmicrosoft.com/oauth2/v2.0/authorize?
nonce= WzRMD9LC95HeHvDz&

The policy parameter in this example invokes the sign up policy called b2c_1_standardsignup. The OpenID Connect response contains an id_token as usual, carrying the claims I configured in the policy:

POST https://proseware.skwantoso.com/auth/openid/return HTTP/1.1


Decoding the id_token from the response yields:

typ: “JWT”,
alg: “RS256″,
kid: “IdTokenSigningKeyContainer”
exp: 1442127696,
nbf: 1442124096,
ver: “1.0”,
iss: “https://login.microsoftonline.com/d7c377db-f609-41f3-be09-2b73defd48a0/v2.0/”,
acr: “b2c_1_standardsignup”,
sub: “Not supported currently. Use oid claim.”,
aud: “9bdade37-a70b-4eee-ae7a-b38e2c8a1416″,
nonce: “WzRMD9LC95HeHvDz”,
iat: 1442124096,
auth_time: 1442124096,
oid: “2c75d1d5-59af-479b-a9c3-d841ff298216″,
emails: [
idp: “localAccountAuthentication”,
name: “Stuart Kwan”,
extension_MembershipNumber: “1234”,
extension_OfferingType: “1”

Here you can see the usual claims returned by Azure Active Directory and also a few more. The custom attributes I added to the directory and requested of the user during sign up are returned in the token as extension_MembershipNumber and extension_OfferingType. You can also see the name of the policy that generated this token in the acr claim. By the way, we are in the process of taking feedback on claim type names and aligning ourselves better with the standard claim types in the OpenID Connect 1.0 specification. You should expect things to change here during the preview.

Since Azure AD B2C is in fact, Azure AD, it has the same programming model as Azure AD. Which means full support for web app, web API, mobile and PC app scenarios. Data in the directory is managed with the REST Graph API, so you can create, read, update, and delete objects the same way you can in a regular tenant. And this is super important – you can pick and choose what features and policies you want to use. If you want to build the user sign up process entirely yourself and manage users via the Graph API, you can absolutely do so.

B2C conforms to Azure AD’s next generation app model, the v2 app model. To build your application you can make protocol calls directly, or you can use the latest Azure Active Directory libraries that support v2. To find out more visit the B2C section of the Azure AD developer guide – we’ve got quickstart samples, libraries, and reference documentation waiting for you. Just for fun, I built the Proseware example using Node.js on an Ubuntu Linux virtual machine running on Microsoft Azure (shout out to @brandwe for helping me with the code!).

How much will it cost?

B2C will be charged on a consumption basis. You pay only for the resources you use. There will be three meters, billed monthly:

  1. Number of user accounts in the directory
  2. Number of authentications
  3. Number of multi-factor authentications

An authentication is defined as any time an application requests a token for a resource and successfully receives that token (we won’t charge for unsuccessful requests). When you consider the OAuth 2.0 protocol, this counts as when a user signs in with a local account or social account, and also when an application uses a refresh token to get a new access token.

You can find the B2C pricing tiers on the Azure.com pricing page. There will be a free tier for developers who are experimenting with the service. The current B2C preview is free of charge and preview tenants are capped at 50,000 users. We can raise that cap for you on a case by case basis if you contact us. We’ll lift the cap when billing is turned on. Do you have hundreds of millions of users? No problem. Bring ‘em on!

What’s next

We’ve already worked with many developers to build apps using Azure AD B2C as part of a private preview program. Along the way we’ve gathered a healthy backlog of features:

  1. Full UX customization: Not just the aforementioned HTML/CSS customization of the local account sign in page, but also the ability to have your URL appear in the browser for every page rendered by B2C. That will remove the last visible remnant of Microsoft from the UX.
  2. Localization: Of course you have users all over the world speaking many languages. Sign in, sign up, and other pages need to render appropriately using strings you provide in the languages you want to support.
  3. Token lifetime control: The ability to control the lifetimes of Access Tokens, ID Tokens and Refresh Tokens is important both for user experience and for you to tune your consumption rate.
  4. A hook at the end of sign up: A number of people have said they want the ability to check a user who is signing up against a record in a different system. A little hook at the end of sign up would allow them to do this, so we’re considering it.
  5. Support for more social networks.
  6. Support for custom identity providers: This would be the ability to, say, add an arbitrary SAML or OpenID Connect identity provider to the tenant.
  7. A variety of predefined reports: So that you can review the activity in your tenant at a glance and without having to write code to call an audit log API.
  8. And more, this is just a fraction of the list…

You can track our progress by following the What’s New topic in the B2C section of the Azure AD developer guide, which you can find in the documentation pages and also by following this blog.

By the way, the proper name of this preview is the Azure Active Directory B2C Basic preview. We’re planning a Premium offering as well, with features that take policies to the next level. But that’s for another blog post!

Please write us

We’re eager to hear your feedback! We monitor stackoverflow (tag: azure-active-directory) for development questions. If you have a feature suggestion, please post it in the Azure Active Directory User Voice site and put “AADB2C:” in the title of your suggestion.

Stuart Kwan (Twitter: @stuartkwan)
Principal Program Manager
Azure Active Directory


Diagram 2.0: No hub. No center.

As I wrote here, Mary Jo Foley's interpretation of one of the diagrams in John Shewchuk's second WAAD post made it clear we needed to get a lot visually crisper about what we were trying to show.  So I promised that we'd go back to the drawing board.  John put our next version out on twitter, got more feedback (see comments below) and ended up with what Mary Jo christened “Diagram 2.0″.  Seriously, getting feedback from so many people who bring such different experiences to bear on something like this is amazing.  I know the result is infinitely clearer than what we started with.

In the last frame of the diagram, any of the directories represented by the blue symbol could be an on-premise AD, a Windows Azure AD, something hybrid, an OpenLDAP directory, an Oracle directory or anything else.  Our view is that having your directory operated in the cloud simplifies a lot.  And we want WAAD to be the best possible cloud directory service, operating directories that are completely under the control of their data owners:  enterprises, organizations, government departments and startups.

Further comments welcome.

Good news and bad news from Delaware Lawmakers

Reading the following SFGate story was a real rollercoaster ride: 

DOVER, Del. (AP) — State lawmakers have given final approval to a bill prohibiting universities and colleges in Delaware from requiring that students or applicants for enrollment provide their social networking login information.

The bill, which unanimously passed the Senate shortly after midnight Saturday, also prohibits schools and universities from requesting that a student or applicant log onto a social networking site so that school officials can access the site profile or account.

The bill includes exemptions for investigations by police agencies or a school's public safety department if criminal activity is suspected.

Lawmakers approved the bill after deleting an amendment that expanded the scope of its privacy protections to elementary and secondary school students.

First of all there was the realization that if lawmakers had to draft this law it meant universities and colleges were already strong-arming students into giving up their social networking credentials.  This descent into hell knocked my breath away. 

But I groped my way back from the burning sulfur since the new bill seemed to show a modicum of common sense. 

Until finally we learn that younger children won't be afforded the same protections…   Can teachers and principals actually bully youngsters to log in to Facebook and access their accounts?  Can they make kids hand over their passwords?  What are we teaching our young people about their identity?

Why oh why oh why oh? 


Identity Management As A Service

A few weeks ago at the European Identity and Cloud Conference I gave a keynote called Conflicting Visions of Cloud Identity. It was the first time that I reported publicly on the work I've been doing over the last year on understanding what cloud computing means for identity – and vice versa.

The keynote led to many interesting exchanges with others at the conference. The conversations ranged from violent agreement to “animated dissidence” – and most important, to the discussion of many important nuances.

It became clear to me that a lot of us involved with information technology could really benefit from an open exchange about these issues. We have the chance to accelerate and align our understanding and to explore the complexities and opportunities.

So today I'd like to take a first step in that direction and lay out a few high level ideas that I'll flesh out more concretely in upcoming posts.  I hope these will goad some of you into elaborating, pushing back, and taking our conversation in other completely different directions.

Preparing for dramatic change

To me, the starting point for this conversation is that Identity Management and the way it is delivered will change dramatically over the next decade as organizations respond to new economic and social imperatives by adopting cloud technology.

We all need to understand this change.

Organizations will find they need new identity management capabilities to take full advantage of the cloud. They will also find that the most reliable and cost-effect way to obtain these capabilities is through Identity Management as a Service – i.e. using the cloud to master the cloud.

We can therefore predict with certainty that almost all organizations will subscribe to identity services that are cheaper, broader in scope and more capable than the systems of today.

Enterprises will use these services to manage authentication and authorization of internal employees, the supply chain, and customers (including individuals), leads and prospects. Governments will use them when interacting with other government agencies, enterprises and citizens.

Identity Management As A Service will require that we move beyond the models of identity management that have guided our thinking to date. A new service-based model will emerge combining more advanced capabilities with externalization of operations to achieve reduction in risk, effort and cost.

Redefining Identity Management

The term “Identity Management” will be redefined to include everything needed to provide and consume identity in our increasingly networked and federated world.  This is so profound that it constitutes a “reset”.

As a category, Identity Management will expand to encompass all aspects of identity:

  • registration of people, organizations, devices and services;
    management of credentials;
  • collection and proofing of attributes;
  • claims issuance;
  • claims acceptance;
  • assignment of roles;
  • management of groups;
  • cataloging of relationships;
  • maintenance of personalization information;
  • storage and controlled publication of information through directory;
  • confidential auditing; and
  • assurance of compliance.

The baseline capability of Identity Management will be to enhance the security and privacy of both organizations and individuals.

There will be a new market of next-generation identity management service providers with characteristics shaped by the importance of identity for both the protection of assets and the enhancement of relationships as we enter the era of the social enterprise.

Meanwhile, the current market for identity management products will be challenged by the simplification, cost reduction and increased innovation possible in the cloud.

Going forward, the term Identity Management As A Service will come up so often that we need an acronym.  For the time being I'm going to adopt the one my friend Eric Norlan proposed over six years ago : IDMaaS. While we're at it, it is worth looking at Eric's prescient article in ZDNet - he wrote it back in 2006 when he was a partner at Digital ID World. Eric reports on a conversation where Jamie Lewis (then CEO of the Burton Group) argued that “companies would find identity data too important to hand-over to others” – a view that certainly described the way enterprises felt at that time.  These issues are still critically important, though many profound evolutions have, I think, transformed the variables in the equations.  These new variables will be ones we want to drill into going forward.

Microsoft and IDMaaS

One of the reasons I want to share my thoughts about Identity Management as a Service now is that they constitute part of the theoretical framework that lies behind many of the decisions about the kind of organizational identity service we at Microsoft are offering. 

I'm therefore really excited to say that today we are able to start bringing you up to speed on exactly what that is.  Here's a quote from today's blog post by my close colleague and friend John Shewchuk, the Technical Fellow who plays a key role in getting our cloud identity offering engineered right: 

What is Windows Azure Active Directory?

We have taken Active Directory, a widely deployed, enterprise-grade identity management solution, and made it operate in the cloud as a multitenant service with Internet scale, high availability, and integrated disaster recovery.

Since we first talked about it in November 2011, Windows Azure Active Directory has shown itself to be a robust identity and access management service for both Microsoft Office 365 and Windows Azure–based applications.

In the interim, we have been working to enhance Windows Azure Active Directory by adding new, Internet-focused connectivity, mobility, and collaboration capabilities that offer value to applications running anywhere and on any platform. This includes applications running on mobile devices like iPhone, cloud platforms like Amazon Web Services, and technologies like Java.

The easiest way to think about Windows Azure Active Directory is that Microsoft is enabling an organization’s Active Directory to operate in the cloud. Just like the Active Directory feature in the Windows Server operating system that operates within your organization, the Active Directory service that is available through Windows Azure is your organization’s Active Directory. Because it is your organization’s directory, you decide who your users are, what information you keep in your directory, who can use the information and manage it, and what applications are allowed to access that information. And if you already have on-premises Active Directory, this isn’t an additional, separate copy of your directory that you have to manage independently; it is the same directory you already own that has been extended to the cloud.

Meanwhile, it is Microsoft’s responsibility to keep Active Directory running in the cloud with high scale, high availability, and integrated disaster recovery, while fully respecting your requirements for the privacy and security of your information.

John's post is called Reimagining Active Directory for the Social Enterprise.  It's done in two parts, and following that John will join into our broader conversation about the identity management reset.   I hope the combination of our two blogs can help animate an industry-wide discussion while providing a specific channel through which people can get the information they need about Microsoft's identity service offering.

Later this week:  The Changing Model of Identity Management.  I hope to see you there.


Disintermediation: an Amazon parable

New York TImes Technology ran a story yesterday about the publishing industry that is brimming with implications for almost everyone in the Internet economy.  It is about Amazon and what marketing people call “disintermediation”.  Not the simple kind that was the currency of the dot.com boom;  we are looking here at a much more advanced case:

SEATTLE — Amazon.com has taught readers that they do not need bookstores. Now it is encouraging writers to cast aside their publishers.

Amazon will publish 122 books this fall in an array of genres, in both physical and e-book form. It is a striking acceleration of the retailer’s fledging publishing program that will place Amazon squarely in competition with the New York houses that are also its most prominent suppliers.

It has set up a flagship line run by a publishing veteran, Laurence Kirshbaum, to bring out brand-name fiction and nonfiction…

Publishers say Amazon is aggressively wooing some of their top authors. And the company is gnawing away at the services that publishers, critics and agents used to provide…

Of course, as far as Amazon executives are concerned, there is nothing to get excited about:

“It’s always the end of the world,” said Russell Grandinetti, one of Amazon’s top executives. “You could set your watch on it arriving.”

But despite the sarcasm, shivers of disintermediation are going down the spines of many people in the publishing industry:

“Everyone’s afraid of Amazon,” said Richard Curtis, a longtime agent who is also an e-book publisher. “If you’re a bookstore, Amazon has been in competition with you for some time. If you’re a publisher, one day you wake up and Amazon is competing with you too. And if you’re an agent, Amazon may be stealing your lunch because it is offering authors the opportunity to publish directly and cut you out. ” [Read whole story here.]

If disintermediation is something you haven't thought about much, you might start with a look at wikipedia:

In economics, disintermediation is the removal of intermediaries in a supply chain: “cutting out the middleman”. Instead of going through traditional distribution channels, which had some type of intermediate (such as a distributor, wholesaler, broker, or agent), companies may now deal with every customer directly, for example via the Internet. One important factor is a drop in the cost of servicing customers directly.

Note that the “removal” normally proceeds by “inserting” someone or something new into transactions.  We could call the elimination of bookstores “first degree disintermediation” – the much-seen phenomenon of replacement of the existing distribution channel.   But it seems intuitively right to call the elimination of publishers “second degree disintermediation” – replacement of the mechanisms of production, including everything from product development through physical manufacturing and marketing, by the entities now predominating in distribution.  

The parable here is one of first degree disintermediation “spontaneously” giving rise to second degree disintermediation, since publishers have progressively less opportunity to succeed in the mass market without Amazon as time goes on.  Of course nothing ensures that Amazon's execution will cause it to succeed in a venture quite different from its current core competency.  But clearly the economic intrinsics stack the deck in its favor. Even without displacing its new competitors it may well skim off the most obvious and profitable projects, with the inevitable result of underfunding what remains.

I know.  You're asking what all this has to do with identityblog.

In my view, one of the main problems of reusable identities is that in systems like SAML, WS-Federation and Live ID, the “identity provider” has astonishing visibility onto the user's relationship with the relying parties (e.g. the services who reuse the identity information they provide).  Not only does the identity provider know what consumers are visiting what services; it knows the frequency and patterns of those visits.   If we simply ignore this issue and pretend it isn't there, it will become an Achilles Heel.

Let me fabricate an example so I can be more concrete.  Suppose we arrive at a point where some retailer decides to advise consumers to use their Facebook credentials to log in to its web site.  And let's suppose the retailer is super successful.  With Facebook's redirection-based single sign-on system, Facebook would be able to compile a complete profile of the retailer's customers and their log-on patterns.  Combine this with the intelligence from “Like” buttons or advertising beacons and Facebook (or equivalent) could actually mine the profiles of users almost as effectively as the retailer itself.  This knowledge represents significant leakage of the retailer's core intellectual property – its relationships with its customers.

All of this is a recipe for disintermediation of the exact kind being practiced by Amazon, and at some point in the process, I predict it will give rise to cases of spine-tingling that extend much more broadly than to a single industry like publishing. 

By the time this becomes obvious as an issue we can also predict there will be broader understanding of “second degree disintermediation” among marketers.  This will, in my view, bring about considerable rethinking of some current paradigms about the self-evident value of unlimited integration into social networks.  Paradoxically disintermediation is actually a by-product of the privacy problems of social networks.  But here it is not simply the privacy of end users that is compromised, but that of all parties to transactions. 

This problem of disintermediation is one of the phenomena leading me to conclude that minimal disclosure technologies like U-Prove and Idemix will be absolutely essential to a durable system of reusable identities.  With these technologies, the ability of the identity provider to disintermediate is broken, since it has no visibility onto the transactions carried out by individual users and cannot insert itself into the relationship between the other parties in the system. 

Importantly, while disintermediation becomes impossible, it is still possible to meter the use of credentials by users without any infringement of privacy, and therefore to build a viable business model.

I hope to write more about this more going forward, and show concretely how this can work.

Robots reshaping social networks

In May I was fascinated by a story in the Atlantic  on The Ecology Project - a group “interested in a question of particular concern to social-media experts and marketers: Is it possible not only to infiltrate social networks, but also to influence them on a large scale?” 

The Ecology Project was turning the Turing Test on its side, and setting up experiments to see how potentially massive networks of “SocialBots” (social robots) might be able to impact human social networks by interacting with their members.  

In the first such experiment it invited teams from around the world to manufacture SocialBots  and picked 500 real Twitter users, the core of whom shared “a fondness for cats”.  At the end of their two-week experiment, network graphs showed that the teams’ bots had insinuated themselves strikingly into the center of the target network.

The Web Ecology Blog summarized the results this way:

With the stroke of midnight on Sunday, the first Socialbots competition has officially ended. It’s been a crazy last 48 hours. At the last count, the final scores (and how they broke down) were:

  • Team C: 701 Points (107 Mutuals, 198 Responses)
  • Team B: 183 Points (99 Mutuals, 28 Responses)
  • Team A: 170 Points (119 Mutuals, 17 Responses)

This leaves the winner of the first-ever Socialbots Cup as Team C. Congratulations!

You also read those stats right. In under a week, Team C’s bot was able to generate close to 200 responses from the target network, with conversations ranging from a few back and forth tweets to an actual set of lengthy interchanges between the bot and the targets. Interestingly, mutual followbacks, which played so strong as a source for points in Round One, showed less strongly in Round Two, as teams optimized to drive interactions.

In any case, much further from anything having to do with mutual follows or responses, the proof is really in the pudding. The network graph shows the enormous change in the configuration of the target network from when we first got started many moons ago. The bots have increasingly been able to carve out their own independent community — as seen in the clustering of targets away from the established tightly-knit networks and towards the bots themselves.

The Atlantic story summarized the implications this way:

Can one person controlling an identity, or a group of identities, really shape social architecture? Actually, yes. The Web Ecology Project’s analysis of 2009’s post-election protests in Iran revealed that only a handful of people accounted for most of the Twitter activity there. The attempt to steer large social groups toward a particular behavior or cause has long been the province of lobbyists, whose “astroturfing” seeks to camouflage their campaigns as genuine grassroots efforts, and company employees who pose on Internet message boards as unbiased consumers to tout their products. But social bots introduce new scale: they run off a server at practically no cost, and can reach thousands of people. The details that people reveal about their lives, in freely searchable tweets and blogs, offer bots a trove of personal information to work with. “The data coming off social networks allows for more-targeted social ‘hacks’ than ever before,” says Tim Hwang, the director emeritus of the Web Ecology Project. And these hacks use “not just your interests, but your behavior.”

A week after Hwang’s experiment ended, Anonymous, a notorious hacker group, penetrated the e-mail accounts of the cyber-security firm HBGary Federal and revealed a solicitation of bids by the United States Air Force in June 2010 for “Persona Management Software”—a program that would enable the government to create multiple fake identities that trawl social-networking sites to collect data on real people and then use that data to gain credibility and to circulate propaganda.

“We hadn’t heard of anyone else doing this, but we assumed that it’s got to be happening in a big way,” says Hwang. His group has published the code for its experimental bots online, “to allow people to be aware of the problem and design countermeasures.”

The Ecology Project source code is available here.  Fascinating.  We're talking very basic stuff that none-the-less takes social engineering in an important and disturbingly different new direction. 

As is the case with the use of robots for social profiling, the use of robots to reshape social networks raises important questions about attribution and identity (the Atlantic story actually described SocialBots as “fake identities”).  

Given that SocialBots will inevitably and quickly evolve, we can see that the ability to demonstrate that you are a natural flesh-and-blood person rather than a robot will increasingly become an essential ingredient of digital reality.  It will be crucial that such a proof can be given without requiring you to identify yourself,  relinquish your anonymity, or spend your whole life completing grueling captcha challenges. 

I am again struck by our deep historical need for minimal disclosure technology like U-Prove, with its amazing ability to enable unlinkable anonymous assertions (like liveness) and yet still reveal the identities of those (like the manufacturers of armies of SocialBots) who abuse them through over-use.


New paper on Wi-Fi positioning systems

Regular readers will have come across (or participated in shaping) some of my work over the last year as I looked at the different ways that device identity and personal identity collide in mobile location technology.

In the early days following Google's Street View WiFi snooping escapades, I became increasingly frustrated that public and official attention centered on Google's apparently accidental collection of unencrypted network traffic when there was a much worse problem staring us in the face.

Unfortunately the deeper problem was also immensely harder to grasp since it required both a technical knowledge of networked devices and a willingness to consider totally unpredicted ways of using (or misusing) information.

As became clear from a number of the conversations with other bloggers, even many highly technical people didn't understand some pretty basic things – like the fact that personal device identifiers travel in the clear on encrypted WiFi networks… Nor was it natural for many in our community to think things through from the perspective of privacy threat analysis.

This got me to look at the issues even more closely, and I summarized my thinking at PII 2010 in Seattle.

A few months ago I ran into Dr. Ann Cavoukian, the Privacy Commissioner of Ontario, who was working on the same issues.  We decided to collaborate on a very in-depth look at both the technology and policy implications, aiming to produce a document that could be understood by those in the policy community and still serve as a call to the technical community to deal appropriately with the identity issues, seeking what Ann calls “win-win” solutions that favor both privacy and innovation.

Ann's team deserves all the credit for the thorough literature research and clear exposition.  Ann expertly describes the policy issues and urges us as technologists to adopt Privacy By Design principles for our work. I appreciate having had the opportunity to collaborate with such an innovative group.  Their efforts give me confidence that even difficult technical issues with social implications can be debated and decided by the people they affect.

Please read WiFi Positioning Systems: Beware of Unintended Consequences and let us know what you think – I invite you to comment (or tweet or email me) on the technical, policy and privacy-by-design aspects of the paper.

Google opposing the “Right to be forgotten”

In Europe there has been a lot of discussion about “the Right to be Forgotten” (see, for example, Le droit à l’oubli sur Internet).  The notion is that after some time, information should simply fade away (counteracting digital eternity).    

In America, the authors of the Social Network Users’ Bill of Rights have called their variant of this the “Right to Withdraw”.  

Whatever words we use, the right, if recognized, would be a far-reaching game-changer – and as I wrote here, represent a “cure as important as the introduction of antibiotics was in the world of medicine”.

Against this backdrop, the following report by CIARAN GILES of the Associated Press gives us much to think about. It appears Google is fighting head-on against the “the Right to be Forgotten”.  It seems to be willing to take on any individual or government who dares to challenge the immutable right of its database and algorithms to define you through something that has been written – forever, and whether it's true or not.

MADRID – Their ranks include a plastic surgeon, a prison guard and a high school principal. All are Spanish, but have little else in common except this: They want old Internet references about them that pop up in Google searches wiped away.

In a case that Google Inc. and privacy experts call a first of its kind, Spain's Data Protection Agency has ordered the search engine giant to remove links to material on about 90 people. The information was published years or even decades ago but is available to anyone via simple searches.

Scores of Spaniards lay claim to a “Right to be Forgotten” because public information once hard to get is now so easy to find on the Internet. Google has decided to challenge the orders and has appealed five cases so far this year to the National Court.

Some of the information is embarrassing, some seems downright banal. A few cases involve lawsuits that found life online through news reports, but whose dismissals were ignored by media and never appeared on the Internet. Others concern administrative decisions published in official regional gazettes.

In all cases, the plaintiffs petitioned the agency individually to get information about them taken down.

And while Spain is backing the individuals suing to get links taken down, experts say a victory for the plaintiffs could create a troubling precedent by restricting access to public information.

The issue isn't a new one for Google, whose search engine has become a widely used tool for learning about the backgrounds about potential mates, neighbors and co-workers. What it shows can affect romantic relationships, friendships and careers.

For that reason, Google regularly receives pleas asking that it remove links to embarrassing information from its search index or least ensure the material is buried in the back pages of its results. The company, based in Mountain View, Calif., almost always refuses in order to preserve the integrity of its index.

A final decision on Spain's case could take months or even years because appeals can be made to higher courts. Still, the ongoing fight in Spain is likely to gain more prominence because the European Commission this year is expected to craft controversial legislation to give people more power to delete personal information they previously posted online.

“This is just the beginning, this right to be forgotten, but it's going to be much more important in the future,” said Artemi Rallo, director of the Spanish Data Protection Agency. “Google is just 15 years old, the Internet is barely a generation old and they are beginning to detect problems that affect privacy. More and more people are going to see things on the Internet that they don't want to be there.”

Many details about the Spaniards taking on Google via the government are shrouded in secrecy to protect the privacy of the plaintiffs. But the case of plastic surgeon Hugo Guidotti vividly illustrates the debate.

In Google searches, the first link that pops up is his clinic, complete with pictures of a bare-breasted women and a muscular man as evidence of what plastic surgery can do for clients. But the second link takes readers to a 1991 story in Spain's leading El Pais newspaper about a woman who sued him for the equivalent of euro5 million for a breast job that she said went bad.

By the way, if it really is true that the nothing should ever interfere with the automated pronouncements of the search engine – even truth – does that mean robots have the right to pronounce any libel they want, even though we don't?