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


Freedom of choice != Your choice of captor

I am happy to see that Nishant Kaushik (@NishantK)  has responded to the posts I've been doing on IdMaaS.  Nishant has strong ideas, having led product architecture and strategy within the Identity Management & Security Products group at Oracle for many years.  Nowadays he is with a startup called Identropy and writes the blog TalkingIdentity.

Nishant's main concern in his first post was that I've gone as far as I have without discussing the importance of governance controls.  I'm going to save this issue for my next piece, since Nishant also ended up in a spirited conversation with Craig Burton that is really worth following.  He wrote:

Craig Burton thinks that this vision, and the associated work Microsoft is doing on Windows Azure Active Directory (as described in this post by John Shewchuck) is “profoundly innovative”. I’ll be honest, I’m having a little trouble seeing what is so innovative about WAAD itself. How is the fact that becoming an Office 365 customer automatically gives you an AD in the cloud that you can build/attach other Azure applications to that different from Oracle saying that deploying a Fusion Application will include an OUD based identity store that the enterprise can also use for other applications? Apart from being in the cloud and therefore far easier to use in federated identity (SAML, OpenID, OAuth) scenarios. But I’ll wait to hear more before commenting any further (though John Fontana and others have already weighed in).

Craig Burton, as is his trademark, includes a few lightning bolts in his response:

Nishant must not have read my post very carefully. In my explanation of why Microsoft’s vision for IDMaaS is so profound, he failed to notice that I never once mentioned WAAD (Windows Azure Active Directory) or Office 365. There is a reason for that. I am not applauding Microsoft’s — or any other vendor’s — implementation of IDMaaS.

What is so profound about this announcement is that Microsoft is following Kim Cameron’s directives for building a Common Identity Framework for the planet, not just for a vendor.

In 2009 Kim Cameron, Reinhard Posch and Kai Rannenberg wrote Proposal for a Common Identity Framework: A User-Centric Identity Metasystem.

In section 5.4 of that document, the authors spell out the requirement for customer Freedom of Choice.

Freedom of Choice

Freedom of choice for both users and relying parties refers to choice of service operators they may wish to use as well as to the interoperability of the respective systems.

This definition is quite different than the freedom of choice Mr. Kaushik writes about in his blog piece. I posit that the Microsoft vision is so profound because it is built on a definition of Freedom of Choice that fits the above description and not where the customer is free to choose a particular captor.

And so I state again:

Freedom of Choice != Your Choice of Captor

Microsoft’s vision has changed the playing field. Any vendor building IdMaaS that is not meeting the Freedom of Choice requirements defined here is no longer in the game. That is profoundly innovative because this is truly a vision that benefits everyone — but mostly the customer.

With these remarks Craig starts really getting to the bare bones of what it takes to be trusted  to manage identity for enterprises and governments. 

It didn't take long before Nishant fired off a second dispatch accepting Craig's  points and clarifing what he saw as the real issues:

I want to be clear: I am not questioning the vision that Kim Cameron has started to talk about in his posts about IDMaaS (though I was bringing up a part – the governance controls – that I felt was missing and that I believe has a major impact on the architecture of a Common Identity Framework, as Craig called it). And I am completely in agreement with what Craig described in his original post in the section “Stop Gushing and Lay it Out for Me”.

Craig talks about how Freedom of Choice necessarily includes Freedom from Captor. He then says “This definition is quite different than the freedom of choice Mr. Kaushik writes about in his blog piece“.  I’m not sure why he thinks that, because what I am saying is exactly in line with what Craig and Kim are saying. It is what I have been saying since back in 2006 when I first started talking about the Identity Services Platform, which talks about the framework through which identity-enabled applications (essentially any application) consume identity from standardized services that can plug into any identity system or metasystem.

What I was pointing out was that John Shewchuck’s post about WAAD seemed to indicate a lack of Freedom of Choice in what Microsoft is rolling out, at least right now. Becoming an Office 365 customer would “automatically create a new Windows Azure Active Directory that is associated with the Office 365 account“, forcing you to store and manage your identities in WAAD.  It should simply ask for the domain from which users could use this, and you could simply point to the Google Apps domain of your company, sign up for WAAD if needed, or grant access to contractors/partners using whatever identity they choose (traditional AD environment, Facebook or Twitter accounts, even personal OpenIDs). By the way, the governance controls I was talking about are essential here in order to define the process of granting, managing and taking away access in this deployment model.

When I said “I’m having a little trouble seeing what is so innovative about WAAD itself”, I was pointing out my opinion that the details in John’s post did not seem to match up with the vision being outlined in Kim’s post, representing the kind of disconnect that Craig himself called out as a risk at various times in his post, but most notably in the section titled Caveats. I guess I’m not quite ready to make the leap that Microsoft’s work will line up Kim’s vision, and was calling out the disconnect I was seeing. And when Craig said “Microsoft is not only doing something innovative – but profoundly innovative”, I assumed he was talking about WAAD and related work, and not just referring to what Kim is talking about.

Nishant goes on to give more examples of how he thinks Office 365 could be implemented.  I won't discuss those at this point since I think we should save our implementation discussions for later.  First we need a more thorough conversation about what IdMaaS actually involves given all the changes that are impacting us.  It is these definitions that must lead to implementation considerations.  I hope Nishant will bear with me on this so we can continue the discussion begun so far.

I also want, in deference to Nishant and others who may have similar concerns, make a few remarks on what we have rolled out right now.  I want to be really clear that while I think we already do a number of things really well and in a robust way at very high scale, there are all kinds of things we still don't do that form an integral part of our vision for what must be done.  Anyone who says they can do all that is needed just doesn't, in my view, have a vision.

On the other hand, I hope we can steer clear of overly simplified recipies for what complicated offerings like Office 365 require as identity management.  For example, applications like Office need directories and places to store information about people in them, and nowhere is it written in stone that this should be done by sending realtime queries to dozens or thousands of systems.   Enterprise users want directory lookup that is as fast and reliable when served from the cloud as it is on premises.  And so on.  My point here is not to argue for one solution versus another, but to invite Nishant and others who may be interested to zero in on the broad set of requirements before getting overly committed to possible ways of meeting them.


Craig Burton on Microsoft's Identity Management as a Service

Craig Burton first achieved prominence as the Senior Vice President of Corporate Marketing and Development who drove Novell's innovation and market strategies in the days when it was aggressively turning computing upside down. Some years later he founded the Burton Group with Jamie Lewis.  Today he is a Distinguished Analyst for Kuppinger Cole, where he just published an intriguing response to the blogs John and I have been doing:  Microsoft is Finally Being Relevant.

For now I'll refrain from comment and just offer up the goods:

Microsoft is Finally Being Relevant
Surprise surprise. For the last few years it looked as if the battling business units and power struggles within Microsoft had all but rendered the company incapable of doing anything innovative or relevant. But clearly something has happened to change this lack of leadership and apparent stumbling in the dark. Microsoft is not only doing something innovative — but profoundly innovative.

In a dual post by Microsoft’s John Shewchuk and Kim Cameron, the announcement was made about what Kim Cameron alluded to at the KuppingerCole EIC in April — Identity Management as a Service (IDMaaS). This is not trivial, and does not suck. It ROCKS.
Why is Identity Management as a Service a Big Deal
From a technical perspective, the place where innovation really makes a difference is the place where the rubber meets the road — infrastructure. Infrastructure is not only fundamental—as it provides the technical framework and underpinning to support big change — but infrastructure is hard.

It’s also hard to get funded and hard to sell both outside and inside of companies that make infrastructure.

This is because there is little possibility of showing a direct ROI in core infrastructure investment. It takes vision and guts to invest in infrastructure.

Nobody wants to buy identity infrastructure. In fact no one should have to pay for identity infrastructure. It should be ubiquitous, work, and be free to everyone and controlled by no one. Infrastructure at this level is as fundamental as air. You don’t think about it, you don’t buy it; you just breathe it in and out and get on with the details.

Metaphorically, when it comes to the maturity of identity infrastructure today—we are all sucking on thin air from teeny tubes of infrastructure veneer connected to identity silos (Facebook Connect, Twitter, Federated Identity and so on.)

It’s much like the other core suite of protocols of the Internet — like TCP/IP. TCP/IP is free as far as a piece of software goes. No one ever pays for the transport anymore.

So should be the protocols and infrastructure for doing Identity Management.  With this announcement Microsoft is showing that it understands Identity Infrastructure is fundamental to everything in the hybrid world of social-mobile-cloud networking that we are stumbling towards.

Further, Microsoft is making it clear it understands that the current identity provider-centric world we live in now is broken and simply will not work for the future. Significant movement forward from this wretched state requires massive change — which is what Microsoft is proposing.

From a political and business perspective, Kim Cameron’s vision of a ubiquitous Identity Metasystem has somehow prevailed inside Microsoft and is starting to emerge. This is a big deal. Finally a company with lots of talent that has been wallowing from lack of leadership has stepped up and put a stake in the ground about Identity. Bravo!

Everybody else of significance that could be doing something significant with identity infrastructure — Google, Facebook, and Amazon for starters — are trapped in their current business models of trafficking your identity for short term profit. For each of them, the little piece they hold captive of your identity is the product by which they are making money. This is both short sighted and unsustainable.

Microsoft’s plan is much grander. Invest in the hard stuff, solve the really tough identity infrastructure problems across the board—simple, private, and scalable. By taking this high road, Microsoft is betting it can take the leadership role by increasing the size of the pie for other SaaS services and apps that organizations and individuals want and are willing to pay for. Much more visionary that continuing to fight over whatever crumb you can get based on the current broken model.

If Microsoft is allowed to pull this off, it is a good thing.
Stop Gushing and Lay it Out for Me
To understand the significance of IDMaaS, it’s useful to take a quick look at how identity management systems have evolved.

Figure 1 shows how identities started out being managed within the boundaries of a domain. Domain-based identity managed need hardly be mentioned here as it can’t possibly meet any of the requirements for identity management in today’s organizational environments. For its day, it worked and it was a good place to start.

Figure 1: Domain Contained Identity

Figure 2 illustrates the first generation of federated identity management systems. This is a powerful model and was a big step forward from the domain model. In this model there is a service provider that accepts claims from an identity provider. A person can then prove who they are to the identity provider and present claims to the service provider to assure proper access to services and resources. This model works when these a relatively small number of parties involved. But as soon as there a diverse number of parties, it quickly breaks down.

Figure 2: Identity Federation Model

Figure 3 shows the scenario with diverse people with diverse relationships with different IPs. When you add diverse and numerous types of devices — cell phones, tablets, laptops and so on — it even makes the case stronger as to why the current federated identity model is reaching its limits.


Figure 3: Diverse People and Devices

So if the Federated Identity model doesn’t work, what will? Figure 4 shows one school of thought were a single IP can somehow grow big enough and inclusive enough, it can manage all of the identity claims of all entities. This architecture is both frightening and poorly thought out. People and organizations need to have the freedom of choice of how their identities are managed and not be locked into an identity management silo of a single provider.

Figure 4: Omni Identity Provider

Figure 5 is another — simpler — graphic showing how a single organization could have federated relationships with multiple constituents. Again, this approach works to a point, but as soon as you consider the impact of the identity explosion brought on by — cloud computing, social computing, mobile computing, and the API economy — this approach simply won’t do the job.

Figure 5: Organization Federated to Many Constituents

Figure 6 then, shows the simplified notion of the IDMaaS architecture. Any number of organizations, constituents or entities can generate and consume claims through the service in the cloud.

Figure 6: Any Entity and Any Number of Entities

Of course Figure 6 doesn’t very effectively illustrate what the three black dots really mean. With the identity explosion we are talking about, the number of entities that are inevitable are several orders of magnitude bigger than anything we have even thought about up to this point.

We are in new territory, it is very unclear what is going to happen as a result all of this.

The fact that Microsoft seems to be acknowledging this fact and is working with vision to address the matter is highly encouraging.

We are not seeing this kind of vision — or anything close to it — from any other major vendor to date.
The biggest problem I see here is Microsoft itself. It isn’t like Microsoft has the reputation of always taking the high road to enhance technology to the benefit of all. To the contrary, Microsoft has the reputation of pretending to take the high road with an “embrace and extend-like” position while executing an exacting and calculating “embrace and execute” practice. Microsoft has become the arrogant elephant to dance with that IBM once was. Microsoft’s past is going to be difficult to shed and it will be a significant effort to convince others that the elephant won’t trample on everyone when it gets the chance.

Figure 7: The New Microsoft?

(Source: Craig Burton, drawn on the iPhone with Autodesk SketchBook Pro)

So the tough questions are:

  • Can Microsoft really execute on such a brave direction?
  • Will Microsoft follow up on allowing true “Freedom of Choice” for the customer? (Think interoperability. i.e. IDMaaS from any vendor, not just MSFT)
  • Will the RESTful implementation be usable?
  • Can the technology transcend the limitations of Kerberos and LDAP as it moves Active Directory to the cloud?


My explanation is a simplified one, but if you study it a bit, you will start to see where Microsoft is going.

In short, the vision of an Identity Metasystem based on Identity Management as a Service is brilliant thinking.

The proof will be found in how Microsoft executes.

There is a lot to work out here to show if this can really work. But I believe it can happen. Microsoft is in a good position to garner the expertise to give us this first implementation so organizations and people can start to vet the idea and see if this can really fly.

I will be anxious to watch carefully at the progress of this direction.

I don't mind taking a few knocks from Craig, and don't think this would be the place to respond to them, even if I do think that the interoperable claims based identity technology we have been building and shipping for the last few years is the rocket fuel needed to “transcend the limitations of Kerberos and LDAP as we move Active Directory to the cloud” – one of his main concerns.

But why quibble?  Craig really gets what's important.  I like the fact that he takes the time to explain why Identity Management as a Service really is a big deal.  I suspect part of what he is saying is that it dwarfs the incremental changes we have seen over the last few years because it will impact every mainstream technology.

Craig's points about why infrastructure is hard are all golden, as is his wonderfully simple statement that “the current identity provider-centric world we live in now is broken and simply will not work for the future.”

As for the tough questions, execution can only be judged by looking at what is shipped and how it evolves over time.  I'd like to take up the more general, IdMaaS-related questions in upcoming posts.  John will be talking in his posts specifically about our RESTful implementation and providing readers with access so they can judge for themselves and give us feedback.  At a practical level, we will be making things available incrementally in cloud time, adding breadth and depth as we go on.  This whole aspect of cloud innovation makes it hugely exciting.

By the way, I love Craig's elephant – I only wish I could dance so well, metaphorically at least.  I also love his graphics: he improved and extended the amateur ones I used in my European Identity and Cloud Conference keynote.  So if it's OK with him, I'm going to pitch my own and go with his in my upcoming posts.  Thanks Craig.


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.


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.


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!

Using Consumer Identities for Business Interactions

Mike Jones writes about an “identity mashup” that drives home a really important lesson:  the organizational and technical walls that used to stand in the way of Internet business are dissolving before our very eyes.  The change agent is the power of claims.  The mashup Mike describes crosses boundaries in many dimensions at once:

  • between industries (medical, financial, technical)
  • between organizations (Medtronic, PayPal, Southworks, Microsoft)
  • between protocols (OpenID and SAML)
  • between computing platforms (Windows and Linux)
  • between software products (Windows Identity Foundation, DotNetOpenAuth, SimpleSAMLphp)
  • between identity requirements (ranging from strong identity verification to anonymous comment)

This is a super-concrete demonstration of the progress being made on the “Identity Metasystem” so many of us in the industry have been working on.   My favorite word in Mike's piece is “quickly”, to which I have taken the liberty of adding my own emphasis:

Medtronic, PayPal, Southworks, and Microsoft recently worked together to demonstrate the ability for people to use their PayPal identities for participating in a Medtronic medical device trial, rather than having to create yet another username and password. Furthermore, the demo showed the use of verified claims, where the name, address, birth date, and gender claims provided by PayPal are relied upon by Medtronic and its partners as being sufficiently authoritative to sign people up for the trial and ship them the equipment. I showed this to many of you at the most recent Internet Identity Workshop.

From a technology point of view, this was a multi-protocol federation using OpenID and WS-Federation – OpenID for the PayPal identities and WS-Federation between Medtronic and two relying parties (one for ordering the equipment and one for anonymously recording opinions about the trial). It was also multi-platform, with the Medtronic STS running on Windows and using the Windows Identity Foundation (WIF) and DotNetOpenAuth, the equipment ordering site running on Linux and using simpleSAMLphp, and the opinions site running on Windows and also using WIF. A diagram of the scenario flows is as follows:

Identity Mash-Up Diagram

We called the demo an “identity mash-up” because Medtronic constructed a identity for the user containing both claims that came from the original PayPal identity and claims it added (“mashed-up”) to form a new, composite identity. And yet, access to this new identity was always through the PayPal identity. You can read more about the demo on the Interoperability @ Microsoft blog, including viewing a video of the demo. Southworks also made the documentation and code for the multi-protocol STS available.

I’ll close by thanking the teams at PayPal, Medtronic, and Southworks for coming together to produce this demo. They were all enthusiastic about using consumer identities for Medtronic’s business scenario and pitched in together to quickly make it happen.


National Strategy for Trusted Identities in Cyberspace

Friday saw what I think is a historic post by Howard Schmidt on The Whitehouse Blog:

“Today, I am pleased to announce the latest step in moving our Nation forward in securing our cyberspace with the release of the draft National Strategy for Trusted Identities in Cyberspace (NSTIC).  This first draft of NSTIC was developed in collaboration with key government agencies, business leaders and privacy advocates. What has emerged is a blueprint to reduce cybersecurity vulnerabilities and improve online privacy protections through the use of trusted digital identities. “

I say the current draft is historic because of the grasp of identity issues it achieves

At the core of the document is a recognition that we need a solution supporting privacy-enhancing technologies and built by harnessing a user-centric Identity Ecosystem offering citizens and private enterprise plenty of choice.  

Finally we have before us a proposal that can move society forward in  protecting individual privacy and simultaneously create a secure and trustworthy infrastructure with enough protections to be resistant to insider attacks.  

Further, the work appears to have support from multiple government agencies – the Department of Homeland Security was a key partner in its creation. 

Here are the guiding principles (beginning page 8):

  • Identity solutions will be secure and resilient
  • Identity solutions will be interoperable
  • Identity solutions will be privacy enhancing and voluntary for the public
  • Identity solutions will be cost-effective and easy to use

Let's start with the final “s” on the word “solutions” – a major achievement.  The authors understand society needs a spectrum of approaches suitable for different use cases but fitting within a common interoperable framework – what I and others have called an identity metasystem. 

The report embraces the need for anonymous access as well as that for strong identification.  It stands firmly in favor of minimal disclosure.  The authors call out the requirement that solutions be privacy enhancing and voluntary for the public, rather than attempting to ram something bureaucratic down peoples’ throats.  And they are fully cognisant of the practicality and usability requirements for the initiative to be successful.  A few years ago I would not have believed this kind of progress would be possible.

Nor is the report just a theoretical treatment devoid of concrete proposals.  The section on “Commitment to Action” includes:

  • Designate a federal agency to lead the public/private sector efforts to advance the vision
  • Develop a shared, comprehensive public/private sector implementation plan
  • Accelerate the expansion of government services, pilots and policies that align with the identity ecosystem
  • Work to implement enhanced privacy protections
  • Coordinate the development and refinement of risk management and interoperability standards
  • Address liability concerns of service providers and individuals
  • Perform outreach and awareness across all stakeholders
  • Continue collaborating in international efforts
  • Identify other means to drive adoption

Readers should dive into the report – it is in a draft stage and “Public ideas and recommendations to further refine this Strategy are encouraged.”  

A number of people and organizations in the identity world have participated in getting this right, working closely with policy thinkers and those leading this initiative in government.  I don't hesitate to say that congratulations are due all round for getting this effort off to such a good start.

We can expect suggestions to be made strengthening various aspects of the report – mainly in terms of making it more internally consistent.  

For example, the report contains good vignettes about minimal disclosure and the use of claims to gain access to resources.  Yet it also retains the traditional notion that authentication is dependent on identification.  What is meant by identification?  Many will assume it means “unique identification” in the old-fashioned sense of associating someone with an identifier.  That doesn't jive with the notion of minimal disclosure present throughout the report.  Why? For many purposes association with an identifier is over-identification or unhelpful, and a simple proof of some set of claims would suffice to control access.  

But these refinements can be made fairly easily.  The real challenge will be to actually live up to the guiding principles as we move from high level statements to a widely deployed system – making it truly secure, resilient and privacy enhancing.  These are guiding principles we can use to measure our success and help select between alternatives.


Vittorio Bertocci brings it all together for us

My good friend Vittorio is one of the most gifted technology presenters – an artist!  But he's also a talented engineer and architect – the rat!  Vittorio has been a great supporter of minimal disclosure.  I want to point you to his nice little guide to the minimal disclosure videos…  None of Vittorio's real-time cartoons this time, but I hope they're coming…

“As is customary by now, the IdElement is providing extensive coverage of the U-Prove CTP:

Announcing Microsoft’s U-Prove Community Technical PreviewStefan describes U-Prove, some typical scenarios where traditional technologies fall short while U-Prove provides a solution, and a summary of what we are releasing.  image
image U-Prove CTP: a Developers’ PerspectiveChristian and Greg explore the CTP, clarifying U-Prove’s role in the Identity Metasystem and describing how ADFSv2, WIF and CardSpace have been extended in the CTP for accommodating U-Prove’s functionality.
Deep Dive into U-Prove Cryptographic protocolsA feast for cryptographers and mathematicians! in this video Stefan describes in details the cryptography behind U-Prove’s algorithm. Not for the faint of heart!    image

“I know that my good friend Felix felt strongly about U-Prove: I am so glad that we can finally share this! Congratulations to Stefan, Christian, Greg and everybody in the IDA division that made this happen :-)


- U-Prove CTP

- U-Prove SDK C# edition or Java edition