Welcome to MSDN Blogs Sign in | Join | Help

Welcome to The Metaverse

Navigating the service-oriented, identity aware metaverse

News

  • Disclaimer:
    The content of this blog are my own personal opinions and do not necessarily represent Microsoft's position, commitments or strategy. In addition, my thoughts and opinions often change, and as a weblog is intended to provide a semi-permanent point in time snapshot you should not consider out of date posts to reflect my current thoughts and opinions.




    Add to Technorati Favorites
Dana Epps on RunAs Radio discussing CardSpace

Just listened in to Scorpion Software's Dana Epps' great interview on RunAs Radio discussing Information Cards, CardSpace and STS', interop and why usernames and password are a pain.

WS-Trust vs. WS-Federation

I do want to correct a small but important error: Identity Selectors in the Identity Metasystem use WS-Trust to request tokens representing the user from Identity Providers, not WS-Federation.

This is an easy mistake to make but it's important to understand the difference between WS-Trust and WS-Federation:

  • WS-Trust is for scenarios where the user needs to interact with an "identity selector" to decide who they want to be at the beginning of each visit or session. This is a scenario we're all familiar with today when we sign in at our web-based email provider as one user to check our "Friends" mail and then sign out and sign back in to check our "Work" mail, etc. This is why identity selectors in the identity metasystem use WS-Trust
  • WS-Federation is for scenarios where two organizations wish to closely collaborate and enable users in one organization to access resources within the other organization without having to manually sign-in. Supported by Enterprise-class technologies like Microsoft's ADFS and PingID's PingFederate, WS-Federation enables a user's organization to tell a partner organization who the user is and also convey extra information such as the user's role and rights.

Personal Cards vs. Managed Cards

Dana did a great job of discussing how information cards can be used TODAY instead of using traditional username/password authentication. However, quite some time was spent focusing on managed-card scenarios and I wanted to provide a little perspective on this matter:

Personal Cards

In order for you to sign-in to a given relying party (website or application) with information cards, all you need is an Identity Selector such as Windows CardSpace and an information card that is compatible with the relying party's specified policies.

Since relying parties decide what type of information they want from you in order to sign you into their systems, they get to ask you for a particular type of token and a particular set of claims. A common personal card scenario is associating or linking one or more personal cards with a relying party's existing account:

After logging in with your username and password, the relying party may allow you to register one or more personal cards that you can use to sign-in during subsequent visits. Since the relying party already knows you, they only really need you to provide a personal card with a PPID (unique ID for that card at this site) which they can use to generate a UniqueID that they can store in their DB and use to look you up next time you sign into their site using your information card. This enables you to sign in more safely and easily from one or more machines with three mouse-clicks rather than having to remember your username and password.

These "personal card" scenarios are easy to support today, with little developer effort.

Managed Cards

Managed cards are issued by identity providers who are willing to assert that a particular set of claims about a person do in fact relate to that person. Examples of organizations who might be interested in issuing a managed card to you are your bank, your employer, your government, your favorite hotel chain or airline, etc.

Where managed cards become extremely exciting and powerful is where a relying party needs some form of information about you that has been corroborated by an organization that they trust. For example: An online wine store might want a confirmation from your state government that you are over 21 and so might ask you to provide a state-issued token containing the "Over21" claim.

Another good example of where managed cards provide great value is when a relying party needs some information about you that is likely to change fairly regularly. For example, imagine if you could sign-in to your favorite online store with your credit card company's member rewards card and the site could show you a list of the products that might interest you that are covered by your available points balance. No usernames, no passwords, no awkward redirection - just a plain and simple, easy to use mechanism that gets you into the site and shows you a list of products that you might want that you can afford!

Which type of card to support now!

However, whilst managed cards are exciting, the infrastructure to support them isn't quite there yet. Specifically, you need an STS (Security Token Service) - a service that issues and processes requests for managed identity tokens. Whilst some vendors (such as PingID's PingTrust and Arcot Systems' WebFort) are currently shipping with managed card support, Microsoft, Novell, IBM and many others are currently building STS capabilities into their future product offerings.

Until then, if you want to start making your users' lives easier and safer then we urge you to add support for personal cards.

Supporting personal cards now will also make it much easier for you to support advanced managed card scenarios when the infrastructure becomes available.

Posted: Tuesday, July 24, 2007 12:32 PM by richardt
Filed under:

Comments

Jason Haley said:

# July 25, 2007 10:12 AM

selvaonline said:

Hi,

 Very useful and nice post. Is there any website currently support this card system.

Regards,

Selva

www.selvaonline.com

# August 21, 2007 7:03 AM
Anonymous comments are disabled
Page view tracker