Adventures of an Eternal Optimist

… ok not really.

But I do love the new slashdot pony theme… get it while you can, limited time offer…

Update: It’s over. But Pinkdot will live on. Me, I’m looking to get a tshirt made :-)

Things went along just swimmingly last night at my “Infocard in an Enterprise Context” talk at the Directory Experts Conference. There were many insightful questions from the audience, and afterwards, it warmed my geeky little heart to see Stuart Kwan surrounded by crowds of administrators, all wanting to give feedback and have questions answered.

There were some very interesting topics brought up during the discussion, which I want to capture before I forget. The most discussed topics surrounded that of “card proliferation”. If you end up having as many different managed cards on your desktop as you do cards in your physical wallet, does that become easier or harder to use than regular username/password combinations?

It is a really good point. A great example was brought up, which was identification cards for gambling establishments. What if you have 20 membership cards for 20 casinos? There are two ways that those casinos might want to do the infocard thing: either they could give you a managed card with that information in it, or they could register your self-asserted card.

In the first case, you literally would end up with 20 different cards. Remember though, in that case the gambling establishment would be requiring an exact issuer, so ALL the cards in your wallet would be greyed out except the right one, and that the same card would always be used for transactions with that site, so it would always pop up at the top, with the “you used this card last time, would you like to use it again? message”. In the second case, you could create a “gambling card” that could be registered at as many sites as you wished. You could do this safely, because nothing in the information stored in the infocard is specific to any one of the gambling institutions, it is just personal contact information. Instead of you giving them your membership number, you are giving them your PPID, which is associated with your membership number at the gambling site. By doing so, you have completely removed any data from the card that would be of interest to steal, or that could be accidentally given away during the process of using the card at multiple sites. Remember that a PPI is a calculated identifier that is different for every Relying Party.

I think that at least in the beginning, that 2nd case will be more common. However, users themselves will not be able to choose what kind of card the Relying Party demands, and besides, the root point of the original question remains. How many cards do YOU have in your wallet? How many username/password combos have you, over the years, accumulated? If Infocard really takes off, there is no doubt that people will begin to accumulate infocards, even if they work hard to keep their cardsets small.

I can’t speak for MS of course, but I’m pretty sure that the Infocard team would be delighted to have this technology become so popular that they have to race to get rid of the currently existing card limit (I know there is one, can’t remember what it is) and implement mass-management tools for the interface sooner rather than later (-:

Another discussed topic was the idea of having cards that had some controlled fields and some open fields. That one is a topic for a whole other conversation, and a very interesting concept.

Lastly – Dave Kearns asked me what about my presentation was “user-centric”. I replied “nothing” as I was specifically addressing how the identity metasystem could be locked down and controlled/audited/managed centrally to satisfy business needs. I think that perhaps that answer was flippant — users still get to see what of their information is being passed in the enterprise, and they can also choose which corporate credentials they wish to use for what corporate resources — this is still an increase in choice and visbility to what they have now.

If you were there and if you are interested in trying this technology out, here is a uber-quick set of instructions and gotchas:

• Although infocard will run on both W2K3 and XP sp2, I suggest using XP sp2, as IE7 beta previews are not yet supported on W2K3
• Getting the right version of IE7 is *critical*. I don’t know all the version numbers, but the version I have works – IE7 Beta preview 2. There was another version following that which does NOT work, so be careful. If you can’t afford the time to be wrong, let me know and I’ll make sure you get a working version.
• Don’t use a host system that you have any attachment to. If you want to follow the CTPs as they come out, you will almost certainly have to start from scratch (for example, moving from the Jan CTP to the Feb CTP required a vanilla install). Use VMs if you can.
• Apparently (and I haven’t even tried it yet, it is that new), there are now TWO Relying Parties on the internet that you can go to with your new Infocard client, Kim Cameron’s Identity Blog and Chuck Mortimore’s Java-based Relying Party.

Thanks again to everyone who attended, I hope that y’all had fun.

Update: Jef comments that IE7 version 5335 fails, and that he got version 5299 to work. I also know that Rohan Pinto had trouble with version 5299 and had to resort to 5296. No matter what, it seems that 5335 is a no go, so I hope that helps! Thanks Jef.

I've just had an experience that I did not expect.

I'm in Vegas for the Directory Experts Conference, and I just walked away from the registration desk with a tshirt.

(you're all wondering if I've gone batty, right? Conference tshirts are a dime a dozen, most people I know use them in their shops as rags)

I walked away from that registration desk with a women's medium. That's right – somebody actually took the time to think about the ladies here at the conference. I can't tell you how downright respectful that is. And how rare. In my years of attending conferences, I have rarely even been able to find a men's small (all the small sizes go first, so I often end up with a garment that is more suitable as a dress than a shirt).

It seems like such a small thing, but really, it is an acknowledgement. It says to me that the women at this conference were expected, are welcomed, and that somebody out there has finally figured out that a woman wearing a classy, relatively form-fitting tshirt with your logo on it is a very good thing.

Compare this to what usually happens to my tshirts — my Dad gets them, and you might catch a glimpse of one of them if you happened to wander by as he mows his lawn… :-)

I have the code that used to work on the Jan CTP working again. It was hard work, for a sys-admin moonlighting as a programmer such as myself :-) I’m hoping that the assembly re-org is over for good — it will kill me if I have to do this again in a month. I also should mention that I think that the reorg was a really good idea, the new organization is a lot more intuitive.

I couldn’t have figured this out without the ‘breaking changes‘ link that I posted earlier. Since you don’t actually have my code, this will seem rather esoteric; however anyone who is wrestling with one of the errors I mention, or researching one of the classes affected should understand what I mean. BTW – any code shown is in C#.

Let’s start with the “dumb errors” and get them out of the way:

• Don’t forget that you had to install the Feb CTP on a vanilla system – if you are using the certificates supplied in the Sept 2005 Resource Kit, make sure to:
• Place the client and service certificate again
• Set up the IIS virtual directory to host the logos of the certificate again (this is optional I believe, but still nice).

Next, let’s talk about new things that might screw you up:

• You have to know to add project references for System.IdentityModel and System.IdentityModel.Selectors. They don’t appear on the nice little list  — I had to browse to C:\Program Files\Reference Assemblies\Microsoft\WinFx\v3.0 and choose them manually.
• In the Sept 2005 Resource Kit, a note existed in the Programmers Guide saying that they had relaxed issuer requirements, and the certificate issuer did not have to be in the “Trusted Root CA” list. Apparently relaxation time is over — you MUST have a valid certificate chain now, one that can be traced to a valid root CA. If you don’t, you will get this exception:
X509 certificate (CN=Fabrikam) chain building failed. A certificate chain could not be built to a trusted root authority.
• To satisfy this requirement, export the certificate for INFOCARD that is generated when you import Fabrikam.pfx, and re-import it into the “Trusted Certificate Authorities” portion of “LocalMachine”. You will know it is in the right place when you open up the original Fabrikam certificate and the details tell you that this certificate is properly chained.
• I believe that the Feb CTP implements online certificate revocation checking by default for the first time (feel free to call me out on that, I come to that conclusion honestly, since revocation was not an issue for me in the Jan CTP and now it is/was). You have to set the default revocation mode to “NoCheck” instead of the now-default “Online” setting if you want things to work without revocation checking. Actual Code for setting this is listed later on in this entry. If you don’t change the setting, you may get an exception:
X509 certificate (CN=Fabrikam) chain building failed. The revocation function was unable to check revocation for the certificate.

Ok, let’s get to the actual Delta List:

Compilation Errors

1. The type or namespace name ‘AuthorizationContext’ could not be found (are you missing a using directive or an assembly reference?)

• Include “System.IdentityModel.Policy”

2. The type or namespace name ‘ClaimSet’ could not be found (are you missing a using directive or an assembly reference?)

• Include “System.IdentityModel.Claims”:

3. The type or namespace name ‘ServiceEndpointCollection’ could not be found (are you missing a using directive or an assembly reference?) — or — The name ‘MetadataResolver’ does not exist in the current context

• Include “System.ServiceModel.Description”

4. Cannot declare variable of static type ‘System.ServiceModel.Description.MetadataResolver’ –or– Cannot create an instance of the static class ‘System.ServiceModel.Description.MetadataResolver’ –or– ‘System.ServiceModel.Description.MetadataResolver’ does not contain a definition for ‘RetrieveEndpoints’

You probably have two lines similar to this:

• MetadataResolver mexProxy = new MetadataResolver(mexAddress);
• ServiceEndpointCollection endpoints = mexProxy.RetrieveEndpoints();

Replace those lines with this line:

• ServiceEndpointCollection endpoints = MetadataResolver.Resolve(mexAddress);

And include “System.ServiceModel.Description”.

5. The type or namespace name ‘InfoCardClientCredentials’ could not be found (are you missing a using directive or an assembly reference?)

• Include “System.IdentityModel.Selectors”.

6. ‘System.ServiceModel.Security.X509CertificateRecipientClientCredential’ does not contain a definition for ‘Certificate’

Replace a line like this:

• credentials.ServiceCertificate.Certificate = ((X509CertificateIdentity)ep.Address.Identity).Certificates[0];

With a line like this:

• credentials.ServiceCertificate.DefaultCertificate = ((X509CertificateIdentity)ep.Address.Identity).Certificates[0];

Runtime Errors

1. Unrecognized attribute ‘type’. Note that attribute names are case-sensitive.

Alter your app.config file to look like this:
<service name='X'
Instead of this:
<service type='X'

(note: got this little tidbit from: Ed Pinto’s Blog )

2. Unrecognized element ‘wsFederationBinding’

• Change the <wsFederationBinding> opening & closing tags in App.Config to be <wsFederationHttpBinding>.
• Change the endpoint attribute binding="wsFederationBinding" to point to wsFederationHttpBinding instead.

3. Configuration section ‘system.serviceModel/bindings/wsFederationBinding’ could not be created. Machine.config is missing information. Please verify that this configuration section is properly registered and that you have correctly spelled the section name. For Windows Communication Foundation sections, run ServiceModelReg.exe -i to fix this error.

• This really just means that you missed changing “wsFederationBinding” to “wsFederationHttpBinding” somewhere. You do not need to run ServiceModelReg.exe, trust me I went down that rabbit hole.

4. Unrecognized attribute ‘defaultProtectionLevel’. Note that attribute names are case-sensitive.

• In your App.Config, remove defaultProtectionLevel="EncryptAndSign" from

system.servicemodel/bindings/wsFederationHttpBinding/
binding/security/message

• In your C# code, add (ProtectionLevel=ProtectionLevel.Sign) as a property of ServiceContractand add (ProtectionLevel=ProtectionLevel.EncryptAndSign) as a property of OperationContract
• Include System.Net.Security if ProtectionLevel doesn’t properly resolve.

5. Unrecognized element ‘requiredClaimTypes’.

• In your App.Config, replace the attributeless tag:

system.servicemodel/bindings/wsFederationHttpBinding/binding/ security/message/requiredClaimTypes

• With the tag:

system.servicemodel/bindings/wsFederationHttpBinding/binding/ security/message/claims

(ie <requiredClaimTypes> becomes <claims>)

6. Unable to cast object of type ‘System.ServiceModel.DnsIdentity’ to type ‘System.ServiceModel.X509CertificateIdentity’

• Replace a line of code like this:

cnFactory.Description.Behaviors.Add( (IChannelBehavior)credentials);

• With a line of code like this:

cnFactory.Endpoint.Behaviors.Add( (IEndpointBehavior)credentials);

7. X509 certificate (CN=Fabrikam) chain building failed. The revocation function was una ble to check revocation for the certificate.

• This is the bit about revocation being set to “Online” by default. Add the following line of code (I put it right before I attach the endpoint certificate to the infocardcredentials variable (called credentials)):

credentials.ServiceCertificate.Authentication.RevocationMode = X509RevocationMode.NoCheck;

• you also need to include System.Security.Cryptography.X509Certificates for X509RevocationMode to resolve.

I found me some doc-U-men-tation on reference assembly changes made to the february CTP:

http://windowscommunication.net/collateral/pages/BreakingChangesJanCTPToFebCTP.htm

I haven’t had a chance to digest it all, but basically it looks like everything in System.Security.Authorization is now part of a new reference assembly called System.IdentityModel.   As well, stuff from System.ServiceModel.Design has been moved into System.ServiceModel.Description.

Affected classes that are part of my Infocard code are:

• authorizationContext
• ClaimSet
• Claim
• MetadataResolver

There are definitely more (such as infocardclientcredentials) that aren’t documented but are probably easy to figure out.  As soon as i get a minute, I will try and give you an exact accounting.   The strange thing is, the document doesn’t mention Microsoft.Infocards once, but my understanding is that data from that assembly has been merged into System.IdentityModel.Selectors.

More data to come. Stay tuned.

(note from the future:  fixes for below problems described here)

You know that saying about one step forward, two steps back?
For any of you who aren’t masochistic, I’m going to save you from having to read the rest of this entry, and give you the executive summary of my experience with the identity-related bits of the Feb CTP right now:

• For the digital identities applet to work, you need to install the WinFX runtime on a vanilla OS, I couldn’t get uninstalls of either the Nov or Jan CTPs to work. Even on the vanilla system it takes forever (but at least it works).
• The infocard client, once installed, won’t import card exports from the last version of infocard. It also throws an error when exporting newly made cards.
• The Microsoft.Infocards, System.ServiceModel.Design, and System.Security.Authorization assemblies don’t seem to be included in the runtime. I’m not a .NET guru, but I think that’s not right.
• Windows SDK is a monster download encoded differently than earlier versions, and also doesn’t seem to have the assemblies listed above.
• As well, the dev extensions (Orcas) do not appear to contain the Microsoft.infocards, System.ServiceModel.Design, or System.Security.Authorization assemblies
• Without those assemblies, it is tougher to exercise the client in any meaningful way.

Final analysis: If you are interested in Infocard, stick with the Jan CTP. The Feb CTP will get you less, not more. Keep in mind, I’m not pretending to be a Visual Studio wizard, and maybe I have to do something wacky like register the SDK or something. I’m just a user trying to follow instructions and failing.

Runtime Installation

Man, where to start? First of all, the cleanup files just don’t work. You can ONLY install this CTP on a vanilla OS if you don’t want to see a little popup window that says the digital identity control panel applet failed to start. I don’t know what they forgot to clean up, but they definitely missed something.

Client Usage

Once you actually get the runtime components installed, and the digital identities icon actually pops up, you see a few new things:

• a link to add provider cards (now all we need is a provider)
• a link to preferences (which doesn’t go anywhere)
• a link to import previously saved cards (that fails when I try to import cards saved from my Jan CTP client)
• a link to export cards (that also fails with an data store error)
• a link to create/manage self-issued cards (which works well)
• a link to Site Usage (that will probably stay empty, see dev section below)

I know this sounds very critical. I’m sorry. Out of anyone, I’m excited to see this technology succeed, but you gotta throw me a bone here! People out there are spending their time to set up this CTP and eagerly see what’s new. They need to know what they are going to get.

Development Environment

Next I tried to run my infocards solution from the last CTP (this is the code that I barely cobbled together from the long-defunct identity resource kit). Nope. That didn’t work either. I’m missing System.ServiceModel.Design, Microsoft.InfoCards and System.Security.Authorization. Shouldn’t these be part of the runtime? Maybe not, this could just be my .NET and/or Visual Studio immaturity showing through.

I vaguely remember a painful process involving .img files from my November adventures with WinFX. So I download the Feb CTP WinFX SDK. A whole gigabyte of SDK. Just to get 3 rotten assemblies. I finally get this hefty little .img package on my disc drive, open isobuster, and thank heavens the ordeal is almost over…. except — NO! It’s not over yet. The only thing I can extract easily is a file called README.T — and all it says is

“This disc contains a “UDF” file system and requires an operating system that supports the ISO-13346 “UDF” file system” specification.”

This is new. I didn’t have to jump through quite so many hoops last time, I don’t think. Can we make it any more difficult?

Luckily, the application of google to the problem resulted in a link the following blog entry from: Tom Archer’s Blog

Bless you. My hero… if you are trying to install the SDK, just go to that link and follow the instructions.

But it all appears to be for naught if you are trying to run InfoCards development code in Visual Studio. I’ve installed the SDK and the extensions (ie Orcas), and I still can’t find Microsoft.Infocards, System.Security.Authorization, or System.ServiceModel.Design. Now, I’m no visual studio wizard, there is likelihood of some serious PEBKAC here. But maybe not — maybe that stuff really isn’t there. All the information on MSDN about the Microsoft.infocards namespace is gone – nothing left but a broken link, as of March 12 at 8:20am. This also makes me suspicious.

I dunno. I’m stumped. All I can think of to do is to spend another hour on google, mining for any possible pertaining link. I could try and run my infocards server code on the old JanCTP box and then see if at least the client code will run on the new box. But generally, I would have to say that this Feb CTP client is completely, utterly, useless.

It’s only been HOURS since I started to install the February 2006 WinFX CTP. I hope there is something new and exciting to discover, after this long, nasty wait.

I also can’t help but notice that the install script is labelled “WinFX Runtime Components 3.0 Beta 2″. That is the same name that I just *uninstalled*, except that what I uninstalled was the January CTP. I’m seized with the terrible fear that I’m accidentally installing the old file instead of the new one, and that I’m going to have to do this all over again, but really I just think that nobody cares to more specifically label the installations. Hopefully there is a way to tell once (if) the stupid thing ever manages to finish.

There just has to be room for improvement when the CTP takes longer to install than the base operating system…

Update: FOILED!!! Something apparently went terribly wrong with the installation, since when I try to start InfoCard, I get an error that says: “The Digital Identity Control Panel Applet failed to start. Error: 0xc005010e Message: the digital identiy service could not be accessed”

Crap. What a waste of a night…

Ok. So let me get this straight. Higgins is an API that will let developers consistently manipulate identity information in different systems, such as LDAP, WS-*, Email, and IM.

Similar concept to JNDI, right?

I’m confused as to how this will directly compete with Infocard. Saying that Higgins competes with InfoCard is like saying that Eclipse competes with InfoCard, is it not? You could use Higgins to create an Identity Selector that one day competes with InfoCard, true. You could also write mulitple Identity Selectors with Higgins that compete with each other – so the competition aspect has little to do with the API, as far as I can see. Either way, creation of a competing Identity Selector is hardly a bad thing, MS is actively encouraging development of identity selectors for other platforms, and seems willing to go head to head with anyone who tries competing on Windows. In fact, I personally think that it can’t be anything but GOOD for Microsoft – IMO, the worst thing that could happen to MS is that nobody bothers to compete at all, and InfoCard withers due to lack of adoption.

I’m not saying it isn’t a good idea, in fact I think it could be great.  I just feel like all the press articles were asking the WRONG questions. Personally, I want more concrete information on exactly what the API will sit in front of. If an API separates applications and libraries, what are those applications, or at least what are the libraries? Do those systems really have enough components in common to ensure that using the abstracted interface actually saves developers time, compared to using the existing mature and well documented APIs?

Those are the things I wonder…