So you want to adopt Infocard?

Good news, you’re in very good company. I’ve spent the last few months flying around the Globe, helping BIG players in the enterprise space to devise ways in which they can start getting pragmatic with Infocard in their business. While I can’t go into details, for obvious reasons, I believe that sharing some of the experiences earned so far may provide good food for thoughts.

In this first installment I will introduce the idea of multi-role PoCs, and I will suggest a strategy for figuring out what claims should go in a card. Here we go J

 

From Gills to Lungs

 

First of all: we have to keep in mind that we live in a very peculiar era. The idea of the Metasystem is dawning, the Infocard bits have been available for a relatively short time. While there’s an amazingly large consensus around it, the ecosystem is still populated by few pioneers who are extremely committed to prove a point and they don’t mind using fins instead of pawns (read: figuring things by themselves instead of happily shopping for ready code/tools). I have a gut feeling that soon evolution will make a significant leap, and we’ll witness a Cambrian Explosion (the prelude to what Kim likes to call Identity Big Bang) in number and diversity of solutions based on Infocard. But in the meanwhile, or if you want to be part of that irresistible force that will push things forward, you will often find yourself in the position of occupying more than one niche.

Let’s see if I manage to be clearer. In a fully developed Identity Metasystem ecology, you would simply take steps to occupy the role (IP, RP or Subject) mandated by your business and you would thrive right away in active participation. But if you are a natural IP, for example, and you write a proof of concept today you may end up with a “cathedral in the desert” for some time: the number of compliant relying parties is still small, so a proof of concept which would encompass your role only would not be very probing to begin with. Furthermore, today many players do not have the level of specialization & role autonomy that the Metasystem allows. It is indeed quite common to see somebody who owns all the three ends of the canonical scenario: there’s a user store, complete with profiles; one or more (web) apps which perform the biz function; more rarely, you can also have a companion smart client which coordinates with the other two to deliver the service (easy case: online photo printing services, with a smartclient for uploading big data). All in the hands of a single player, which owns all the ends of the scenario.

If you are in that situation, you can still profitably experiment with the Metasystem without “having to choose a side” (yet). You can apply the design principles of claim based authorization and trust based authentication to your reality, maintaining clear independence and role separation between modules even if your scenario may (seem to!) allow you the luxury of being tightly coupled to yourself. Insodoing, in your proof of concept you’ll have a chance to walk in the shoes of more roles and touch what it means in practical terms: so when the time will come to profitably assume a prevalent role, you will know what it takes to be the counterpart of that role and this will prevent a number of small but unpleasant glitches in the execution. Besides, you will have a great chance to re-engineer your IdM structure according to sound, proven, maintainable & scalable practices J

 

What claims?

 

OK, enough metaphors: let’s get practical.

In a typical end to end scenario you own one or two websites, offering your revenue generator service (may be even just gaining eyeballs for advertising) to a crowd of users that you own as well (read: you have a user store, complete with profiles).

You want to explore the use of Infocard, so you decide to factor your assets in

 

• one identity provider
  
• one or two relying parties

And things get interesting already at this point. Even before having the ball rolling and see the first HTTP post, you need to make some decisions about how your cards will look like.

In a pure IP scenario, deciding on the claims would be pretty much straightforward: you take the User table on your user store, and every column is probably a good candidate to become a claim. This is a very good start, and I usually draft the claim set according to this principle. We have to consider, however, that until today we didn’t really have any barrier between our web apps (now the RPs) and our user store (now façaded by our IP): so if we needed any additional data after the authentication phase, it was easy to stretch our hand and grab it. Now things are different: the claims listed in the card mandates the info I can obtain from the IP, and I must assume that I can talk with the IP only via WS-Trust. This means that any info owned by the IP and NOT codified in the card in form of claim will be unreachable: the obvious consequence is that we MUST figure out what we will need NOW, at design time. We have to go though the code of our RPs, and discover on which user info they (not surprisinglyJ) rely upon. Since we own both ends, IP and RP, what we discover can actually influence the IP itself. We may discover that we need one certain claim that was not codified as a column in the user store, but nonetheless its value can be obtained only by the IP part: in that case we will add such a claim in the card, and once we’ll get to the point of writing an STS we will embed in it the logic for populating such a value. If we have more than one RP, which will rely on the same IP, you have to consolidate all the info you get from each one of them in the card: every RP will explicitly ask for the claim subset it needs, but the card needs to be ready for the full set. Again, this is an “unnatural” situation made possible by our PoC: a pure IP would simply expose in the card the info it knows without concerns of what RPs want, here you are simply “reverse engineering” what are such info from the RPs logic since until now we haven’t explicitly singled them out. In the true Ecosystem you can expect a RP to evaluate if one IP offers the info it needs, and if the IP doesn’t the RP will simply move on and decide to federate with somebody who does.

There is another point, subtle but with important consequences: there may be info about the user which is not owned by the IP, but it is squarely owned by the RP. Let’s think of the classical scenario of the wine seller, which is happy if you sign in with a card from a trusted IP and containing an indication of your age. The wine seller may see a value in remembering that you bought prevalently Brandy, and push special offers on you as you log in. The labels of the last bottles you bought are not information that a generic IP should codify in a claim, as the ownership of it goes clearly to the wine seller: that brings to the idea that user profiles on RPs are something still useful in a Metasystem world. The authentication and authorization are taken care of by the IP card, while the business specific profiling is still in the hands of the RP. There are some complications: nothing prevents the user from sending different cards in different sessions as long as they all satisfy the RP policy, so the RP user profiling may not be straightforward in a registration-free scenario; however this is not too hard to solve, I’ll get back to it in some other post.

Below you can find a small divertissment where I show a rough schema for the claim inclusion decision process described above.

 

 

OK, that was a lot of meat. And we barely scratched the surface, the sole claim vs. profile discussion is BIG and should encompass selfissued cards as well… I hope I gave you food for thoughts, and I encourage you to use the comments if you want clarifications or you want to share your experience. Let’s make this happen! Who wants to be the first to evolve wings? J