Kerry McCain bill proposes “minimal disclosure” for transaction

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

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

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

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

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

 

Touch2Id Testimonials

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

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

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

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

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

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

ZIP ruled personally identifying in California

From CNN this surprising story:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Clay Feet of Giants?

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

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

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

Just further evidence of just how irrelevant Microsoft has become.

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

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

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

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

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

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

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

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

Let me clear. The Identity Metasystem has no peer.

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

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

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

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

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

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

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

 

Change will come: the present is untenable.

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

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

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

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

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

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

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

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

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

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

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

In fact I bet that we do. 

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

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

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

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

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

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

From CardSpace to Verified Claims

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

What’s new about it?

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

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

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

A focused approach

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

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

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

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

What about CardSpace?

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

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

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

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

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

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

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

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

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

 

Vittorio's new book is a must-read

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

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

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

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

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

A confused critique of identity federation

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

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

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

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

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

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

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

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

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

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

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

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

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

6.2 ACTORS PARTICIPATING IN THE METASYSTEM

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:

image

image

image

image

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.

image

 

 

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
http://github.com/southworks/protocol-bridge-claims-provider

Download
http://github.com/southworks/protocol-bridge-claims-provider/downloads

Docs
http://southworks.github.com/protocol-bridge-claims-provider

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.