"A logical fallacy is a false or incorrect logical principle. An argument that is based upon a logical fallacy is therefore not valid."

1) Argument from authority: Stating that a claim is true because a person or group of perceived authority says it is true. E.g. "this thing scales, the vendor said so".

2) Looks Good on Paper: A particular design looks elegant and can be easily explained on paper. However is non-performant and entirely unmaintainable in real-life. Example of this is the "enterprise service bus".

3) Design from Best of Breed: Identify the functional areas covered by your architecture, then pick best of breed in each area. You end up with a master of all trades, Jack of none. Your system needs to hang together, you can’t take each area in isolation.  These days with software acquisitions you can’t even be guaranteed that choices from a single vendor will hang together as they might have been developed by different smaller companies.

More on this later…

Here is a blurb about the panel:

Beyond Web 2.0…What Enterprise 2.0 Is…And What It Means For Wall Street

Beyond Web 2.0, Enterprise 2.0 is about deploying these new technologies and social practices in a corporate business context.

This session will explore the drivers pushing Enterprise 2.0 adoption, survey relevant technologies, and discuss how Wall Street and the financial markets are benefiting.

Tom Steinthal, Managing Director, Financial Services, BSG Alliance (Moderator)
Marc Adler, Senior Vice President, Equities and Head of Complex Event Processing, Citigroup
Michael Ogrinz, Principal Architect for Global Markets, Bank of America
Jonathan Rochelle, Senior Product Manager, Google

Should be an interesting discussion.

1. Self-Issued Cards in which essentially you act as your own security token service and
2. Managed cards – in which a trusted third party acts as Identity Provider making assertions around your identity.

I have seen many examples leveraging self-issued cards but relatively few incorporating managed cards. There is a sample STS available on the http://cardspace.netfx3.com website but due to the complex nature of it I’ve found it challenging to set up and leverage. If you look at the message boards they are full of issues and questions involving managed cards.

To mitigate this I’ve put together a managed STS and will be hosting it here from my own website in the coming days. It’ll allow you to setup a relying party, setup claims and test values for same and even download a managed card.

I’ll also provide a generic test harness that’ll simulate your relying party and allow you to test the end to end interactions. Last thing it’ll do is provide you with the RST and RSTR structures passed around in XML as we go.

I hope this’ll be a useful service and a useful learning tool and there’ll be more to come on that in a few days. (as a side note I’m surprised Serrack or Microsoft hasn’t set this up themselves by now).

But of course there is a selfish agenda to all my work and the main reason I did this is because I wanted to understand the inner workings of a security token service. This (painful) process has shown me…

1. how it processes the Request for a Security Token
2. how it generates the Request for a Security Token Response
3. how the Cardspace Identity Selector will process that and lastly
4. how to consume the token on the Relying Party side.

When an RP indicates it needs a claim, let’s say
http://schemas.francisshanahan.com/sts/superclaim

Cardspace includes that as a required (or optional) claim in an RST. The Security Token Service reads this, (presumably) locates the value for this claim and then includes that value in an RSTR.

One thing I was surprised to learn is that Cardspace Identity Selector doesn’t actually display this value! The ID selector actually displays a value from what’s called a "Display token". Here’s where things begin to break down (for me)…

The values in the Display Token are actually what get displayed to the user.

So tying back to the Laws of Identity: The user should have knowledge and control over what gets sent to any Relying Party.

This Displaytoken seems to violate this as follows…

1. There is nothing that prevents the STS from including claims in the RSTR that were not requested in the RST.  Thus an STS could
   • ignore the "isOptional" attribute of each claim and include that information regardless.
   • Or worse still, an STS could include claim values that WERE NEVER requested. I’ve tried this with my own STS and Cardspace happily forwards these on to the RP for decryption.
2. There is nothing that prevents the STS from including Values in the Display Token that are DIFFERENT from the values in the actual claims token. So for example, it may be shown to the user that they are passing an email address of "foo@bar.com" but in reality the value being sent to the RP is actually "mypersonal@emailAddress.com". The user wouldn’t know at best until the RP processed the RSTR token.
3. Whilst the Security token is encrypted and bundled up nicely to protect its information, the DisplayToken is sent in clear (to allow the Cardspace selector to display it). Now what’s the point of protecting your claims in a security token if you go ahead and put those same claims in a Display token? How can we have user control and consent (Law #1) without violating the security of the data itself?

So it seems once again I have confounded myself with Identity by delving into the details. Perhaps it would be better to just go along with the whiteboard conversations and ws-trust what I’m being ws-told rather than ws-implement it?

It would appear based on my rudimentary investigations that there’s a potential for the first Law to be broken either through
a) Unwittingly implementing an STS that pumps in claims into an RSTR without looking at the RST.
b) A malicious STS mis-representing claims to a end user and secretly passing different information to an RP.

This for me was the kind of "Ahaah" moment that would typically not be uncovered until knee deep in an implementation and could potentially derail a project. I’m not saying this is the fault of  Cardspace, or even the Identity Meta-System. Rather I think this is a problem that’s just inherent with Law #1. As with anything I tend to find there is a lot of buzz around the high-level solution but sometimes when you dive a level deeper, you come to find out there may actually be a problem [LINK].

That’s why it’s always better to be an "I-know-it-works-because-I-tried-it,-look-my-hands-are-dirty" architect than an "I-don’t-know-what-the-problem-could-be,-it-compiled-on-the-whiteboard" architect.

I will talk to Kim[LINK] about this…

A while ago someone made the claim that there was only one way to implement a pattern. This struck me as a remarkable statement as the very word "pattern" implies no specific implementation. A pattern is an abstract notion that has potentially many implementations, that’s what makes it so useful. Most people start with the GoF Blue Book on patterns but you may prefer the "Non Software Examples of Patterns" [LINK].

Talk to any java person for more than 5 minutes and they’ll throw up the MVC all over you. This is a nice pattern but many folks don’t understand it. For example just this morning I heard an "architect" refer to the MVC as Model, View, Controls. They described implementing the View using CSS and the "Controls" using tag libraries. Ho-hum.  Even more common is that folks don’t realize there are two MVC patterns, model 1 and 2.

A lot of Patterns turn into Anti-Patterns because folks blindly follow the pattern without understanding the pattern. For example someone recently told me you shouldn’t implement the Abstract Factory using reflection. Riiiigghhht.

So maybe a new description of patterns is needed. I’ll offer this one up using something that’s easy to understand: Vegetables.

1. The Onion Design Pattern; This is a "layered architecture". Instead of 2 or 3 layers, you actually have 20 or 30. Opening it up usually makes you cry.
2. The Asparagus Design Pattern; This pattern is generally tasteless. You’ll think all is fine until hours later when you visit the bathroom.
3.   The Artichoke; Another layered design; In this case almost 90% of the code-base can be cut out and discarded.
4. The Mushroom; Not a true vegetable design pattern. This one grows up overnight. All is usually fine until you cut into it and millions of spores are released into the air.
5.   The Sprout; A malleable design pattern, usually implemented in a "new & fresh" technology like "Ruby on Rails" or "Grails". Sometimes referred to as "Agile" but unable to support any load.

I’m sure there are more…