Hi there!This may be a bit ahead of its time, and it will sound to many as an exercise in empty "formalism": but I believe it may be food for thought for some others, so here it is :) Summary: I propose it will be useful to have a collective name for the portfolio of resources accessible by a company via federation agreements, as the prominence of such a portfolio IMHO will steadily grow.Yadda yadda: Today all the "online" resources fall in one (or more) of the following categories: intranet, internet and extranet. This is a pretty handy subdivision, not only because it expresses where a resource lives: it conveys clearly the level of access I have on that resource, the contexts from which I can leverage it, which capabilities I can expect and so on and so forth. I can use that distinction to decide what to make of a resource. However, from the functional perspective that taxonomy can sometime lose its effectiveness, there are grey zones. If I partner with an external company, I can access their resources better than if I were a generic net surfer: so when I consider how to leverage those resources as an asset it's not efficient to treat them as belonging to the Internet category. Yet I wouldn't say that they are now in my extranet, as they are not under my control (except for the part covered by the partnering contract), and a fortiori that they are in my intranet! So how would I call this situation? Today I don't give a name to it, maybe the pattern does not appear often enough or it simply surfaces in such a variety of forms that it's difficult to focus on it. There are so many different ways of partnering that it's not the matter of speaking of the lack of a standard: there's not even a customary way of doing it. If I see a star shaped cloud, I call it a star shaped cloud if anything (that's to say I describe it, I don't call it): if start shaped clouds would start to appear in big quantity everyday in wintertime I bet metereologists would soon start to call it stellanembus or some even less likely name.Fast forward some time in the future: WS-* sank down in the infrastructure layers, and everybody happily take advantage of it without even knowing it's there anymore. Things which today are hard to implement, like the above mentioned cross company partnering, became super easy for the technical point of view (or, if you don't want to see it that way, at least there is a defined way of partnering which has wide consensus) and what's left is just the commercial contract part. I'm not an economist, but I can imagine that this will promote new business models in which other company's services are seen more and more often like an asset, which can be leveraged in a similar way to the internal resources. Maybe something not radically different from today in sustance, rather a matter of reaching a critical mass. Those aggregates, guess what, could be appropriately called federations (hey, I finally said the word) from the identity management point of view. From the wire point of view, those resources are probably accessed in the same way as the internal ones: ok, in house I use kerberos and for them I've to shop at their STS to bargain a SAML; does that change the life of my devs? You bet it doesn't. For the design and business perspective, however, those are a different category: the relationships must be mantained, contracts (in paper, not in square brakets:)) must be signed & renewed, the SLAs must be verified, the claims mapped, etc etc. So it will make sense, as it does now, to treat resources "borrowed" from external entities according to their specific values and drawbacks (this doesn't diminish the value of *accessing* them with the same ease as the internal ones, courtesy of the WS-* gang). In other words, IMHO it will be useful to have a collective name for the portfolio of resources which are available to a company thanks to federation agreements, irrespective of their physical location. I don't know if that portfolio will be called Fnet, Fednet, Federnet or any other assonance with the *net theme or if it will depart completely from a location based schema: however it will be, I'm rather convinced that we will need a name for it :)Think of a typical meeting: "OK, the bill for this pay per use service is out of control, yet it makes no sense to build one in-house: maybe it's time to extend our Federnet with somebody who perform the same functions?"
P.S.: didn't I mentioned in the former post that I would have been more practical in the future? Well, you're a b s o l u t e l y right. But this stuff was buzzing in my head, and writing about it was a good way to get rid of it :-) If you are eager of rock solid enablers for the federated world of tomorrow available today or almost, go visit Andy's blog. It will be hard to find a better resource about Infocard.
Back in October 2005, few weeks after I moved to the US, I wrote a blog post in which I introduced the