Let’s find a more accurate term than ‘Self-Sovereign Identity’

I really liked Timothy Ruff‘s recent post: 7 Myths of Self-Sovereign Identity. 

I was especially glad to see him confirming my observation that the term “Self-Sovereign”  seems to create a lot more confusion than understanding.  He makes some excellent points in his post, but it left me scratching my head that such a smart guy has to spend his time busting myths that are really just the result of lazy naming.  Then again, should we be surprised?  Lazy naming is rampant amongst us technologists, making our lives difficult at every turn…

Timothy writes:

I recently attended the ID2020 event in New York, where some of the biggest players in identity were on hand, working toward fulfilling the United Nations’ Sustainable Development Goal 16.9: Identity for all by 2030. It was an excellent event, lots of energy, very professional, and serious about moving the needle on this BHAG (big, hairy, audacious goal).

We heard first-hand examples of the pains caused by broken identity systems around the world, some of which were truly heartbreaking. Most of us take for granted that we can prove things about ourselves, unaware that over a billion people cannot, leaving them unable to obtain desirable work or advanced education, open a bank account, hold title to property, or even travel. As noted by the World Bank’s ID4D, identity is a prerequisite to financial inclusion, and financial inclusion is a big part of solving poverty.

That means improving identity will reduce poverty, not to mention what it could do for human trafficking. Refugees bring another troubling identity dilemma where the need is critical, and where we are commencing efforts through our partnership with iRespond.

The Culprit

Several times throughout the event, Self-Sovereign Identity (SSI) was discussed as a new and potentially big part of the solution. While there was clearly hope, there was also skepticism that, in my opinion, stems from misperceptions about what SSI really is and is not.

If SSI really was what these skeptics thought, I wouldn’t favor it either. And if they knew what SSI really is, I think they’d embrace it wholeheartedly.

The perception problem begins with the very term, “self-sovereign.”

At one point on the main stage, the venerable Kim Cameron, Microsoft’s Principal Identity Architect and author of the seminal 7 Laws of Identity, quipped:

“The term ‘self-sovereign’ identity makes me think of hillbillies on a survivalist kick.”

Kim went on to clarify that he is strongly in favor of SSI, he just dislikes the term and the negative perceptions it conjures up.

Me, too.

Self-sovereign identity is not a great term — for lots of reasons — but until we have a better one, (“decentralized identity” is a serious candidate) let’s clarify the one we’ve got.

I guess it’s OK to postpone the search for a better term (and no, “decentralized identity” isn’t an answer except amongst identerati!) while people read the 7 Myths of Self-Sovereign Identity –  but not for much longer, since the myths resulting from the awful failed name may be contagious:

  1. Self-sovereign means self-attested.
  2. SSI attempts to reduce government’s power over an identity owner.
  3. SSI creates a national or “universal ID” credential.
  4. SSI gives absolute control over identity.
  5. There’s a “main” issuer of credentials.
  6. There’s a built-in method of authenticating.
  7. User-centric identity is the same as SSI.

All the points Timothy makes (except his definition of user-centric identity – my views were explained here in 2008 in –  er – ‘terse prose’, rather like espresso) should help convince people who understand identity that SSI is worth looking at.

But the first point stands out as a basic stake in the ground.

Decentralized identity systems must allow us to present claims we make about ourselves (now called self-attested), but must allow us to present claims that express things others say about us too.

Governments offer an excellent example.  Governments make laws.  For those of us in contact with civilization our legal identities are key to important aspects of our lives – like signing contracts or crossing borders.  So our identity systems must allow us to present legal, verifiable, government-backed claims whenever it is appropriate and we agree to do so.

Writing this, I get a strange déjà-vue pointing out that “Just because some tables are green, it doesn’t mean that all tables are green.”  Must we really argue that just because some claims should be self-issued, that doesn’t mean all claims should be self-issued?

The principle is self-evident.  But I’ll be posting at length about the ways we can combine user-control, self-issued claims and verified claims to create the next big mainstream identity technology.

Meanwhile let’s explain to our colleagues who don’t have the opportunity to interact with real customers that  “Self-Sovereign Identity” has been test-marketed and bombed.  Let’s start brain-storming a really good name for the true social network that is controlled by its users and allows us to present claims from whoever we want.

Tim Cook knocks it home: GDPR will impact the whole world

In my last keynote for the European Identity Conference I described how the Laws of Identity, that were increasingly flaunted by the Internet giants during the decade following their articulation, culminated in sharp and rigorous pushback by the European Union in the form of the GDPR – just as the Laws had predicted would happen.  In a word, the GDPR turned laws of computer science into legal constructs.

I also explained how crucially important this was:  that GDPR would press the digital reset button not just on Europe, but on the entire world.  I argued it would usher in a whole new “user-in-control” era of technology, one symptom of which would be the rise of the decentralized identity initiative leveraging blockchain.   

Since then one recurring question people have had is why I thought the GDPR regulation, which only applies in Europe, would have a broad international impact, since “things are so different in the US”.

There are two main dynamics at play:

First, the same issues that led the European Union to create the GDPR impact all societies.  There are countless people in America and elsewhere who have lost all confidence in the Internet giants to protect their data or their interests.  This has already given rise to social sentiment that is motivating political leaders to get on the right side of history – introducing data privacy legislation.  And in the discussion around what this will be, the GDPR has set the bar and established expectations that make it easy to lead campaigns describing what bad legislation is missing.

Second, all sentient beings within the internet companies understand the fundamental nature of the internet:  it is world-wide and cannot be bifurcated.  Building reliable, defensible services that behave differently in Europe and North America is a no-win proposition.  Technology companies have lobbied for international harmonization of regulations for many years.  Over time practicality will push those who choose to bifurcate and ignore the internet’s fundamental nature back to this principle.

Microsoft, which operates a number of giant internet services, saw from the beginning that the GDPR was consistent with humanistic aspirations and that formalizing protections in the ways specified by the GDPR was simply a best practice that should apply to every service we operate everywhere.  Satya Nadella has consistently supported not only the GDPR, but the citizen’s right to identity and privacy, and beyond that, the whole principle of user-centric computing and giving people control of and access to their data.

But those with doubts about the world-wide impact of GDPR can now also read carefully the truly remarkable speech given Wednesday by Apple’s Tim Cook. He makes it absolutely clear that Apple sees the GDPR as a fundamental technology building-block and fully understands that the EU has effectively pushed the digital reset button world-wide – and that this is hugely positive.

Good morning.
It is an honor to be here with you today in this grand hall, a room that represents what is possible when people of different backgrounds, histories and philosophies come together to build something bigger than themselves.

I am deeply grateful to our hosts. I want to recognize Ventsislav Karadjov for his service and leadership. And it’s a true privilege to be introduced by his co-host, a statesman I admire greatly, Giovanni Butarelli.

Now Italy has produced more than its share of great leaders and public servants. Machiavelli taught us how leaders can get away with evil deeds, and Dante showed us what happens when they get caught.

Giovanni has done something very different. Through his values, his dedication, his thoughtful work, Giovanni, his predecessor Peter Hustinx — and all of you — have set an example for the world. We are deeply grateful.

We need you to keep making progress — now more than ever. Because these are transformative times. Around the world, from Copenhagen to Chennai to Cupertino, new technologies are driving breakthroughs in humanity’s greatest common projects. From preventing and fighting disease, to curbing the effects of climate change, to ensuring every person has access to information and economic opportunity.

At the same time, we see vividly — painfully — how technology can harm rather than help. Platforms and algorithms that promised to improve our lives can actually magnify our worst human tendencies. Rogue actors and even governments have taken advantage of user trust to deepen divisions, incite violence and even undermine our shared sense of what is true and what is false.

This crisis is real. It is not imagined, or exaggerated, or crazy. And those of us who believe in technology’s potential for good must not shrink from this moment.

Now, more than ever — as leaders of governments, as decision-makers in business and as citizens — we must ask ourselves a fundamental question: What kind of world do we want to live in?

I’m here today because we hope to work with you as partners in answering this question.

At Apple, we are optimistic about technology’s awesome potential for good. But we know that it won’t happen on its own. Every day, we work to infuse the devices we make with the humanity that makes us. As I’ve said before, technology is capable of doing great things. But it doesn’t want to do great things. It doesn’t want anything. That part takes all of us.

That’s why I believe that our missions are so closely aligned. As Giovanni puts it, we must act to ensure that technology is designed and developed to serve humankind, and not the other way around.

We at Apple believe that privacy is a fundamental human right. But we also recognize that not everyone sees things as we do. In a way, the desire to put profits over privacy is nothing new.

As far back as 1890, future Supreme Court Justice Louis Brandeis published an article in the Harvard Law Review, making the case for a “Right to Privacy” in the United States.

He warned: “Gossip is no longer the resource of the idle and of the vicious, but has become a trade.”

Today that trade has exploded into a data industrial complex. Our own information, from the everyday to the deeply personal, is being weaponized against us with military efficiency.

Every day, billions of dollars change hands and countless decisions are made on the basis of our likes and dislikes, our friends and families, our relationships and conversations, our wishes and fears, our hopes and dreams.

These scraps of data, each one harmless enough on its own, are carefully assembled, synthesized, traded and sold.

Taken to its extreme, this process creates an enduring digital profile and lets companies know you better than you may know yourself. Your profile is then run through algorithms that can serve up increasingly extreme content, pounding our harmless preferences into hardened convictions. If green is your favorite color, you may find yourself reading a lot of articles — or watching a lot of videos — about the insidious threat from people who like orange.

In the news almost every day, we bear witness to the harmful, even deadly, effects of these narrowed worldviews.

We shouldn’t sugarcoat the consequences. This is surveillance. And these stockpiles of personal data serve only to enrich the companies that collect them.

This should make us very uncomfortable. It should unsettle us. And it illustrates the importance of our shared work and the challenges still ahead of us.

Fortunately this year you’ve shown the world that good policy and political will can come together to protect the rights of everyone. We should celebrate the transformative work of the European institutions tasked with the successful implementation of the GDPR. We also celebrate the new steps taken, not only here in Europe, but around the world. In Singapore, Japan, Brazil, New Zealand and many more nations, regulators are asking tough questions and crafting effective reforms.

It is time for the rest of the world — including my home country — to follow your lead.

We at Apple are in full support of a comprehensive federal privacy law in the United States. There and everywhere, it should be rooted in four essential rights: First, the right to have personal data minimized. Companies should challenge themselves to de-identify customer data — or not to collect it in the first place. Second, the right to knowledge. Users should always know what data is being collected and what it is being collected for. This is the only way to empower users to decide what collection is legitimate and what isn’t. Anything less is a sham. Third, the right to access. Companies should recognize that data belongs to users, and we should all make it easy for users to get a copy of, correct and delete their personal data. And fourth, the right to security. Security is foundational to trust and all other privacy rights.

Now, there are those who would prefer I hadn’t said all of that. Some oppose any form of privacy legislation. Others will endorse reform in public, and then resist and undermine it behind closed doors.

They may say to you, “Our companies will never achieve technology’s true potential if they are constrained with privacy regulation.” But this notion isn’t just wrong, it is destructive.

Technology’s potential is, and always must be, rooted in the faith people have in it, in the optimism and creativity that it stirs in the hearts of individuals, in its promise and capacity to make the world a better place.

It’s time to face facts. We will never achieve technology’s true potential without the full faith and confidence of the people who use it.

At Apple, respect for privacy — and a healthy suspicion of authority — have always been in our bloodstream. Our first computers were built by misfits, tinkerers and rebels — not in a laboratory or a board room, but in a suburban garage. We introduced the Macintosh with a famous TV ad channeling George Orwell’s 1984 — a warning of what can happen when technology becomes a tool of power and loses touch with humanity.

And way back in 2010, Steve Jobs said in no uncertain terms: “Privacy means people know what they’re signing up for, in plain language, and repeatedly.”

It’s worth remembering the foresight and courage it took to make that statement. When we designed this device we knew it could put more personal data in your pocket than most of us keep in our homes. And there was enormous pressure on Steve and Apple to bend our values and to freely share this information. But we refused to compromise. In fact, we’ve only deepened our commitment in the decade since.

From hardware breakthroughs that encrypt fingerprints and faces securely — and only — on your device, to simple and powerful notifications that make clear to every user precisely what they’re sharing and when they are sharing it.

We aren’t absolutists, and we don’t claim to have all the answers. Instead, we always try to return to that simple question: What kind of world do we want to live in?

At every stage of the creative process, then and now, we engage in an open, honest and robust ethical debate about the products we make and the impact they will have. That’s just a part of our culture.

We don’t do it because we have to. We do it because we ought to. The values behind our products are as important to us as any feature.

We understand that the dangers are real — from cyber-criminals to rogue nation states. We’re not willing to leave our users to fend for themselves. And we’ve shown we’ll defend those principles when challenged.

Those values — that commitment to thoughtful debate and transparency — they’re only going to get more important. As progress speeds up, these things should continue to ground us and connect us, first and foremost, to the people we serve.

Artificial Intelligence is one area I think a lot about. Clearly it’s on the minds of many of my peers as well.

At its core, this technology promises to learn from people individually to benefit us all. Yet advancing AI by collecting huge personal profiles is laziness, not efficiency. For artificial intelligence to be truly smart, it must respect human values, including privacy.

If we get this wrong, the dangers are profound.

We can achieve both great artificial intelligence and great privacy standards. It’s not only a possibility, it is a responsibility.

In the pursuit of artificial intelligence, we should not sacrifice the humanity, creativity and ingenuity that define our human intelligence.

And at Apple, we never will.

In the mid-19th century, the great American writer Henry David Thoreau found himself so fed up with the pace and change of industrial society that he moved to a cabin in the woods by Walden Pond.

Call it the first digital cleanse.

Yet even there, where he hoped to find a bit of peace, he could hear a distant clatter and whistle of a steam engine passing by. “We do not ride on the railroad,” he said. “It rides upon us.”

Those of us who are fortunate enough to work in technology have an enormous responsibility.

It is not to please every grumpy Thoreau out there. That’s an unreasonable standard, and we’ll never meet it.

We are responsible, however, for recognizing that the devices we make and the platforms we build have real, lasting, even permanent effects on the individuals and communities who use them.

We must never stop asking ourselves, what kind of world do we want to live in?

The answer to that question must not be an afterthought, it should be our primary concern.

We at Apple can — and do — provide the very best to our users while treating their most personal data like the precious cargo that it is. And if we can do it, then everyone can do it.

Fortunately, we have your example before us.

Thank you for your work, for your commitment to the possibility of human-centered technology, and for your firm belief that our best days are still ahead of us.

Thank you very much.

 

That this speech represents a really commendable watershed moment is best demonstrated by its low point:  Tim’s “embellishment” of Apple’s stance towards privacy back in 2010.

In case facts are still of interest, I’ll quote from an article in CSO magazine that made it to the front page of digg.com in 2010:

A Microsoft identity guru bit Apple and smacked Google over mobile privacy policies. Once upon a time, before working for Microsoft, this same man took MS to task for breaking the Laws of Identity.  Kim Cameron, Microsoft’s Chief Identity Architect in the Identity and Security Division, said of Apple, “If privacy isn’t dead, Apple is now amongst those trying to bury it alive.”

Collection and Use of Non-Personal Information

We also collect non-personal information – data in a form that does not permit direct association with any specific individual.  We may collect, use, transfer, and disclose non-personal information for any purpose. The following are some examples of non-personal information that we collect and how we may use it:

· We may collect information such as occupation, language, zip code, area code, unique device identifier, location, and the time zone where an Apple product is used so that we can better understand customer behavior and improve our products, services, and advertising.

The MS identity guru put the smack down not only on Apple, but also on Google, writing in his blog, “Maintaining that a personal device fingerprint has ‘no direct association with any specific individual’ is unbelievably specious in 2010 – and even more ludicrous than it used to be now that Google and others have collected the information to build giant centralized databases linking phone MAC addresses to house addresses. And – big surprise – my iPhone, at least, came bundled with Google’s location service.”

Apple’s new policy is also under fire from two Congressmen who gave Apple until July 12th to respond. Reps. Edward J. Markey (D-Mass.) and Joe Barton (R-Texas) sent a letter to Apple CEO Steve Jobs asking for answers about Apple gathering location information on its customers.

Cameron seems to believe location based identifiers and these changes of privacy policies may open the eyes of some people to the, “new world-wide databases linking device identifiers and home addresses.”

 

For the record, the only error in the CSO article is that I actually took Microsoft to task for having broken the Laws of Identity while I worked at Microsoft.  And the main reason I stayed at Microsoft is because they listened.

By the way, I’ve never admitted this before, but I was so peaved by Apple’s assertion that they could release my identifier and location to anyone they wanted, that I took my iPhone, which until then I had liked, put it on my driveway, and squished it into aluminum foil by driving over it several times.

In light of Tim Cook’s terrific speech, I think I will probably get one again.  Thanks, Tim, for pressing that reset button.

The Laws of Identity on the Blockchain

These days people tend to ask me two main questions: What do I think about Blockchain identity? And what does it change in the Laws of Identity? In my keynote at Kuupinger Cole’s 2018 European Identity and Cloud Conference I took the opportunity to answer both.

Of course I had no choice about that. Neither question can be discussed without considering the other. Identity on the Blockchain must be subject to the Laws of Identity. In fact, the GDPR codifies a number of the Laws which originated as computer science into the basic legal fabric of Europe – with an impact on technology that I think will be world-wide. I’ll be discussing the way GDPR will help drive blockchain identity in more detail going forward. Meanwhile, the video of my initial presentation on this subject is here:


The Laws of Identity on the Blockchain

EIC 2016 in Munich

Like the other attendees, I very much enjoyed the Kuppinger Cole European Identity and Cloud Conference (EIC) 2016 held in Munich in May.  The conference is growing by leaps and bounds but still provides plenty of opportunity for interaction and exchange of information.   Run by Europeans for Europeans, it provides great insights for those of us from outside the EU and gives us a better understanding of the hot-topics in the European IT community.

Again I’ll just share tweets hoping it will give a feel for what transpired.  My slightly personal keynote on The Cloud is Rewiring the World – What does it Mean for Identity and my presentation The Future of AD in the Days of Azure AD  are posted courtesy of Kuppinger Cole.

Note: Originally a “storify” recapitulation of twitter traffic appeared here, but “storify” disappeared and nuked everyone’s content on May 16th 2018.

Keynote on Laws of Identity at IIW

This year Phil Windley asked me to give “the opening keynote” at the Internet Identity Workshop (IIW) conference in Mountain View CA.  I was a little skeptical…

If you haven’t attended, the IIW is the perfect “un-conference.  It has no keynotes or panels, it’s about getting stuff done.”  Besides that, everyone doing anything leading edge in digital identity attends as often as they can – it’s a place to collaborate and a Who’s Who of experts.  Why keynote them?

But Phil explained there were many attending the conference who were new to Identity and didn’t have any context or way to grasp what people working in the area had already been through.  So he asked me to talk about “The Laws of Identity 10 years later”.

The “later” was intriguing.  It gave me the opportunity to share what we had learned 10 years ago, and then begin to discuss what we have learned since.  I’ve been wanting the chance to get a conversation going about that, so I agreed to take the risk of breaking the no-keynote taboo.

As the day of the conference approached, I saw there was no mention of a keynote in the conference materials, and began to dread being booed out of Mountain View for doing a keynote in a sacred place…  Anyway I forsook slides (what a liberating experience!) and just jotted down a few notes in case the keynote (an un-keynote?) actually took place.  Which it did – and those in the audience were more than gracious.  It led to great conversations with people approaching identity in new ways, including conversations about one of my big new interests:  blockchain.

I thought the best way to share the experience is by sharing the Kim Cameron IIW twitter feed.  So here goes:

Lost in translation

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

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

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

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

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

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

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

A look inside AzureAD B2C

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

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

The Why

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

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

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

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

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

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

The what

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

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

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

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

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

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

The How

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

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

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

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

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

Azure Active Directory B2C is now in public preview

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

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

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

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

Introducing Microsoft Azure Active Directory B2C

By Stuart Kwan

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

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

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

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

How it works

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

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

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

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

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

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

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

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

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

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

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

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

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

Configuring Azure AD B2C

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

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

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

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

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

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

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

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

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

Then the sign up experience looks like this:

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

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

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

Building an app that uses B2C

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

GET /prosewareb2c.onmicrosoft.com/oauth2/v2.0/authorize?
response_type=id_token&
client_id=9bdade37-a70b-4eee-ae7a-b38e2c8a1416&
redirect_uri=https://proseware.skwantoso.com/auth/openid/return&
response_mode=form_post&
nonce= WzRMD9LC95HeHvDz&
scope=openid&
p=b2c_1_standardsignup
HTTP/1.1

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

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

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IklkVG9rZW5TaWduaW5nS2V5Q29udGFpbmVyIn0.eyJleHAiOjE0NDIxMjc2OTYsIm5iZiI6MTQ0MjEyNDA5NiwidmVyIjoiMS4wIiwiaXNzIjoiaHR0cHM6Ly9sb2dpbi5taWNyb3NvZnRvbmxpbmUuY29tL2Q3YzM3N2RiLWY2MDktNDFmMy1iZTA5LTJiNzNkZWZkNDhhMC92Mi4wLyIsImFjciI6ImIyY18xX3N0YW5kYXJkc2lnbnVwIiwic3ViIjoiTm90IHN1cHBvcnRlZCBjdXJyZW50bHkuIFVzZSBvaWQgY2xhaW0uIiwiYXVkIjoiOWJkYWRlMzctYTcwYi00ZWVlLWFlN2EtYjM4ZTJjOGExNDE2Iiwibm9uY2UiOiJXelJNRDlMQzk1SGVIdkR6IiwiaWF0IjoxNDQyMTI0MDk2LCJhdXRoX3RpbWUiOjE0NDIxMjQwOTYsIm9pZCI6IjJjNzVkMWQ1LTU5YWYtNDc5Yi1hOWMzLWQ4NDFmZjI5ODIxNiIsImVtYWlscyI6WyJza3dhbkBtaWNyb3NvZnQuY29tIl0sImlkcCI6ImxvY2FsQWNjb3VudEF1dGhlbnRpY2F0aW9uIiwibmFtZSI6IlN0dWFydCBLd2FuIiwiZXh0ZW5zaW9uX01lbWJlcnNoaXBOdW1iZXIiOiIxMjM0IiwiZXh0ZW5zaW9uX09mZmVyaW5nVHlwZSI6IjEifQ.cinNfuoMCU4A2ZeeHBKLxAuc8B7UPKwd9sKngxQO8jy19ky3cAHhTJljO0KL7oQ1P5yMFQYs9i4hAun3mmL5hPyC3N7skjU9R0rYl91Ekk7QTlrYgDpGDp5uCF7eA-iWQr0Bmw8oUTYGpjrKfuQP2x8DFxiGgmFqkqz0a20-oy1R6Qr9PaSzr2r8KtjplPX97ADerKIBpdTeLRPmKILWqEDKzoG-bU40LULvPRdvA4yh4nlhRhn4CNUmjZfMWnBcCR3I6jBPl2M3qHQ10DoNXNe2qzL8GalzuMYNnG92OrUppZ5hmXRUXW9yrIRRzDGcERfRyrbyFuYPfu1JJBSTCA

Decoding the id_token from the response yields:

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

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

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

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

How much will it cost?

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

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

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

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

What’s next

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

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

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

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

Please write us

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

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

 

Yes to SCIM. Yes to Graph.

Today Alex Simons, Director of Program Management for Active Directory, posted the links to the Developer Preview of Windows Azure Active Directory.  Another milestone.

I'll write about the release in my next post.  Today, since the Developer Preview focuses a lot of attention on our Graph API, I thought it would be a good idea to respond first to the discussion that has been taking place on Twitter about the relationship between the Graph API and SCIM (Simple Cloud Identity Management).

Since the River of Tweets flows without beginning or end, I'll share some of the conversation for those who had other things to do:

@NishantK: @travisspencer IMO, @johnshew’s posts talk about SaaS connecting to WAAD using Graph API (read, not prov) @IdentityMonk @JohnFontana

@travisspencer: @NishantK Check out @vibronet’s TechEd Europe talk on @ch9. It really sounded like provisioning /cc @johnshew @IdentityMonk @JohnFontana

@travisspencer: @NishantK But if it’s SaaS reading and/or writing, then I agree, it’s not provisioning /cc @johnshew @IdentityMonk @JohnFontana

@travisspencer: @NishantK But even read/write access by SaaS *could* be done w/ SCIM if it did everything MS needs /cc @johnshew @IdentityMonk @JohnFontana

@NishantK: @travisspencer That part I agree with. I previously asked about conflict/overlap of Graph API with SCIM @johnshew @IdentityMonk @JohnFontana

@IdentityMonk: @travisspencer @NishantK @johnshew @JohnFontana check slide 33 of SIA322 it is really creating new users

@IdentityMonk: @NishantK @travisspencer @johnshew @JohnFontana it is JSON vs XML over HTTP… as often, MS is doing the same as standards with its own

@travisspencer: @IdentityMonk They had to ship, so it’s NP. Now, bring those ideas & reqs to IETF & let’s get 1 std for all @NishantK @johnshew @JohnFontana

@NishantK: @IdentityMonk But isn’t that slide talking about creating users in WAAD (not prov to SF or Webex)? @travisspencer @johnshew @JohnFontana

@IdentityMonk: @NishantK @travisspencer @johnshew @JohnFontana indeed. But its like they re one step of 2nd phase. What are your partners position on that?

@IdentityMonk: @travisspencer @NishantK @johnshew @JohnFontana I hope SCIM will not face a #LetTheWookieWin situation

@NishantK: @johnshew @IdentityMonk @travisspencer @JohnFontana Not assuming anything about WAAD. Wondering about overlap between SCIM & Open Graph API

Given these concerns, let me explain what I see as the relationship between SCIM and the Graph API.

What is SCIM?

All the SCIM documents begin with a commendably unambiguous statement of what it is:

The Simple Cloud Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns of exchanging this schema using standard protocols. In essence, make it fast, cheap and easy to move users in to, out of and around the cloud. [Kim: emphasis is mine]

I support this goal. Further, I like the concept of spec writers being crisp about the essence of what they are doing: “Make it fast, cheap and easy to move users in to, out of and around the cloud”.  For this type of spec to be useful we need it to be as widely adopted as possible, and that means keeping it constrained, focussed and simple enough that everyone chooses to implement it.

I think the SCIM authors have done important work to date.  I have no comments on the specifics of the protocol or schema at this point – I assume those will continue to be worked out in accordance with the spec's “essence statement” and be vetted by a broad group of players now that SCIM is on a track towards standardization.  Microsoft will try to help move this forward:  Tony Nadalin will be attending the next SCIM meeting in Vancouver on our behalf.

Meanwhile, what is “the Graph”? 

Given that SCIM's role is clear, let's turn to the question of how it relates to a “Graph API”.  

Why does our thinking focus on a Graph API in addition to a provisioning protocol like SCIM?  There are two answers.

Let's start with the theoretical one.  It is  because of the central importance of graph technology in being able to manage connectedness – something that is at the core of the digital universe.  Treating the world as a graph allows us to have a unified approach to querying and manipulating interconnected objects of many different kinds that exist in many different relationships to each other.

But theory only appeals to some… So let's add a second answer that is more… practical.  A directory has emerged that by August is projected to contain one billion users. True, it's only one directory in a world with many directories (most agree too many).  But beyond the importance it achieves through its scale, it fundamentally changes what it means to be a directory:  it is a directory that surfaces a multi-dimensional network.  

This network isn't simply a network of devices or people.  It's a network of people and the actions they perform, the things they use and create, the things that are important to them and the places they go.  It's a network of relationships between many meaningful things.  And the challenge is now for all directories, in all domains, to meet a new bar it has set.    

Readers who come out of a computer science background are no doubt familiar with what a graph is.  But I recommend taking the time to come up to speed on the current work on connectedness, much of which is summarized in Networks, Crowds and Markets: Reasoning About a Highly Connected World (by Easley and Kleinberg).  The thesis is straightforward:  the world of technology is one where everything is connected with everything else in a great many dimensions, and by refocusing on the graph in all its diversity we can begin to grasp it. 

In early directories we had objects that represented “organizations”, “people”, “groups” and so on.  We saw organizations as “containing” people, and saw groups as “containing” people and other groups in a hierarchical and recursive fashion.  The hierarchy was a particularly rigid kind of network or graph that modeled the rigid social structures (governments, companies) being described by technology at the time.

But in today's flatter, more interconnected world, the things we called “objects” in the days of X.500 and LDAP are better expressed as “nodes” with different kinds of “edges” leading to many possible kinds of other “nodes”.  Those who know my work from around 2000 may remember I used to call this polyarchy and contrast it with the hierarchical limitations of LDAP directory technology.

From a graph perspective we can see “person nodes” having “membership edges” to “group nodes”.  Or “person nodes” having “friend edges” to other “person nodes”.  Or “person nodes” having “service edges” to a “mail service node”.  In other words the edges are typed relationships between nodes that may possibly contain other properties.  Starting from a given node we can “navigate the graph” across different relationships (I think of them as dimensions), and reason in many new ways. 

For example, we can reason about the strength of the relationships between nodes, and perform analysis, understand why things cluster together in different dimensions, and so on.

From this vantage point, directory is a repository of nodes that serve as points of entry into a vast graph, some of which are present in the same repository, and others of which can only be reached by following edges that point to resources in different repositories.  We already have forerunners of this in today's directories – for example, if the URL of my blog is contained in my directory entry it represents an edge leading to another object.  But with conventional technology, there is a veil over that distant part of the graph (my blog).  We can read it in a browser but not access the entities it contains as structured objects.  The graph paradigm invites us to take off the veil, making it possible to navigate nodes across many dimensions.

The real power of directory in this kind of interconnected world is its ability to serve as the launch pad for getting from one node to a myriad of others by virtue of different  relationships. 

This requires a Graph Protocol

To achieve this we need a simple, RESTful protocol that allows use of these launch pads to enter a multitude of different dimensions

We already know we can build a graph with just HTTP REST operations.  After all, the web started as a graph of pages…  The pages contained URLs (edges) to other pages.  It is a pretty simple graph but that's what made it so powerful.

With JSON (or XML) the web can return objects.  And those objects can also contain URLs.  So with just JSON and HTTP you can have a graph of things.  The things can be of different kinds.  It's all very simple and very profound.

No technology ghetto

Here I'm going to put a stake in the ground.  When I was back at ZOOMIT we built the first commercial implementation of LDAP while Tim Howes was still at University of Michigan.  It was a dramatic simplification relative to X.500 (a huge and complicated standard that ZOOMIT had also implemented) and we were all very excited at how much Tim had simplified things.  Yet in retrospect, I think the origins of LDAP in X.500 condemned directory people to life in a technology ghetto.  Much more dramatic simplifications were coming down the pike all around us in the form of HTML, latter day SQL and XML.  For every 100 application programmers familiar with these technologies, there might have been – on a good day – one who knew something about LDAP.  I absolutely respect and am proud of all the GOOD that came from LDAP, but I am also convinced that our “technology isolation” was an important factor that kept (and keeps) directory from being used to its potential.

So one of the things that I personally want to see as we reimagine directory is that every application programmer will know how to program to it.  We know this is possible because of the popularity of the Facebook Graph API.  If you haven't seen it close up and you have enough patience to watch a stream of consciousness demo you will get the idea by watching this little walkthrough of the Facebook Graph Explorer.   Or better still just go here and try with your own account data.

You have to agree it is dead simple and yet does a lot of what is necessary to navigate the kind of graph we are talking about.  There are many other similar explorers available out there – including ours.  I chose Facebook's simply because it shows that this approach is already being used at colossal scale.  For this reason it reveals the power of the graph as an easily understood model that will work across pretty much any entity domain – i.e. a model that is not technologically isolated from programming in general.

A pluggable namespace with any kind of entity plugging in

In fact, the Graph API approach taken by Facebook follows a series of discussions by people now scattered across the industry where the key concept was one of creating a uniform pluggable namespace with “any” kind of entity plugging in (ideas came from many sources including the design of the Azure Service Bus).

Nishant and others have posed the question as to whether such a multidimensional protocol could do what SCIM does.  And my intuition is that if it really is multidimensional it should be able to provide the necessary functionality.  Yet I don't think that diminishes in any way the importance of or the need for SCIM as a specialized protocol.  Paradoxically it is the very importance of the multidimensional approach that explains this.

Let's have a thought experiment. 

Let's begin with the assumption that a multidimensional protocol is one of the great requirements of our time.  It then seems inevitable to me that we will continue to see the emergence of a number of different proposals for what it should be.  Human nature and the angels of competition dictate that different players in the cloud will align themselves with different proposals.  Ultimately we will see convergence – but that will take a while.   Question:  How are we do cloud provisioning in the meantime?  Does everyone have to implement every multidimensional protocol proposal?  Fail!

So pragmatism calls for us to have a widely accepted and extremely focused way of doing provisioning that “makes it fast, cheap and easy to move users in to, out of and around the cloud”.

Meanwhile, allow developers to combine identity information with information about machines, services, web sites, databases, file systems, and line of business applications through multidimensional protocols and APIs like the Facebook and the Windows Azure Active Directory Graph APIs.  For those who are interested, you can begin exploring our Graph API here:  Windows Azure AD Graph Explorer (hosted in Windows Azure) (Select ‘Use Demo Company’ unless you have your own Azure directory and have gone through the steps to give the explorer permission to see it…)

To me, the goals of SCIM and the goals of the Graph API are entirely complementary and the protocols should coexist peacefully.  We can even try to find synergy and ways to make things like schema elements align so as to make it as easy as possible to move between one and the other. 

Diagram 2.0: No hub. No center.

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

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

Further comments welcome.