… 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 :-)
… 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:
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:
Next, let’s talk about new things that might screw you up:
X509 certificate (CN=Fabrikam) chain building failed. A certificate chain could not be built to a trusted root authority.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:
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”.
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];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 )
<wsFederationBinding> opening & closing tags in App.Config to be <wsFederationHttpBinding>.binding="wsFederationBinding" to point to wsFederationHttpBinding instead.defaultProtectionLevel="EncryptAndSign" fromsystem.servicemodel/bindings/wsFederationHttpBinding/
binding/security/message
(ProtectionLevel=ProtectionLevel.Sign) as a property of ServiceContractand add (ProtectionLevel=ProtectionLevel.EncryptAndSign) as a property of OperationContractsystem.servicemodel/bindings/wsFederationHttpBinding/binding/ security/message/requiredClaimTypes
system.servicemodel/bindings/wsFederationHttpBinding/binding/ security/message/claims
(ie <requiredClaimTypes> becomes <claims>)
cnFactory.Description.Behaviors.Add( (IChannelBehavior)credentials);
cnFactory.Endpoint.Behaviors.Add( (IEndpointBehavior)credentials);
credentials.ServiceCertificate.Authentication.RevocationMode = X509RevocationMode.NoCheck;
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:
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:
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.
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.
Once you actually get the runtime components installed, and the digital identities icon actually pops up, you see a few new things:
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.
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…