Kapil Sachdeva's Blog - SmartCard Serenity

Thanks to Kim's explanation finally I have a clear understanding of how the InfoCard selection mechanism (GUI) will work.

In my blog here I was saying that what is displayed in wireframe GUI that comes with Indigo BETA SDK is an attribute card and not Infocard. My understanding was wrong. He corrects me here

“Well, the question is, does the user have to know about the metadata connecting the InfoCard to the Identity Provider?  I don't think so.  Therefore we "dereference" the metadata and show the underlying identity information.  Developers might find this confusing at first, but what do developers like better than a level of indirection????

Here's our thinking.  The InfoCards contain "metadata" just as Kapil says.  But when a user looks at an InfoCard, we don't show her the metadata (which would be meaningless to her).  Instead, we use the metadata to procure a token, and show the information the identity provider is capable of releasing (in other words the set of claims that go along with that identity). “

So, what is displayed is a portion of InfoCard i.e set of claims supported by STS (whose representive this InfoCard is).

But in wirefram GUI I am able to see the attributes (data) which I can also edit, it goes against the notion that InfoCard is just a metadata.

Trevor Lawrence throws a light on this as a comment in Kim's blog.

“It looks at the moment as if the InfoCard UI has a special case built in to allow you to edit your claims in the self-asserted IP that is included. In general, as I understand it, out-of-band mechanisms are likely to be needed to change the claim data that an external IP asserts for a user. (In an authoritive IP I can't just change my passport number without by some other means proving to this IP that that indeed is the number of a new passport issued to me.) “

Now this makes everything clear. What is displayed are supported claims in InfoCard (minus the geekey part) and if these claims reside on user's machine (PC as a local identity provider) then you can edit and see the claims else you need an out of band mechanism to do that. Mostly knowing that these are claims [not data] (displayed in wireframe GUI) which will be transmitted by my IDP to relying party should be enough.

Many thanks to Kim and Trevor for insight.

Kim answers my question on confusion regarding Identity metasystem architecture here.

My question was how Liberty based systems which use different protocol (other than WS-Trust) to exchange security tokens would be suppoed in Identity metasystem (mostly to take advantage of InfoCard system Microsoft has put in place).

Kim points out the problem is not only for Liberty enabled providers but for existing islands of identity systems if they want to use the metasystem.

“The truth is, to get to a metasystem, it wouldn't only be Liberty or SAML implementors who would have add the token exchange capability -changes would be required in all the systems asserting corporate and government identities;  in operating systems, mobile devices, online services, smartcards; and in every other technology mentioned in our whitepaper.  No one, including Microsoft, has WS-Trust rolled out at this point in time, so everyone would have to take the plunge.”

This is exactly true.

As a solution to this he proposes

“I was really trying to point out that everything SAML users and vendors already had in place could continue to work just as it does now, while with a small incremental effort their systems could embrace the metasystem.  Sure, it would mean supporting WS-Trust - a protocol designed for metasystem purposes:  exchanging one security token for another different security token.  But the people who've built SAML systems will have little difficulty going this extra step. “

So basically the problem can be approached in 2 ways.

•  Liberty or SAML systems move to WS-Trust protocol completely (which I do not think they will do) or
•  Liberty or SAML systems add translators (protocol translators WS-Trust to SAML Request and vice versa) at the server side.

There is a nice blog from Andy Harjanto on InfoCard System so do not want to explan here the basic concepts. He has done a great job describing with some sample code all the elements of InfoCard system.

I was recently playing with the Avalon and Indigo BETA SDK to see the InfoCard systems in action. There is something which may be confusing (seems like today I am going to talk only about confusions :) ) to some people. With Indigo comes a Windows service called Microsoft Digital Identity service (InfoCard system) which displays a GUI where you could create sets of attributes. These sets are called “Cards”. Lot of people will take this to be “InfoCards”.

An InfoCard is just a metadata which says what is the authentication mechanism to be used at STS .. what are supported claims at STS etc. It does not contain the data or attributes about user. 

Microsoft InfoCard 1.0 Beta 1 GUI displays digital identities of user and not the Info cards. Wish there is a better word MSFT can use for these set of attributes instead of “Cards” to avoid possible confusion.

Now this also raises a question, the GUI from Digital Identities service is for selecting a set of attributes not info cards (if my understanding is correct) so will there be a selection mechanism for InfoCards also ?.... A use case can be imagined in which I have 2 InfoCards (for eg 2 authentication mechanisms) for the same relying party then client on my PC should know of a way to select the correct InfoCard.

From Identity metasystem whitepaper at MSDN

“Participants in the identity metasystem can include anyone or anything that uses, participates in, or relies upon identities in any way, including, but not limited to existing identity systems, corporate identities, government identities, Liberty federations, operating systems, mobile devices, online services, and smartcards. Again, the possibilities are only limited by innovators' imaginations.”

Identity Metasystem Architectural Diagram

Going by this diagram which is based on WS-Trust as a request/response protocol for security tokens I do not understand how this architecture of Identity metasystem connects different participants as mentioned in statement above.

If I have a Liberty ID-FF or SAML 2.0 enabled IDP which use SAMLRequest and SAMLResponse for security tokens this architecture does not help.

My understanding is that this identity meta system is for service providers, identity providers and client machines (infocard system) which are based on WS-Trust and so saying that other participants such as Liberty could participate in this meta system may not be correct.

If some one could clarify ?

Blogging after a long time ... have been busy working on new versions of .NET Smart card.

In May I participated in Liberty conformance event in New Jersey and successfully interoperated our Smart card solution which consists of ID-FF 1.2 LECP profile and ID-WSF 1.1 LUAD-WSC with other vendors and got the certification.

Here is a link to the press release.

http://www.projectliberty.org/press/details.php?item_id=115

From the release:

At the test event hosted by the IEEE Industry Standards and Technology Organization (IEEE-ISTO) and held in Piscataway, New Jersey, during the week of May 9-13, 2005, the following products and services demonstrated conformance with the Liberty Alliance Identity Federation Framework version 1.1 and 1.2 (ID-FF1.1 and ID-FF1.2), and the Liberty Alliance Web Services Framework version 1.0 and 1.1 (ID-WSF 1.0 and ID-WSF 1.1):

Axalto –Axalto’s robust iClient 1.0 technology package is a set of client components and a programmable smart card that supports the Liberty ID-FF 1.2 Liberty Enabled Client Profile (LECP) and Liberty ID-WSF 1.1 Liberty User Agent or Device (LUAD) WSC profiles. By supporting the LECP profile and acting as a LUAD-WSC, the Axalto iClient allows support for secure and mobile usage of user credentials using smart cards.

I have been waiting and knew this would happen and is definitely a good thing to happen. I have been working with the both specifications and in spirituality they are the same and differ mostly at schema level, after all there can not be many ways to solve the same problem.

Kudos to SUN and MSFT to come together and have industry march towards better inter-operable solutions.

Following are the links where the initial drafts of the specifications can be found

http://msdn.microsoft.com/library/en-us/dnglobspec/html/websso.pdf

An interoperability profile for Liberty ID-FF1.2 and WS-Federation Passive: this document is a profile of WSSOMEX that allows using either Liberty's ID-FF 1.2 (browser POST profile) or WS-Federation Passive Requestor Interoperability Profile to interact with a service.

http://msdn.microsoft.com/library/en-us/dnglobspec/html/websso-mex.pdf

A web single sign-on metadata exchange protocol (WSSOMEX) that defines a mechanism whereby a Service Provider can determine the protocol suites supported by a client's Identity Provider and use a commonly supported protocol suite to perform SSO-based operations. Simply put, this protocol lets a Service Provider ask "what protocol suites do you speak?" to an Identity Provider.