do it. think it. blog it! ... a twisted world

In my effort to have a non vendor specific JavaCard reader application/applet. Here's something else I discovered. Well, this may sound silly The SmartCard/JavaCard reader neds to either be built into your desktops/laptops or you may need to use a external reader. You are free to buy a reader from any vendor and in the process of doing so, you would also receive the necessary PC/SC drivers from the vendor.

but to make life simpler, here's a small list of vendors that you may procure your smartcard reader from.

1. Schlumberger
2. Gemplus
3. SCM Microsystems
4. Towitoko
5. Omnikey
6. Advanced Card Systems
7. Athena Smartcard Systems
8. Intertex IX
9. Ankari (American Biometrics)
10. Orga

There may be some of you who may not want to go through he process of buying a reader and a smartcard but would still be interedted in testing the applet/application without shelling out any moolah. Well, I have something for those folks too. I suggest you use the Smart Card Simulator. TSCS is a program for Windows 32 simulating a terminal and a smart card. Neither a smart card nor a smart card terminal is necessary. Just install the software on your PC and start working with smart cards. With this software you can see ¨into¨ the smart card, create files, send commands and receive the response from the smart card.

The Smart Card Simulator offers you a wide variety of possibilities to learn and work with a smart card. It can be used to understand and to learn the principles of a smart card, design and test a smart card application, calculate typical execution times etc.

null

Identity Management, and Identity Federation has been the buzzword in this space for a while now. According to the definition of "Federated Identity" on wikipedia, it has two general meanings:

• The virtual reunion, or assembled identity of a person's user information (or principal), stored across multiple distinct identity management systems. Data is joined together by use of the common token, usually the user name.
• The process of a user's authentication across multiple IT systems or even organisations.

now, this is great when the Legal Entity has a unique "identity" on each of the disparate systems. But when the Legal Entity who has a identity on a system is provided access to a partner site or system, there is absolutely no "Federation" possible if the Legal Entity has no identity on the partner site or system. I was involved in a brainstorming session related to shibboleth with a few technical folks from a university. What came up was the need to allow students from one university to access resources from another university. The folks I was interacting with were "sold" on the idea of federation, but lacked complete understanding of how federation really worked. Here were my concerns:

• The user needed to have a unique identity on either systems.
• The user needs to explicitly "federate" his identity. (If he does have a unique identity on each system)
• If the users identity gets stolen, well, we have a much bigger issue.

(I thought) What the university really needed was implicit Federation. Whereby when a user who has authenticated himself at one university, when provided access to resources in another, should be granted access even thought the user does not have a unique identity at the other. Here's an example:

1. University1 and University2 belong to a "defined" Circle of Trust.
2. Student at University1 authenticates at University1.
3. Student tries to access resources at University2.
4. University2 Requests University1 to assert the validity of the user session.
5. University1 Asserts that the user is "A" authenticated user, but does not actually reveal the users "handle" or "identity" in any form
6. University2 grants the user access by just knowing that the user is a "authenticated" user at University1, without even knowing who the user actually is. (University2 provides just generic content to the user)
7. User tries to personalize his "content" or University2 needs to provide the User "specific" content based on role the student has at University1
   • University2 would need to prompt the user for "permissions" to derive his "role" from UnIversity1
   • User grants permissions by using a digital signature of some sort.
   • University2 uses that digital signature to request University1 for the Users roles
   • University1 verifies that the digital signature matches that of the Authenticated User and grants University2 the users roles and/or "identity/alias".
   • University2 provisions a local "identity/alias" and associates it with the "role" as asserted by University1
8. University2 can now allow the user to "personalize "content" or provide the user "content" as necessary.

I believe that with this aproach, even though a student has no "identity" on one system or university (University2 in the example I used) he/She still gets to experience the "magic" of "federation". On second thoughts, If I apply this to the examples widely used in "federation", where a airliner and a car rental company are in a circle of trust, well, I am sure that the car rental company would love to receive a new unidentified user from a "partner airline" and dynamically provision the user and sell him a product !!! it's all about making money in the bargain right ? or is it just making the user experience more enjoyable and easy ? I believe that we'd be kidding ourselves if we say that it's ONLY about "user experience" Now: The user providing his/her "digital signature" to the car rental company is another story altogether.. Comment Away Please... (Comments are active for only 30 days from the date of this posting) UPDATE : Please Read Pat Patterson's response by Clicking Here or by following the link in the 1st Comment/Trackback below.