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:

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:



Decoding the id_token from the response yields:

typ: “JWT”,
alg: “RS256″,
kid: “IdTokenSigningKeyContainer”
exp: 1442127696,
nbf: 1442124096,
ver: “1.0”,
iss: “”,
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 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


Kerry McCain bill proposes “minimal disclosure” for transaction

Steve Satterfield at Inside Privacy gives us this overview of central features of new Commercial Privacy Bill of Rights proposed by US Senators Kerry and McCain (download it here):

  • The draft envisions a significant role for the FTC and includes provisions requiring the FTC to promulgate rules on a number of important issues, including the appropriate consent mechanism for uses of data.  The FTC would also be tasked with issuing rules obligating businesses to provide reasonable security measures for the consumer data they maintain and to provide transparent notices about data practices.
  • The draft also states that businesses should “seek” to collect only as much “covered information” as is reasonably necessary to provide a transaction or service requested by an individual, to prevent fraud, or to improve the transaction or service
  • “Covered information” is defined broadly and would include not just “personally identifiable information” (such as name, address, telephone number, social security number), but also “unique identifier information,” including a customer number held in a cookie, a user ID, a processor serial number or a device serial number.  Unlike definitions of “covered information” that appear in separate bills authored by Reps. Bobby Rush (D-Ill.) and Jackie Speier (D-Cal.), this definition specifically covers cookies and device IDs.
  • The draft encompasses a data retention principle, providing that businesses should only retain covered information only as long as necessary to provide the transaction or service “or for a reasonable period of time if the service is ongoing.” 
  • The draft contemplates enforcement by the FTC and state attorneys general.  Notably — and in contrast to Rep. Rush's bill — the draft does not provide a privacy right of action for individuals who are affected by a violation. 
  • Nor does the bill specifically address the much-debated “Do Not Track” opt-out mechanism that was recommended in the FTC's recent staff report on consumer privacy.  (You can read our analysis of that report here.) 

As noted above, the draft is reportedly still a work in progress.  Inside Privacy will provide additional commentary on the Kerry legislation and other congressional privacy efforts as they develop.   

Press conference will be held tomorrow at 12:30 pm.  [Emphasis above is mine – Kim]

Readers of Identityblog will understand that I see this development, like so many others, as inevitable and predictable consequences of many short-sighted industry players breaking the Laws of Identity.


Touch2Id Testimonials

Last summer I wrote about the British outfit called touch2id.  They had developed a system that sounded pretty horrible when I first heard about it – a scheme to control underage drinking by using peoples’ fingerprints rather than getting them to present identity cards.  I assumed it would be another of the hair-brained biometric schemes I had come across in the past – like this one, or this, or these.

But no.  The approach was completely different.  Not only was the system popular with its early adopters, but its developers had really thought through the privacy issues.   There was no database of fingerprints, no record linking a fingerprint to a natural person.  The system was truly one of “minimal disclosure” and privacy by design:

  • To register, people presented their ID documents and, once verified, a template of their fingerprint was stored on a Touch2Id card that was immediately given to them.  The fingerprint was NOT stored in a database
  • When people with the cards wanted to have a drink, they would wave their card over a machine similar to a credit card reader, and press their finger on the machine.  If their finger matched the template on their card, the light came on indicating they were of drinking age and they could be served.

A single claim:  “Able to drink“.  Here we had well designed technology offering an experience that the people using it liked way better than the current “carding” process – and which was much more protective of their privacy.  “Privacy by design” was delivering tangible benefits.  Merchants didn’t have to worry about making mistakes.  Young people didn’t have to worry about being discriminated against (or being embarassed) just because they “looked young” or got a haircut.  No identifying information was being released to the merchants.  No name, age or photo was stored on the cards.  The movements of young people were not tracked.  And so on.

Today touch2id published Testemonials - an impressive summary of their project consisting of reviews by individuals involved.  It is clear that those who liked it loved it.  It would be interesting to find out to what extent these rave reviews are typical of those who tried the system.  

At any rate, it's instructive to compare the positive outcome of this pilot with all the biometric proposals that have crashed onto the shoals of privacy invasion.

ZIP ruled personally identifying in California

From CNN this surprising story:

California's high court ruled Thursday that retailers don't have the right to ask customers for their ZIP code while completing credit card transactions, saying that doing so violates a cardholders’ right to protect his or her personal information.

Many retailers in California and nationwide now ask people to give their ZIP code, punching in that information and recording it. Yet California Supreme Court's seven justices unanimously determined that this practice goes too far.

The ruling, penned by Justice Carlos Moreno, overrules earlier decisions by trial and appeals courts in California. It points to a 1971 state law that prohibits businesses from asking credit cardholders for “personal identification information” that could be used to track them down.

While a ZIP code isn't a full address, the court's judgment states that asking for it — and piecing that 5-digit number together with other information, like a cardholder's name — “would permit retailers to obtain indirectly what they are clearly prohibited from obtaining directly, (therefore) ‘end-running'” the intent of California state laws.

“The legislature intended to provide robust consumer protections by prohibiting retailers from soliciting and recording information about the cardholder that is unnecessary to the credit card transaction,” the decision states. “We hold that personal identification information … includes the cardholder's ZIP code.”

Bill Dombrowski, president of the California Retailers Association, said it is “ironic” that a practice aimed partly at protecting consumers from fraud is being taken away.

“We think it's a terrible decision because it dramatically expands what personal information is, by including a ZIP code as part of an address,” Dombrowski said. “We are surprised by it.”

The court decision applies only in California, though it reflects a practice that is increasingly common elsewhere. It does not specify how or if all businesses that take credit cards, such as gas stations, would be affected — though it does state that its objection is not over a retailer seeing a person's ZIP code, but rather recording and using it for marketing purposes.

The discussion began with a June 2008 class-action lawsuit filed initially by Jessica Pineda against home retailer Williams-Sonoma.

In her suit, Pineda claimed that a cashier had asked for her ZIP code during a purchase — information that was recorded and later used, along with her name, to figure out her home address. Williams-Sonoma did this tapping a database that it uses to market products to customers and sell its compiled consumer information to other businesses.

Pineda contended the practice of asking for ZIP codes violates a person's right to privacy, made illegal use of her personal information and gave a retailer, like Williams-Sonoma, an unfair competitive advantage.

Williams-Sonoma claimed that a ZIP code doesn't constitute “personal identification information,” as stated in the 1971 state law.

The state supreme court ruling, only addressing the “identification information” issue, determined that a ZIP code should be protected, since the law specifically mentions protecting a cardholder's address. The court concluded requesting a ZIP code is not much different than asking for a phone number or home address.

It is not illegal in California for a retailer to see a person's ZIP code or address, the ruling notes: For instance, one can request a customer's driver's license to verify his or her identity. What makes it wrong is when a business records that information, according to the ruling, especially when the practice is “unnecessary to the sales transaction.”

In reversing the Court of Appeals judgment, the supreme court remanded the case back to a lower court to order specific changes and policies “consistent with this decision.”

The important thing here is that the Court understood a very nuanced technical point: although the ZIP is not in itself personally identifying, when used with other information such as name, the ZIP becomes personally identifying.  Understanding the privacy implications of such information combinations is key. I think there is much wisdom in the Court recognizing that this is a defining issue.

In terms of industry reaction, the notion that recording our ZIP protects us is totally ludicrous and shows to what extent we are in need of stronger privacy-protecting identity solutions like U-Prove. The logic of the California Retailers Association is pathetically convoluted – will someone please give these people a consultant for Christmas?

My thanks to Craig Wittenberg for the heads up on this story. He saw it as a sign that minimal disclosure laws already exist in the US…

That's an interesting idea. One way or the other, it is extremely important to get harmonization on this kind of question across business jurisdictions.  Looking at cases like this one, I have a feeling harmonization might possibly take “quite a while” to achieve…

The Clay Feet of Giants?

Over at Craig Burton, the marketing guru who put Netware on the map and later formed the Burton Group with Jamie Lewis lets loose with a passionate fury that couldn't care less about who has deployed what:

It’s been a week since Microsoft announced that it was never going to release the next version of CardSpace. The laughable part of the announcement is the title “Beyond Windows CardSpace” which would leave you to believe that Microsoft has somehow come up with a better architecture.

In fact Microsoft announced its discontinued development of CardSpace with absolutely no alternative.

Just further evidence of just how irrelevant Microsoft has become.

The news that Microsoft had abandoned CardSpace development is not news to those of us who watch this space, Microsoft hasn’t done Jack with CardSpace for over two years.

It’s just that for some reason Microsoft PR decided to announce the matter. Probably so the U-Prove group could get more press.

Well, that's a bit harsh. Identity selectors like CardSpace only make sense in the context of the other components of the Identity Metasystem – and Microsoft has done a lot over the last two years to deliver those components to customers who are doing successful deployments on a massive scale all over the world.  I don't think that's irrelevant, Craig.

Beyond that, I think Craig should look more closely at what the U-Prove agent actually does (I'll help by putting up a video). As I said here, the U-Prove agent doesn't do what CardSpace did. And the problems CardSpace addressed DO remain tremendously important.  But while more tightly scoped, for the crucial scenario of sensitive claims that are privacy protected the U-Prove agent does go beyond CardSpace.  Further, protecting privacy within the Identity Metasystem will turn out, historically, to be absolutely relevant.  So let's not hit on U-Prove.

Instead, let's tune in to Craig's “Little History” of the Identity Metasystem:

In early 2006, Kim Cameron rolled out the Laws of Identity in his blog. Over next few months as he rolled out each law, the impact of this powerful vision culminating in the release of the CardSpace architecture and Microsoft’s licensing policy rocked the identity community.

Two years earlier Microsoft was handed its head when it tried to shove the Passport identity initiative down our throats.

Kim Cameron turned around and proposed and delivered an Identity Metasystem—based on CardSpace—that has no peer. Thus the Identity Metasystem is the industry initiative to create open selector-based digital identity framework. CardSpace is Microsoft’s instantiation of that Metasystem. The Pamela Project, XMLDAP, Higgins Project, the Bandit Project, and openinfocard are all instantiations in various stages of single and multiple vendor versions of the Identity Metasystem.

Let me clear. The Identity Metasystem has no peer.

Anything less than a open identity selector system for claims-based digital identity is simply a step backwards from the Identity Metasystem.

Thus SAML, OpenID, OAuth, Facebook Connect and so on are useful, but are giant steps back in time and design when compared to the Identity Metasystem.

I agree that the Identity Metasystem is as important as Craig describes it, and that to reach its potential it MUST have user agents. I further agree that the identity selector is the key component for making the system user centric. But I also think adoption is, ah, essential… We need to work out a kink or two or three. This is a hard problem and what we've done so far hasn't worked.

Be this as it may, back at Craig's site he marches on in rare form, dissecting Vendor Speak as he goes.  Mustering more than a few thrusts and parries (I have elided the juicier ones), he concludes:

This means there is an opening for someone or some group with a bit of vision and leadership to take up the task…

But mark my words, we WILL have a selector-based identity layer for the Internet in the future. All Internet devices will have a selector or a selector proxy for digital identity purposes.

I'm glad to finally see this reference to actual adoption, and now am just waiting for more discussion about how we could actually evolve our proposals to get this to happen.


Change will come: the present is untenable.

Gunnar Peterson at 1 Raindrop adds his own thoughts about CardSpace and Claims:

The official announcements from Microsoft on Cardspace have led to a lot of reflection in the identity community. From the core team, Mike Jones described what he considered some of the important barriers:

  • Not solving an immediate perceived problem: In my extensive experience talking with potential adopters, while many/most thought that CardSpace was a good idea, because they didn’t see it solving a top-5 pain point that they were facing at that moment or providing immediate compelling value, they never actually allocated resources to do the adoption at their site.
  • Not drop-dead simple to use: Users were often confused by their first encounter with CardSpace; many didn’t succeed at the task at hand. Indeed, many saw it as something complicated getting in the way of what they were actually there to do.

The first of these issues is one I am always trying to be cognizant of. From the 90s, a Bill Joy quote that stuck with me was when he described why JINI never took off – “we were solving problems that people did not know they had yet.” Its an every day occurrence to manage this reality-perception gap in infosec both from a business risk standpoint; as well as given the myriad of architectural opportunities for improvement (aka problems) which ones and where do you want to invest your time in strengthening your systems?

But from an industry perspective, there is a positive way to look at Bill Joy's quote – the word “yet.” Just a few years after JINI failed to launch, Web services took off like gangbusters and there is no end in sight.

As Howard Marks says in investing, sometimes being early is indistinguishable from being wrong, but that is a temporary thing, and a longer term view is in order. Jeremy Grantham (GMO) got out of tech stocks in the 90s bubble, his clients thought he was crazy and he lost half his business. Grantham called this taking career risk.

Another great value investor, Jean Marie Eveillard said about this episode – I would rather lose half my clients than lose half my client's money.

Everyone could see the tech bubble was out of control in the 1990s but very few investment managers were willing to take the career risk to themselves to protect their client's assets. 

Today everyone can see that our Internet identity technology is woefully inadequate, but very few are willing to push through comprehensive approaches towards addressing them.

Being early is not necessarily being wrong, but when coupled with a new usage paradigm, its more problematic. Farhang Kassaei discussed what the view looked like from the point of a consuming company looking to develop on Cardspace.

The Cardspace team has many talented people and freely published more in depth thinking on identity than anyone else in the industry. These lessons won't be forgotten and the future for Claims based access control is bright, in fact its just beginning. We may look back in a few years time and think of Cardspace like JINI and see tidal wave stack of CBAC/ABAC/Selectors/U-Prove that powered up huge new parts othe industry the same way Web services played out.

In fact I bet that we do. 

What's the other option? Living with a ridiculous patchwork approach to identity?

No one writes there own crypto, security people are good at getting this message across – but what do you bootstrap your crypto off of? Identity! And people write identity, authN, authZ, provisioning, from scratch all the time – where is the logic? 

Gunnar continues with an interesting reference to the behavioral economist Dan Ariely before concluding:

There is too much fraud, crime, malfeasance and threats to keep rolling out the same old same old identity. Change will come if for no other reason than the present is untenable.

Cardspace was like the first Marines trying to take the beach and some got cut down, but much has been learned in the process and the beach has to be taken; there are waves of identity and access improvement coming right now.

Rest in Peace Cardspace. Long Live Claims Based Access Control!

From CardSpace to Verified Claims

Last week Microsoft announced the availability of Version 2 of the U-Prove Technology Preview.

What’s new about it?

The most important thing is that it offers a new, web-oriented user experience carefully tailored to helping people control the release of “verified claims” while protecting their privacy.  By verified claims I mean things that are said about them as flesh-and-blood people by entities that can speak, at least in certain contexts, with authority. By protecting privacy I mean keeping information released to the minimum necessary, and ensuring that the authority making the claims – for example a government – is not able to track and profile the way your information is used.

The system takes a number of the good ideas from CardSpace but is also informed by what CardSpace didn’t do well. It doesn’t require the installation of new components on your computer. It works on all the major browsers and phones. It roams between devices. Sites don't have to worry about users “getting a card” before the system will work. And it allows claims providers and relying parties to shape and brand their users’ experiences while still providing a consistent interface for claims approval.

In other words, it represents a big step forward for protecting privacy using high value credentials to release claims.

A focused approach

When it comes to verified claims, the “U-Prove Agent” goes beyond CardSpace.  One way it does this is by being highly focused and integrated into a specific type of identity experience. I’ll be posting a video soon that will help you get a concrete sense of why this works.

That focus represents a change from what we tried to do with CardSpace.   One of the key goals of CardSpace was to provide a “generalized solution” – an alternative to the “patchwork quilt” of what I called “identity kludges” that characterize peoples’ experience of identity on the Internet.

In fact I still believe as much as ever that a “generalized solution” would be nice to have. I would even go so far as to say that a generalized solution is inevitable – at some point in time.

But the current chaos is so vast – and peoples’ thinking about it so fractured – that the only prudent practical approach is to carve the problem into smaller pieces. If we can make progress in some of the pieces we can tie that progress together. The U-Prove Agent for exchange of verified claims is a good example of this, making it possible to offer services that would otherwise be impossible because of privacy problems.

What about CardSpace?

Because of its focus, the U-Prove agent isn’t capable of doing everything that CardSpace attempted to do using Information Cards.

It doesn’t address the problem of helping users manage ALL their identities while keeping them separate. It doesn’t address the user problems of password fatigue, phishing and pervasive “secret questions” when logging into consumer web sites.  It doesn’t solve the famous “home realm discovery problem” when using federation. And perhaps most frustrating when it comes to using devices like phones, it doesn’t give the user a simple way to pick their identities from a set of visual representations (icons or cards).

These issues are all more pressing today than they were in 2006 when CardSpace was first proposed. Yet one thing is clear: in five years of intensive work and great cross-industry collaboration with other innovators working on Apple and Linux computers and phones, we weren’t able to get Information Cards onto the radar of the big web properties users depend on.

Those properties had other priorities. My friend Mike Jones put it well at Self-Issued:

“In my extensive experience talking with potential adopters, while many/most thought that CardSpace was a good idea, because they didn’t see it solving a top-5 pain point that they were facing at that moment or providing immediate compelling value, they never actually allocated resources to do the adoption at their site.”

Regardless of why this was the case, it explains why last week Microsoft also announced that it will not be shipping CardSpace 2.0.

In my personal view, we all certainly need to keep working on the problems Information Cards address, and many of the concepts and technologies used in Information Cards should be retained and evolved. I think the U-Prove team has done a good job at that, and provides an example of how we can move forward to solve specific problems. Now the question is how to do so with the other aspects of user-centric identity.

Over the next while I’m going to do a series of posts that explore some of these issues further – drawing some lessons from what we’ve learned over the last few years.  Most of all, it is important to remember what great progress we’ve made as an industry around the Identity Metasystem, federation technology, and claims-based computing. The CardSpace identity selector dealt with the hardest and most forward-looking problems of the Metasystem:  the privacy, security and usability problems that will emerge as federated identity becomes a key component of the Internet.  It also challenged industry with an approach that was truly user centric.

It's no surprise that it is hardest to get consensus on forward-looking technologies!  But meanwhile,  the very success of the Identity Metasystem as a whole will cause all the issues we’ve been working on with Information Cards to return larger than life.


Vittorio's new book is a must-read

Vittorio's new bookIf you are a programmer interested in identity, I doubt you'll find a more instructive or amusing video than this one by Vittorio Bertocci.  It's aimed at people who work in .NET and explores the Windows Identity Foundation.   I expect most programmers interested in identity will find it fascinating no matter what platform they work on, even if it just provides a point of comparison.

And that brings me to Vittorio's new book:  Programming Windows Identity Foundation.  I really only have one thing to say about it:  you are crazy to program in WIF without reading this book.  And if you're an architect rather than a coder – but still have a sense of reading code – you'll find that subjects like delegation benefit immensely from the concrete presentation Vittorio has put together.

I have to admit to being sufficiently engrossed that I had to drop everything I was doing in order to deal with some of the miniature brain-waves the book induced.  

But then, I have a soft spot for good books on programming.  I'm talking about books that have real depth but are simple and exciting because the writer has the same clarity as programmers have when they are in “programming trance”.  I used to even take a bunch of books with me when I went on vacation – it drove my mother-in-law nuts.

I'm not going to try to descibe Vittorio's book – but it really hangs together, and if you're trying to do anything original or complex it will give you the depth of understanding you need to do it efficiently.  Just as important, you'll enjoy reading it.

A confused critique of identity federation

in a recent piece at The Federal Circle, Earl Smith II, managing partner, comes out “all guns blazing” against identity federation and the “weird and wonderful” Laws of Identity. 

Earl wishes he could “simplify” digital identity, rejecting identity federation as being too abstract to solve digital identity problems.  Unfortunately, his view of things mixes up architecture and the way real live systems are deployed, and he creates a straw man out of particular deployment assumptions.  The resulting explanation demonstrates that once confused about this, things can look stranger and stranger: 

All such “federated identity” models start with the intuitively appealing premise that if an individual has already been identified by one service provider, then that identification should be made available to other services, to save time, streamline processes, reduce costs, and open up new business channels.  It’s a potent mix of supposed benefits, and yet strangely unachievable.

True, we can now enjoy the convenience of logging onto multiple blogs and social sites with an OpenID, or an unverified Twitter account.  But higher risk services like banking, e-health and government welfare stand apart, still maintaining their own identifiers and sovereign registration processes.

To my mind, the fashionable open identity approach is ironically lumbered with the same lofty ambitions that killed off traditional Big PKI.  The express aim is to create “trust frameworks” sufficient to enable business to be conducted amongst strangers.  To this end, federated identity proponents implore banks and government agencies to re-invent themselves as “Identity Providers” in accordance with the weird and wonderful Laws of Identity.

The Laws of Identity embody some powerful ideas, especially the view that when we go about our business, each of us exercises a plurality of virtual identities.  In different settings we present different identities, each standing as a proxy for a complex and bounded relationship.  We have different relationships with various entities and services: banks, government agencies, health services, employers, stores, professional associations, social networks and so on.  Each identity is context dependent, and can lose its meaning when taken out of context…

But for the most part, the Laws of Identity and the new ecosystem model are chockfull of unfamiliar abstractions.  They deconstruct identities, attributes and services, and imagine that when two parties meet for the first time with a desire to transact, they start from scratch to negotiate a set of attributes that confer mutual trust.  In practice, it is rare for parties in business to start from such a low base.  Instead, merchants assume that shoppers come with credit cards, patients assume that doctors come with medical qualifications, and banks assume that customers have accounts.  If you don’t have the right credential for the transaction at hand, then you simply can’t play (and you have to go back, out of band, and get yourself appropriately registered).

Perhaps the most distracting generalisation in the new identity ecosystem is that Service Providers, Identity Providers and Attribute Providers are all different entities.  In reality, these roles are all fulfilled simultaneously and inseparably by banks, governments, social networks and so on.

To put order into this nest of ideas, let's begin with what Earl calls “the most distracting generalization in the new ecosystem”:  that Service Providers, Identity Providers and Attribute Providers are all different entities. 

In fact, Earl, I made no such statement in the Laws of Identity or anywhere else, despite my support for an identity ecosystem.  

The Laws of Identity refers to an Identity Provider as issuing “claims”, a Relying Party as “depending on” claims, and a Subject as “presenting” claims, but makes no statement that if you do one you can't do the others.  Why?  Identity Provider, Subject and Relying Party are architectural roles.  A single entity can play any combination of those roles.  One particular combination is complete separation of the roles, but in most cases every entity plays more than one.     

For example, today's large web sites (like the MSN's, Googles and Yahoos) are composed of thousands of individual services.  Without having to be conscious of it, people log in to a site's Identity Provider service, which issues claims that are consumed by each of the composite Relying Party services that make up the site.  So the “decomposition” which Earl sees as “deconstructed unfamiliar abstractions” is, at the architectural level, a MUST in order to have large scalable sites, and this is as key to the current web as to the metasystem model which is just standardizing and extending it. 

I refer Earl and others to the User-Centric Identity Metasystem paper for more details.  Section 6.2 states:


The actors participating in the Identity Metasystem can be classified by role, taking into consideration that any individual actor or set of actors can play multiple roles (both at the same time and at different times).

(6.2 goes on to define roles such as Subject, Claims Issuer, Relying Party, etc).

That paper is not simple-minded in its presentation, but its goal is to lay out a model for precisely understanding the way identity systems actually work and can work in the future, not to do mass pedagogy.  People using Facebook or Google or Windows Live never think about the decomposition of services within the identity fabric, yet depend every day on that very decomposition.

Continuing to unwind Earl's comments, let's factor out what he says about Trust Frameworks.  Here I'm not unsympathetic to the points he is making, though I think they are only part of the story.  I agree that most initial usage of the architecture is, as in the examples I've given here, within tightly bounded trust contexts. But I also think that once the technology framework is in place (e.g. now…) we will see more and more examples of federation within wider contexts where it makes sense.  The question is simply, “what makes sense”?

If I could use my banking identity to log into the IRS, would that make sense to me?  Yes, because I don't access the IRS site often enough that I can ever remember an IRS credential.  Would it make sense to Earl?  Maybe not.  So that very potential divergence leads us to posit the need for an ecology with choices – one of which would be the IRS itself for those who don't relate to bridging of contexts.

Earl calls upon us to agree on a few simplifying assumtions:

  • There aren’t many strangers in real life business
  • Relying Party and “Identity Provider” are often the same
  • There are no surprise credentials

These are all good points, but don't diminish the utility of federation.  For example, in the case of using a banking identity to access the IRS, I'm not a stranger to the IRS, nor is the bank.  And my banking credential is not a surprise.  I just don't want the IRS to make me manage an extra credential for once-a-year use.  Requiring me to do this is not a simplifying assumption!

Paradoxically the next piece by Earl at The Federal Circle is called Will Cost Savings Continue to be a Significant Driver for Cloud Computing?  But Earl never asks how an enterprise or government organization that runs some of its services in the cloud handles the resulting identity problems without increasing its costs… 

Would he suggest two credentials, one for inside the enterprise and one to get to the cloud?  Two helpdesks?  Two authorization systems?  Or would he agree we should be able to reuse a single credential across these two contexts? 

Bingo.  Wouldn't it be nice if Cloud services could rely on (dare I say be a Relying Party for) identities provided by the enterprise or government?   The point is that if I build my identity systems today in keeping with an architecture that allows various roles to be played wherever it makes most sense, I set myself up for a future that is unfolding in ways I can't always predict. 

I hope that as someone advising people on how to grow and future-proof their organizations, Earl looks at the issues involved in federation one more time.  The ability to cross technological and organization boundaries – which is called federation – is central to our ability to evolve with the agility Earl rightly sees as necessary. 

Once Earl comes to see that federation architecture is completely consistent with the assumptions he puts forward, I have the feeling he will have an interesting perspective on the kinds of cross-context claims that make sense in various business and government contexts. 

Southworks seeds open source claims transformer

Reading Matias Woloski's blog I see that Southworks has put its work bridging OpenID and WS-Federation into an open source project (download here).    This is a great move.  He also shows some screen shots that give a good feel for what was involved in the Medtronics proof of concept described here.  Matias writes:

A year ago I wrote a blog post about how to use the Windows Identity Foundation with OpenID. Essentially the idea was writing an STS that can speak both protocol WS-Federation and OpenID, so your apps can keep using WIF as the claims framework, no matter what your Identity Provider is. WS-Fed == enterprise, OpenID == consumer…

Fast forward to May this year, I’m happy to disclose the proof of concept we did with the Microsoft Federated Identity Interop group (represented by Mike Jones), Medtronic and PayPal. The official post from the Interoperability blog includes a video about it and Mike also did a great write up

The business scenario brought by Medtronic is around an insulin pump trial. In order to register to this trial, users would login with PayPal, which represents a trusted authority for authentication and attributes like shipping address and age for them. Below are some screenshots of the actual proof of concept:





While there are different ways to solve a scenario like this, we chose to create an intermediary Security Token Service that understands the OpenID protocol (used by PayPal), WS-Federation protocol and SAML 1.1 tokens (used by Medtronic apps). This intermediary STS enables SSO between the web applications, avoiding re-authentication with the original identity provider (PayPal).

Also, we had to integrate with a PHP web application and we chose the simpleSAMLphp library. We had to adjust here and there to make it compatible with ADFS/WIF implementation of the standards. No big changes though.

We decided together with the Microsoft Federated Identity Interop team to make the implementation of this STS available under open source using the Microsoft Public License.

And not only that but also we went a step further and added a multi-protocol capability to this claims provider. This is, it’s extensible to support not only OpenID but also OAuth and even a proprietary authentication method like Windows Live.




DISCLAIMER: This code is provided as-is under the Ms-PL license. It has not been tested in production environments and it has not gone through threats and countermeasures analysis. Use it at your own risk.

Project Home page



If you are interested and would like to contribute, ping us through the github page, twitter @woloski or email matias at southworks dot net

This endeavor could not have been possible without the professionalism of my colleagues: Juan Pablo Garcia who was the main developer behind this project, Tim Osborn for his support and focus on the customer, Johnny Halife who helped shaping out the demo in the early stages in HTML :), and Sebastian Iacomuzzi that helped us with the packaging. Finally, Madhu Lakshmikanthan who was key in the project management to align stakeholders and Mike who was crucial in making all this happen.

Happy federation!