\n
<\/P>
\n
From Gills to Lungs<\/STRONG><\/P> <\/P> 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\u2019s 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\u2019t 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\u2019ll 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.<\/P> Let\u2019s 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<\/I> you may end up with a \u201ccathedral in the desert\u201d 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\u2019s 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.<\/P> If you are in that situation, you can still profitably experiment with the Metasystem without \u201chaving to choose a side\u201d (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\u2019ll 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<\/SPAN><\/SPAN><\/P> <\/P> What claims?<\/STRONG><\/P> <\/P> OK, enough metaphors: let\u2019s get practical.<\/P> 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).<\/P> You want to explore the use of Infocard, so you decide to factor your assets in<\/P> <\/P> 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. <\/P> 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\u2019t really have any barrier between our web apps (now the RPs) and our user store (now fa\u00e7aded 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<\/SPAN><\/SPAN>) 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\u2019ll 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 \u201cunnatural\u201d situation made possible by our PoC: a pure IP would simply expose in the card the info it knows<\/I> without concerns of what RPs want<\/I>, here you are simply \u201creverse engineering\u201d what are such info from the RPs logic since until now we haven\u2019t 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\u2019t the RP will simply move on and decide to federate with somebody who does.<\/P> 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\u2019s 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\u2019ll get back to it in some other post.<\/P> Below you can find a small divertissment where I show a rough schema for the claim inclusion decision process described above.<\/P> <\/P> <\/P> 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\u2026 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\u2019s make this happen! Who wants to be the first to evolve wings? J<\/SPAN><\/SPAN><\/P><\/p>\n Good news, you\u2019re in very good company. I\u2019ve 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\u2019t go into details, for obvious reasons, I believe that sharing some…<\/p>\n","protected":false},"author":1,"featured_media":1492,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"footnotes":""},"categories":[61,39,9,86,30,55],"tags":[],"class_list":["post-671","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-architecture-ws","category-cardspace","category-identity","category-infocard","category-wcs","category-windows-cardspace"],"_links":{"self":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/671","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/comments?post=671"}],"version-history":[{"count":1,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/671\/revisions"}],"predecessor-version":[{"id":1813,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/671\/revisions\/1813"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media\/1492"}],"wp:attachment":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media?parent=671"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/categories?post=671"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/tags?post=671"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n![](\"http:\/\/www.filelodge.com\/files\/room27\/727299\/CardDecision.jpg\")
\n
\n
\n