Transducers and Delegation

Ernst Lopez Cordozo recently posted a very interesting comment about delegation issues:

“We always use delegation: if I use a piece of software on my machine to login to a site or application, it is that piece of software (e.g. the CardSpace client) that does the transaction, claiming it is authorized to do so.

“But if the software is compromised, it may misrepresent me or even somebody else. Is there a fundamental difference between software on my (owned? managed? checked?) machine and a machine under somebody else’s control?”

Ernst’s “We always use delegation” may be true, but risks losing sight of important distinctions. Despite that, it invites us to think about complex issues.

Analog-to-Digital transducers

There are modules within one's operating system whose job it is to vehicle our language and responses by sensing our behavior through a keyboard or mouse or microphone, and transforming it into a stream of bits.

The sensors constitute a transducer performing a conversion of our behavior from the physical to the digital worlds. Once converted, this behavior is communicated to service endpoints (local or distant) through what we’ve called “channels”.

There are lots of examples of similar transducers in more specialized realms – anywhere that benefit is to be had by converting physical being to electrical impulses or streams of bits. And there are more examples of this every day.

Consider the accelerator pedal in your car. Last century, it physically controlled gas flowing to your engine. Today, your car may not even use gas… If it does, there are more efficient ways of controlling fuel injection than with raw foot pressure… The “accelerator” has been transformed into a digital transducer. Directly or indirectly, it now generates a digital representation of how much you want to accelerate; this is fed into a computer as one of several inputs that actually regulate gas flow (or an electric engine).

Microphones make a more familiar example. Their role is to take sounds, which are physical vibrations, and convert them into micro currents that can then be harnessed directly – or digitized. So again, we have a transducer. This one feeds a channel representing the sound-field at the microphone.

I’m certain that Ernst would not argue that we “delegate” control of acceleration to the foot pedal in our car – the “foot-pedal-associated-components” constitute the transducer that conveys our intentions to engine control systems.

Similarly, no singer – recording through a microphone into a solid-state recording chain – would think of herself as “delegating” to the microphone… The microphone is just the transducer that converts the singer's voice from the physical realm to the electrical – hopefully introducing as little color as possible. The singer delegates to her manager or press representative – not to her microphone.

So I think we need to tease apart two classes of things that we want done when using computers. One is for our computers to serve as colorless transducers through which we can “become digital”, responding ourselves to digital events.

The other is for computers to “act in our stead” – analyze inputs, apply logic and policy (perhaps one day intuition?), and make decisions for us, or perform tasks, in the digital sphere.

Through the transducer systems, we are able to “dictate” onto post-physical media. The system which “takes dictation” performs no interpretation. It is colorless, a transcription from one medium to another. Dictation is the promulgation of “what I say”: stenography in the last century; digitization in this.

When we type at our keyboard and click with our mouse, we dictate to obedient digital scribes that convert our words and movements into the digital realm, rather than onto papyrus. These scribes differ from the executors and ambassadors and other reactive agents who are our “delegates”. There is in this sense a duality with the transducer on one side and the delegate on the other.

Protection of the channel

No one ever worried about evil parties intercepting the audio stream when Maria Callas stood before a microphone. That is partly because the recording equipment was protected through physical security; and partly because there was no economic incentive to do so.

In the early days, computers were like that too. The primitive transducer comprised a rigid and inalterable terminal – if not a punch card reader – and the resulting signal travelled along actual WIRES under the complete control of those managing the system.

Over time the computing components became progressively more dissociated. Distances grew and wires began to disappear: ensuring the physical security of a distributed system is no longer possible. As computers evolved into being a medium of exchange for business, the rewards for subverting them increased disproportionally.

In this environment, the question becomes one of how we know the “digital dictation” received from a transducer has not been altered on the way to the recipient. There is also a fundamental question about who is gave the dictation in the first place.

In the digital realm, the only way to ensure integrity across component boundaries is through cryptography. One wants the dictation to be cryptographically protected – as close to the transducer as possible. The ideal answer is: “Protect the dictation in the transducer to ensure no computer process has altered it”. This is done by giving the transducer a key. Then we can have secure digital dictation.

Compromise of software

Ernst talks about software compromise. Clearly, other things being equal, the tighter the binding between a transducer (taken in a wide sense) and its cryptographic module, the less opportunity there is for attack on the dictation channel. Given digital physics, this equates to reduction of the software surface area. It is thus best to keep processes and components compartmentalized, with clear boundaries, clear identities.

This, in itself, is a compelling reason to partition activities: the transducer being one component; processes taking this channel as an input then having separate identities.

Going forward we can expect there will be widely available hardware-based Trusted Platform Modules capable of ensuring that only a trusted loader will run. Given this, one will see loaders that will only allow trusted transducers to run. If this is combined with sufficiently advanced virtualization, we can predict machines that will achieve entirely new levels of security.

CardSpace

Given the distinctions being presented here, I see CardSpace as a transducer capable of bringing the physical human user into the digital identity system. It provides a context for the senses and translates her actions and responses into underlying protocol activities. It aims at adding no color to her actions, and at taking no decisions on its own. 

In this sense, it is not the same as a process performing delegation – and if we say it is, then we have started making “delegation” such a broad concept that it doesn’t say much at all. This lack of precision may not be the end of the world – perhaps we need new words all the way round. But in the meantime, I think separating transducers from entities that are proactive on our behalf is an indispensible precondition to achieving systems with enough isolation between components that they can be secure in the profound ways that will be required going forward.

New Visual Studio Toolkit for CardSpace

If you use visual studio and are interested in CardSpace, you'll be interested in Christian Arnold's brand new “Visual Studio 2005 Toolbox for Windows CardSpace”.  It looks like it makes the task of CardSpace enabling .NET 2.0 apps as easy as pie.  I'm out of the country now but can't wait to try it.

You can download the tools here.  Christian also runs what he calls a “little support forum“.

The ToolBox provides an easy way to use Windows CardSpace in your ASP.NET 2.0 Web-Application to register and validate your users. It´s also possible to use the controls to receive a SAML token and get the decrypted values of provided claims. The token decrypting process is build based on the community sample.

The install process looks pretty straightforward – you just add the tools to your toolbox:

 

That adds two new controls to your Visual Studio 2005 ToolBox:

Here's a taste of how you use the CreateCardSpaceUserWizard Control:

 

You need to add a little configuration:

<cc1:CreateCardSpaceUserWizard ID=”CreateCardSpaceUserWizard1″ runat=”server” BuildInRegistration=”False” OnUserRegistered=”CreateCardSpaceUserWizard1_UserRegistered1″>

<cc1:IdentityClaim ClaimUri= “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier” />

<cc1:IdentityClaim ClaimUri= “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” />

</cc1:CreateCardSpaceUserWizard>

Christian explains that this causes the system to request the privatepersonalidentifier and the emailadress of a new user powered with CardSpace or other Information Card identity selector.

He explains that by defining the claim

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

the control will store the emailaddress automatically, so you don't have not to worry about this 🙂

After registration the control will fire the UserRegistered Event. The eventargs will tell you the result of the operation and the provided claims as a NameValueCollection.
 
Christian goes on to explain how to use the system with the default ASP.NET 2.0 Membership-Provider. 

Clearly, there are a great many sites built on this Membership-provider technology and the emergence of this toolkit in the identity ecosystem is a major event.

Comment problem seems due to Firefox bug

As Pamela explains, it was neither the upgrade to WordPress 2.0.2 (made necessary by a security vulnerability discovered in WordPress 2.0.1), nor the nifty Pamela Project code, that has been causing problems when using non-Windows Card Selectors with Firefox on my blog.  Instead, it is the latest rev of Firefox itself (bugs are being filed).

For anyone who is using the “xmldap Identity Selector” Firefox plugin on the Mac and has suddenly found that they are unable to log into the PamelaWare Test Blog or Product Blog or Pat’s or Kim’s blogs, the problem is not with the blogs themselves. The problem appears to be buggy nastiness in the Mac version of Firefox 2.0.0.2, which wreaks havoc with Chuck’s plugin (xmldap Identity Selector v0.8.6) . If you uninstall Firefox 2.0.0.2 and then install Firefox 2.0.0.1 from mozilla.com (get release 2.0.0.1 here), you will again be able to authenticate to everyone’s blogs once again. The Safari plugin works as well, so if you want to remain on Firefox 2.0.0.2, you could satisfy your Information Card needs by using that plugin on your Mac instead.

We now return you to your regularly scheduled blog commenting :)

A number of people also discovered a less severe problem where comments ended up in a manual approval queue rather than being automatically posted even after InfoCard login.  If you have logged in with an InfoCard you should be getting automated instant access.  As far as I can tell, this now works properly.

Please keep me posted about any other issues.  This will help everyone using WordPress with the Pamela Project plugin.

Final note:  automated trackbacks will also be slowed down for a while I strengthen the trackback spam filter (gee – too bad there is no delegated authentication yet…)  If you want me to see a posting quickly please drop an i-names email.

The umpire delegates back

Pete Rowley of RedHat has to win the Witty Title Award for “The umpire delegates back“:  

Recently Kim Cameron has been defending CardSpace against various assertions that it won’t work offline. As I pointed out some while back, that is pure nonesense. I’ll let you read Kims blog for the details of how such a system might work with CardSpace, but I’ll just say it has to do with delegation. And that’s just a big word for access control, in this case user centric decentralized access control.

There really is no big secret to how this stuff is possible – at some point in time an offline user will be online, and during that time instead of ceding their credentials to the service in the sky (or worse, it happens without choice), they spend the time granting access specific to the service that needs access. That’ll be a statement along the lines of “Pete’s blog is allowed to view this flickr photoset.”, not “here’s my password dude, do as you will”, or indeed “hey, IdP, see that service? That’s me that is.” I have to agree with Kim on the notion of impersonation – at no time should anybody give the required access level for impersonation of themselves, on or offline.

There be dragons.

Pete has a fascinating blog and it's really worth following his People In The Policy series.  This is good stuff.

WordPress 2.1.2 and Project Pamela

I've installed a new version of WordPress – and Project Pamela's InfoCard plugin (more later) – and I'm using it to run my blog as of NOW.  If you see anomolies, let me know.

The good news is Project Pamela's InfoCard plugin is really slick.  It worked right out of the box. 

It doesn't require WordPress 2.1.2, but I wanted to get to the latest revision.

The bad news is that if you currently log in with an InfoCard you will have to respond to an email sent by the system in order to be switched over to the new way of doing things at my end.  Pretty painless though.

ISSUE: Password registration is still not enabled while I figure out exactly how it works

Separating the identity of users from services

Geoff Arnold added a comment to an earlier piece that helps tease out the issues around delegation:

In otherwords, there is no user-absent scenario. There is a user is present and delegates authority scenario. After all, how can a user delegate authority if she isn’t present???

That's fine as long as one of the rights that can be delegated is ability to delegate further. And I'm guessing that that's what Eve is really talking about. Not delegating 100% of her rights to some agent, but delegating sufficient rights that the agent can act as a more-or-less first class entity, negotiating and delegating on her behalf.

In fact the only (obvious) right that I should not be able to delegate is the right of revocation….

OK.  So delegation is recursive.  If we accept the notion that services operate within their own identity when they do something a user has asked them to – then if they want to delegate further, they need to create a Delegation Token that:

  • asserts they have the right to delegate in some particular regard; and 
  • defines exactly what they want to delegate further, and to whom.

They need to present this along with the user's authorization.  One ends up with the whole delegation chain – all of which is auditable.

In this scenario, the user's identity remains under her control.  That's one of the things we mean when we say, “user centric”.  By issuing an authorization for some service to do something, she actually asserts her control over it.  I think this would be true even if, given a suitable incentive, she delegated the right of revocation (there are limits here…)

Multiple tokens to capture these semantics 

CardSpace is built on top of WS-Trust, though it also supports simple HTTP posts. 

One of the main advantages of WS-Trust is that it allows multiple security tokens to be stapled together and exchanged for other tokens.  

This multi-token design perfectly supports strong identification of a service combined with presentation of a separate delegation token from the user.    It is a lot cleaner for this scenario than the single-token designs such as SAML, proposed by Liberty, or the consequent “disappearing” of the user.

I guess I find Eve's contention that, “By contrast, Liberty’s ID-WSF was developed to support both the ‘human present’ and ‘human absent’ modes” a bit triumphalist and simplistic.   

Going forward I'll write more about why I think WS-Trust is a step forward for these delegation scenarios.  And about why I think getting them right is so very important.

Identities on multiple devices

As I said here, I want also to look at a second strange claim by Eve

On another issue, she noted that OpenID 1.0 has a vulnerability in that it leaves users’ identities open to possible correlation by unauthorized third-parties.

But that CardSpace has a vulnerability of an opposite but equally problematic nature. Given that each CardSpace is associated with a particular client device (i.e., a particular desktop, laptop, or mobile phone running Vista), and given the fact that each user might have multiple such devices, each with a multiplicity of cards running on them…that the more such devices, cardspaces, and i-cards multiply for a given user, the more difficult it will become for a particular user to correlate the various fragments of their identity across their own personal “space.”

This really strikes me as bizarre.  Maybe Eve was asleep while the entire world learned to copy mp3s onto their music players and carry them around?  Duh.  We know how to move files from device to device.  In fact there are probably many hundreds of millions of people who can do it better than either Eve or I can.

The idea that this is the big vulerability of CardSpace boggles my mind.  The whole criticism “Does not compute.”

Then again, I actually use Information Cards, and move them from device to device, so maybe that's why it's so clear to me how easy it is to do. 

Let me share the exact experience I have installing the Information Cards from my PC's CardSpace onto my mobile phone.

 Moving Information Cards from device to device

1)  I open up CardSpace and select Back Up Cards.  This will create a file containing my cards.  I decide to call it “cardset”.

2) I copy ‘cardset’ to my phone and click on it:

3) The phone asks for the password I used to protect my file

 

4) It verifies I'm importing the right cards

5)  And now I have the same cards on my phone device as on my PC.

How hard is that?  It would be the same process copying the file to some other device.  It works fine.  As easy as getting a word document or powerpoint or mp3 from one place to another.  Dongle anyone?  How about email?

Still, the uberpoint is this:  once Information Cards live on my phone, they go whereever I go. 

There are lots of ways phones can potentially talk to other devices.  So who says we have to copy our cards to all our devices once they live in a secure, personal device like a phone that we always have with us?

NOTE:  I want to point out that the mobile implementation of CardSpace I'm showing here is NOT a product.  It's a way of learning about the issues, and collaborating with colleagues in the world of telecom and secure portable devices.  But hey!  It's still a lot of fun.  More later.

Interesting summary by Kobielus

Despite the puns in his first paragraph, this piece by James Kobielus is very interesting, and sums up a lot of the conversations he has been having with people involved in the identity milieu:

“First off, I'd like to suggest that what we should be focusing on is not ‘user-centric identity’, per se, but ‘internet-scalable identity metasystems’ (a thought that Andre ping'd me on and Dick got me to take to hardt). What are the principles for making our identity metasystems truly internet-scalable? Could it be that user-centricity (however defined) is a necessary (but perhaps not sufficient) condition for internet-scalability?

“Now, let's look back to that previous post where I enumerated the main internet-scalability questions that Mr. Hardt laid out for our consideration:

  1. How do we scale up user-centric identity schemes, in which claims/attributes flow through and are forwarded by the user, so that they work on an open internet scale, not just within self-contained federations or circles of trust?
  2. How do we enable the free movement of claims from anywhere to anywhere?
  3. How do we extend lightweight identity management to the “long tail” of websites that don't and won't implement a heavyweight trust/federation model such as SAML or Liberty requires just to do chained/proxied authentication?
  4. How do we leverage the same core universal lightweight internet design patterns–i.e., REST using URIs and HTTP/HTTPS–to do internet-scale ubiquitous identity?

“Now I'm going to slightly shift the context for a moment to Kim Cameron's “laws of identity,” and then attempt to map that, plus Hardt's concerns, back to the notion of what it takes to make an identity metasystem truly internet-scalable. First, what I'll do is just republish Kim's actual written principles, but in a different order:

  • Consistent Experience Across Contexts: The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.
  • Pluralism of Operators and Technologies: A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.
  • Human Integration: The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.
  • User Control and Consent: Technical identity systems must only reveal information identifying a user with the user’s consent.
  • Minimal Disclosure for a Constrained Use: The solution which discloses the least amount of identifying information and best limits its use is the most stable long term solution.
  • Justifiable Parties: Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
  • Directed Identity: A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

“Now, I'll reclassify/regroup/rewrite these principles into three higher-order principles:

  • Abstraction: An internet-scalable identity metasystem must provide all end- and intermediary entities (i.e., users, identity agents, IdPs, RP/SPs, identity brokers, etc.) with a consistent, abstract, standardized , lightweight, reliable, speedy, and secure experience/interface across all use cases, interactions, credentials, protocols, platforms, etc while enabling separation of identity contexts across myriad domains, operators, and technologies.
  • Heterogeneity: An internet-scalable identity metasystem must enable seamless, standards-based interoperability across diverse identity use cases, interactions, design patterns, credentials, protocols, IdPs, RP/SPs, platforms, etc.
  • Mutuality: An internet-scalable identity metasystem must ensure that all end- and intermediary-entities (i.e., human users, identity agents, IdPs, RP/SPs, identity brokers, etc.) can engage in mutually acceptable interactions, with mutual risk balancing, and ensure that their various policies are continually enforced in all interactions, including, from the human user’s point of view, such key personal policies/peeves as the need for unambiguous human-machine communication mechanisms, privacy protection, user control and consent, minimal disclosure for a constrained use, limitation of disclosures to necessary and justifiable parties, and so on and so forth.

“Now, how would conformance to these three wordy uber-principles contribute to internet-scalability? Well, abstraction is the face of the universal interoperability backplane of any ubiquitous infrastructure (be it REST, SOA, ESB, or what have you). And heterogeneity is the fabric of any hyper-decentralized, federated, multidomain interoperability environment. And mutuality (i.e., a balancing of rights, responsibilities, risks, restrictions, rewards, etc.) is essential for any endpoint (e..g, the end user, an RP/SP, etc.) to participate in this heterogeneous, abstract environment with any degree of confidence that they can fend for themselves and actually benefit from plugging in.

“User-centric identity got going as an industry concern when it became clear that federated identity environments are not always mutual, from the end user's point of view. In other words, under “traditional” federation, some “attribute authority” (not necessarily under your or my direct control) may be coughing up major pieces (attributes) of our identity to unseen RP/SPs (also not under our control) without consulting us on the matter. In other words, those RP/SPs can selectively deny us access to the resources (i.e., apps, data, etc.) we seek, but we often can't selectively deny them access to the resources (i.e., our identity attributes) that they seek. Doesn't seem like a balanced equation, does it?

“Now, tying all this back to Dick's key design criteria for the identity metasystem (in summary): open, free, lightweight, ubiquitous interaction patterns. Seems to scream for abstraction plus heterogeneity plus mutuality, which are necessary and, taken together, sufficient conditions for internet scalability.

“In other words, necessary for the identity metasystem to be universally feasible, flexible, interoperable, implementable, extensible, and acceptable.

I think James makes good points. 

Certainly one of the main things that will get us to the identity big bang is correcting the way earlier systems  “disappeared” the user.  You can see this in the enterprise domain-based systems, where the domain was all-powerful, and it was just assumed that a user was an artifact of one single administrative domain. We now realize we need more flexible constructs.

And you can see it in consumer systems as well.

Why did we all do this?  It depends on the context.  In the consumer space, I think, for example, it was assumed that customers would be loyal to the convenience of a “circle of trust” set up by portal operators and their suppliers.  There was nothing innately wrong about this, but it is just one scenario seen from one point of view. 

From the individual customer's point of view, the “circles of trust” should really have been called “circles of profit” between which they were supposed to choose.  As Doc Searls says, this isn't the only customer relationship which is possible!  Basically, we're talking very last-century stuff that didn't understand the restructuring impact of the web – and these ideas now have to grow into a much wider context.  This is a world of really deep relationships with customers, not of forced confinement.

So a big “correction” was in the cards, and the popularity of the “user-centric” view derives partly from this.  But there are other forces at play, too.  People can talk about “user agents operating on our behalf” as much as they want.  But who decides what “our behalf” really is?  We need as individuals to control those agents – delegate to them as James says – and keep them from getting “too big for their britches…” 

So my basic thesis is not that there shouldn't be agents and services operating on our behalf – or that I would support an architecture that made this impossible.  It is that all these services and agents must begin and end by being under the user's control, and we need a consistent technology to achieve that.

I totally buy the notion that a web site gets to decide who accesses it, and what the rules of engagement are for that to happen (“trust is local”).  So the user's control with respect to her interests do not diminish a service's control with respect to its interests.  Should we call this mutuality?  I think what we really have is a mutual veto – both the user and the site being visited can set whatever bar they want before they back out of the transaction.  To me, in a world of competition, this remains control.

 

Mixed signals?

Stephen Mcgibbon, senior director of Microsoft's European technology office, is in the midst of a lively identity discussion on the Danish blog Overskudsdanmark.  In a posting called, “What CardSpace enables, Vista prevents…“, Stephen quotes Stephan Engberg – who is on the international advisory board of Privacy International and other important organizations – as saying,

“I can easily see that Cardspace in itself COULD be a step in the positive direction, but MS is sending mixed signals by pushing the aggressive Live Id and “trusted” computing simultaneously with Cardspace.

“That might be ok if someone else had access to make usable solutions, but it is not my understanding that VISTA and Cardspace provide that access. What Cardspace enables, VISTA prevents.”

I guess there are several issues here.  I'll defer the discussion of how CardSpace provides openness until Stephan has had a chance to look around this blog – the “HelloWorld Card” series would probably help get a technology orientation.  Or just poke through the articles, or look at comments like this recent one from Dale Olds at Novell.  While that's happening, I'll try to get more up to speed on his criticisms of Live ID and Vista.

Perhaps I can move the discussion forward by sharing some high level information about the current Windows Live ID service.

It's quite a bit different, conceptually, than Passport was – even though it is a technical evolution of that system.  At core, Live ID sees itself as part of a very distributed and multi-centered world, whereas Passport was centralized and technologically monolithic.

You can get a sense for this by looking at the most recent Windows Live ID Whitepaper.  Let me pass on a few quotes which I hope will entice you to read more of the paper:

How Does Windows Live ID Participate in the Identity Metasystem and Work with “InfoCard”?

Microsoft is working with others in the industry to create an identity metasystem that brings existing and future identity providers into a connected identity ecosystem and empowers end users to control the use of their identities. The Windows Live ID service will participate in the identity metasystem as one identity provider among many, able to accept claims from other identity providers and transform them so they can be used within Microsoft online services. This participation will include acceptance of self-issued and managed “InfoCards.” It will thus provide full support for the “InfoCard” identity model.

Roles of the Windows Live ID Service in the Identity Metasystem

Microsoft has published its vision of a universal identity solution that is inclusive of a plurality of identity operators and technologies—the identity metasystem. In such a metasystem, identity providers, relying parties, and subjects can select, request, transfer, transform, and consume identities through a suite of well-defined and open Web Services (WS-*) protocols. Microsoft is working to implement components of the identity metasystem, as are many other companies in the industry. As a result, various building blocks for the metasystem are being developed. Some of these components will be delivered to end users in the form of software installed and running locally on their computers and devices, while others will be online services.

The design philosophy of the identity metasystem is not to replace the existing identity systems in use today, but instead to bring these existing systems together by enabling interoperation among subjects, relying parties, and identity providers through industry standard protocols. The Windows Live ID service will participate in the identity metasystem as a “managed” identity provider already at Internet scale. Windows Live ID will bring a large base of end users and relying parties to the metasystem, taking us one step closer to Internet-wide identity federation and doing our part to help the industry move beyond the “walled garden” paradigm.

The Windows Live ID service will play several essential roles that are strategic for Microsoft. The service:

  • Is an Internet-scale identity provider intended primarily for users of Microsoft online services, which are all relying parties of the Windows Live ID service.
  • Is open and issues claims in a form that can be consumed by any relying party, any device, and any other trusted identity authority.
  • Serves Microsoft online services as a “claims transformer,” allowing those services to accept identities issued by third-parties. Third-party identity providers include other Internet service providers and managed-identity providers, such as the planned Active Directory Security Token Service (STS).
  • Will be the identity provider and federating authority for third party services and software built on top of the Microsoft online services platform

In short, I see Windows Live ID as the identity component for the MSN properties, which speaks standard protocols, and is trying to be open and do business with the other parties who want to engage.  This is all a new model – not only for Microsoft, but for the industry as a whole.  There are many business details to be worked out, as there are elsewhere in the industry.  But I see a progressively deeper committment to putting privacy first, and think my Live ID colleagues deserve a lot of credit for that.  In fact, we have invited Stephan's Privacy International colleague Simon Davies to review and criticize our structures and initiatives, and have tried to act on his recommendations just as we would act on the recommendations of world-renouned security experts or other leading thinkers.

So I'm interested in the disconnect Stephan and I have in our perceptions.  Is it because Microsoft hasn't communicated broadly enough? Or is there something substantive here?  I would really like to understand. 

In terms of Stephan's comments about Vista being controlling in some way, I just don't understand at all.  It's the opposite of what we were trying to do.

Not everything about Vista is perfect, but we have been very hard core about putting our customers totally in control.  User-centriic is a big deal for me, and for everyone I know.  So are open interfaces and protocols.  I don't understand his objection to our “trusted computing” effort. 

So Stephan, let me know what you're thinking, and let's try to figure this out.

 

Bandit and Higgins hit interop milestone

I was so snowed under trying to work against time for the OpenID annoucement at RSA that I missed blogging another imporant milestone that has been reached by the identity community.  This report on progress in the Higgins and Bandit side of the house is great news for everyone:

The Bandit and Eclipse Higgins Projects today announced the achievement of a key milestone in the development of open source identity services. Based on working code from the two projects and the larger community of open source developers, the teams have created a reference application that showcases open source identity services that are interoperable with Microsoft’s Windows* CardSpace* identity management system and enable Liberty Alliance-based identity federation via Novell® Access Manager. This reference application is a first-of-its-kind open source identity system that features interoperability with leading platforms and protocols. This ground-breaking work will be demonstrated at the upcoming RSA Conference in San Francisco.

“There are two basic requirements for translating the potential of recent identity infrastructure developments into real-world benefits for users: interoperability and a consistent means of developing identity-aware applications,” said Jamie Lewis, CEO and research chair of Burton Group. “First, vendors must deliver on their promise to enable interoperability between different identity systems serving different needs. Second, developers need a consistent means of creating applications that leverage identity while masking many of the underlying differences in those systems from the programmer. The Bandit and Eclipse Higgins interoperability demonstration shows progress on the path toward these goals. And the fact that they are open source software projects increases the potential that the identity infrastructure will emerge as a common, open system for the Internet.”

The Bandit and Higgins projects are developing open source identity services to help individuals and organizations by providing a consistent approach to managing digital identity information regardless of the underlying technology. This reference application leverages the information card metaphor that allows an individual to use different digital identity ‘I-Cards’ to gain access to online sites and services. This is the metaphor used in the Window’s CardSpace identity management system that ships with the Vista* operating system.

“Windows CardSpace is an implementation of Microsoft’s vision of an identity metasystem, which we have promoted as a model for identity interoperability,” said Kim Cameron, architect for identity and access at Microsoft. “It’s rewarding to see the Bandit and Higgins projects, as well as the larger open source community, embracing this concept and delivering on the promise of identity interoperability.”

The open source technology developed by Bandit and Higgins enables initial integration between a non-Liberty Alliance identity system and a Liberty Alliance-based federated identity system provided by Novell Access Manager. Specifically, these technologies enable Novell Access Manager to authenticate a user via a Microsoft infocard (CardSpace) and consume identity information from an external identity system. It will further show that identity information from Novell Access Manager can be used within an infocard system. This is a significant step forward in the integration of separate identity systems to deliver a seamless experience for the user as demonstrated by the reference application.

“The Liberty Alliance project fully supports the development of open source identity services that advance the deployment of Liberty-enabled federation and Web Services as part of the broader Internet identity layer,” said Brett McDowell, executive director of the Liberty Alliance. “The open source community’s embrace of Liberty Alliance protocols is validation of the benefits this technology provides, and we salute the Bandit and Higgins teams for their role in making the technology more broadly accessible.”

Higgins is an open source software project that is developing an extensible, platform-independent, identity protocol-independent software framework to support existing and new applications that give users more convenience, privacy and control over their identity information. The reference application leverages several parts of Higgins including an identity abstraction layer called the Identity Attribute Service (IdAS). To support a dynamic environment where sources of identity information may change, it is necessary to provide a common means to access identity and attribute information from across multiple identity repositories. The IdAS virtualizes identity sources and provides a unified view of identity information. Different identity stores or identity management systems can connect to the IdAS via “context providers” and thus provide interoperability among multiple systems.

“Many groups have been working towards the goals of Internet identity interoperability,” said Paul Trevithick, technology lead for the Higgins project. “This milestone represents a major step in having multiple open source projects work together to support multi-protocol interoperability.”

The Bandit project, sponsored by Novell, is focused on delivering a consistent approach to enterprise identity management challenges, including secure access and compliance reporting. The Bandit team’s contributions to the reference application include the development of multiple “context providers” that plug into the Higgins Identity Attribute Service (IdAS) abstraction layer to provide access to identity information across disparate identity stores. It also showcases the role engine and audit reporting capabilities in development by the Bandit community.

“The development of this reference application would not have been possible without the collaboration and contribution of the wider Internet identity community,” said Dale Olds, Bandit project lead and distinguished engineer for Novell. “This is the first of many milestones we are working towards as both the Bandit and Higgins communities strive to enable interoperable, open source identity services.”

So congratulations to Bandit, Higgins and everyone else who made this happen – this is great stuff, and the identity big bang is one step closer for it.