C'est la vie !

How infocard and WS-* intersect: a concrete scenario.

It's been a while since I haven't posted anything on my quest to understand Microsoft's infocard. There's now substantially more information about it that a month ago so I had the opportunity to get a better idea of how infocard can be used and how do they relate to some of the WS-* specifications (like WS-Trust or WS-SecurityPolicy).

Below is a figure that describes a concrete sequence of steps that can take place between a client (e.g. a PC running Longhorn, sorry Vista) a relying party (a web service provider) and an identity provider.

Some explanations on the steps:

1. Step 1: The client application obtains (at design time or runtime) the relying party's policy.

2. Step 2: In this policy, RP indicates many things (like who the issuer is, the token type and the claims it needs). It also sets its authentication mechanism to the specific value "IssuedToken" (in the <SecurityToken> element which is defined in the newly released WS-SecurityPolicy specification). This will trigger the infocard system on the client.

3. Step 3: The ID Selector (part of the infocard system on the client) will match existing cards with the claims requested by the RP. It then lets the principal chose the appropriate card.

4. Step 4: The infocard system will then use the metadata contained in the card to contact the corresponding identity provider and obtain the security token and the needed claims (RST and RSTR are WS-Trust calls).

5. Step 5: The principal authenticates if necessary.

6. Step 6: The identity provider returns the appropriate security token with the claims that were requested.

7. Step 7: Finally the client application can access the RP using the token and claims it has just obtained.

One component I show here is not used: the Digital ID control panel. This panel is used to create local (i.e. self-issued) cards.

I've had the opportunity to show this diagram to some people in-the-know and they confirmed this was an accurate scenario (whewwww!) so I hope this might help some people understanding where infocard and the WS-* specs intersect.

Posted at 12:35AM Aug 03, 2005 by Hubert Le Van Gong in Identity  |  Comments[0]

JavaOne - TS3556

Pat and I will be presenting a session at JavaOne today (13h30); the title is Multiple Platforms, Single Identity: Interoperable identity (TS-3556).

We will discuss various forms of single sign-on (SSO) and introduce the concept of identity Federation. We will conclude our presentation with a live demo of SSO interoperability between a site that uses our Access Manager (it's powered by Liberty's Identity Federation Framework (ID-FF)) and a site run by Microsoft (using WS-Federation passive profile). This demonstration illustrates the use of our recently announced Web Single Sign-On Metadate Exchange protocol.

If you're at JavaOne and are interested in federated identity, please come and visit us!

Posted at 08:44AM Jun 29, 2005 by Hubert Le Van Gong in Identity  |  Comments[0]

Infocard - Follow-up

Well, I've had some excellent comments on my blog entry on Microsoft's Infocard and Identity Metasystem. As envisionned, there is a lot of uncertainty about interoperability between SAML, Liberty or the-likes and the metasystem proposal. Kim Cameron was kind enough to do a thorough review of my analysis and respond to it. Thanks a lot!

Below are my comments on Kim's responses:

Preamble: I'm still convince that using the term IP (Identity Provider) is a bad idea. Most identity systems I can think of associate Identity Providers (IP or IdP) with the provisioning of authentication statements, not attributes. And by most of them I include WS-Federation as well as Liberty, SAML or Shibboleth (well I guess that's pretty much all of them!). I have not (yet) read Kim's laws (so maybe I'm an outlaw – ok that's a bad one, sooorry ) but all I can say is that this is going to confuse people. Since the identity metasystem is brand new it would be great if Microsoft could find another term, that would clarify the debate.

I don't know if I'd call the Identity Selector a "broker" - in the sense that it is operated by the user rather than some other organization or agency. I don't want to start thinking of myself as "brokering" my own interactions - my life is complicated enough already. And I'll bet Hubert feels the same way.

The selector is actually engineered as a highly tuned control surface through which the user can establish an unambiguous and safe channel to the digital world. Through this surface the user is able to evaluate the authenticity of those with whom he or she is interacting, decide what provider should be used in a given context, and approve (or prevent) information being released to a relying party.

I would certainly agree that giving control to the user and preserving his privacy are essential criteria; these are actually some of the founding principles for Liberty. However I would say that the last thing we want is to bombard the user with requests from the identity selector; there is a difficult balance to strike between usability and security/privacy but I hope that the metasystem will be flexible enough to let a service provider obtain some information from an attribute provider (identity providers in the metasystem) without additional consent by the user being (of course assuming he previously expressed this at the attribute provider). In fact it seems to me the identity selector is close to the Liberty's interaction service except it is constrained to be on the user's PC when Liberty offers several ways of interacting with the owner of the attributes.

Regarding Identity Metasystem, is there going to be a similar notion to profiles? By profile I mean things like a personal profile (home address, shipping address...) or a business profile... Basically some clearly specified set of attributes that logically go together. A service provider could then refer to such specification when requesting data, which would facilitate the identity selector's task. My understanding is that the infocard will group attributes together but I'm not sure there will be agreed-upon templates.

Within this kind of a system, does an Identity Provider (IP) know what the user's decisions are? That depends.

An IP never knows what a user has disclosed using another IP. So there is complete segregation of providers. This allows complete segregation of identity contexts.

I think we're in total agreement here, the last thing we want is to have attibute providers correlating (any type of )information about the user's activities. But if the user had to give his consent for the release of some information to a service provider, I don't see how the IP would not be aware of it; maybe I missed something.

Further, a given IP may or may not know who the user is divulging information to. In other words there can be both "auditing" and "non-auditing" identity providers. Our study of the laws led us to conclude that in some contexts, auditing by the provider may be considered a good thing, whereas in others it may not. Our goal is to provide a platform for expressing all aspects and variations of identity.

A non-auditing identity provider is significantly different from what an IP does in Liberty. But an auditing provider seems to me to be totally consistent with the concept of a Liberty IP (which knows about the information releases a user has approved, including what information has been - or should be - released to whom).

Terminology issue again – We need to be careful here as when kim writes "Liberty IP" he means an attribute provider (namely a WSP – Web Service Provider). That said, I think Kim makes a good point on the fact that a Liberty WSP does know what information (it hosts) was released on behalf of the user. I have to say I don't have a good example of when a non-auditing provider is preferable. Note that a WSP does not know much about the requesting service provider (WSC in Liberty's jargon.

Hubert also asks a good question about the details of interworking with other systems. It has been pretty clear to me that SAML and Liberty implementations can easily interwork with this proposal - it may require some extensions to current capabilities but nothing very significant. So really, it's a question of whether we want (as an industry) to make this proposed metasystem work or not. As an identity guy I certainly hope so since I think it is win-win for all players, including the individual - who, as Doc Searls so convincingly pointed out at DIDW, will increasingly move toward the center of economic activity as the world continues to collide with cyberspace.

As one can read in my blog Scott Cantor and others commented on the interoperability aspect of Microsoft's proposal. At the low-level there is some common ground with the support of SAML tokens. Beyond that it is a bit unclear how SAML2.0 for instance would interoperate with the Identity Metasystem. Kim thinks it should be easy so I will anxiously look for postings around that issue.

In terms of the ID-WSF framework, I'm not an expert on this. But from my viewpoint, InfoCards in no way dictate what protocols are used for all kinds of web services and all kinds of scenarios, so I don't understand the "direct competition" point. Maybe Hubert can explain. InfoCards are, basically, a proposal for giving the user control, supporting multiple technologies and operators within a unified context, and upping the bar on safety and user integration - doing all the things necessary to building a metasystem that is consistent with the laws of identity outlined here.

When I wrote "direct competition" I meant between Liberty's ID-WSF and the overal Identity Metasystem proposal. ID-WSF provides a framework for identity based web services (discovery of attribute providers, retrieval of user's information, interaction service...). It sure seems to me like the Identity Metasystem is looking at providing a similar set of functionality, isn't it?

Posted at 06:46AM May 24, 2005 by Hubert Le Van Gong in Identity  |  Comments[0]

Paul Madsen - WS-KindofInteresting

In this blog entry Paul discussed our (Sun) recent announcement of the Web Single Sign-On Metadata Exchange Protocol developed with Microsoft. I think he's raising interesting points on the interoperability issue.

First, a minor correction:

Sun and Microsoft recently announced some fruits of their relationship in the identity management and web services space, the wonderfully named WSSOMEP (I think they missed out on the chance to call it SOME (Sign On Metadata Exchange))

We actually refer to it as WSSOMEX (see in the Interoperability profile document) but SOME would have been cool indeed

Then Paul suggests other ways to perform this 'What languages do you speak?' query:

So this is one way to address the 'what can the other guy do' issue. There are others. Here is my list:

• ask the other guy (WSSOMEP model)

• look it up (metadata file at well-known location)

• ask somebody else (UDDI)

• trial and error, e.g. use one of the suites and, if it works, fine. If not, glean something from the error message

To me the 2^nd option is close to one method proposed in the protocol document to discover where the Identity Provider is located. One issue I can think of with such approach (or the 3^rd one) is the lack of dynamicity and the requirement for the identity provider to provision this information ahead of time (plus the maintenance of it): it's a bit of a if you want to know something about me, just ask me direclty and you'll be sure to get up-to-date information kind-of-thing. The last method may seem dumb but when the number of possibilities is reduced (and one would argue it is greatly reduced as of today ) it is actually pretty efficient; not scalable at all but efficient...

Paul then moves on to Liberty ID-WSF:

What others are there?

For Liberty's ID-Web Services Framework, the Web Services Consumer (WSC) is able to discover versioning support of its eventual partner Web Services Provider (WSP) by interacting with the Discovery Service. The knowledge it gains about the capabilities of the WSP is implicit however, it never explicitly asks the question 'what can the other guy do' but rather 'give me everything I need in order to talk to the other guy'. The 'everything I need' includes the required versioning info.

I find very interesting that Paul refers to the versioning mechanism used in ID-WSF as I to think there is quite a bit of overlap between the 2 mechanisms (at least scope-wise). Of course the difference is that the model used in WSSOMEX does not rely on a 3^rd party (the DS in ID-WSF) that speaks the same language than the requester so we need to define protocol (could be hand waving...); we should investigate how Liberty could leverage something like WSSOMEX (or WSSOMEX directly once it gets into a standards org. but that is a separate topic).

Posted at 02:36PM May 20, 2005 by Hubert Le Van Gong in Identity  |  Comments[0]